diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-06-16 16:59:00 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-06-16 16:59:33 +0000 |
| commit | 9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch) | |
| tree | b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/unknown | |
| parent | b89a938452613061c0f1f23e710281cf5c83cb29 (diff) | |
| download | emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip | |
add 18th iteration of classifier
Diffstat (limited to 'results/classifier/118/unknown')
155 files changed, 34751 insertions, 0 deletions
diff --git a/results/classifier/118/unknown/02572177 b/results/classifier/118/unknown/02572177 new file mode 100644 index 00000000..da620d9d --- /dev/null +++ b/results/classifier/118/unknown/02572177 @@ -0,0 +1,446 @@ +permissions: 0.812 +device: 0.791 +architecture: 0.788 +performance: 0.781 +peripherals: 0.775 +virtual: 0.774 +semantic: 0.770 +register: 0.767 +risc-v: 0.761 +debug: 0.756 +assembly: 0.756 +ppc: 0.753 +arm: 0.749 +graphic: 0.747 +socket: 0.742 +user-level: 0.735 +PID: 0.731 +hypervisor: 0.723 +TCG: 0.722 +x86: 0.719 +network: 0.708 +vnc: 0.706 +mistranslation: 0.693 +VMM: 0.692 +kernel: 0.689 +KVM: 0.669 +boot: 0.658 +files: 0.640 +i386: 0.635 + +[Qemu-devel] 答复: Re: [BUG]COLO failover hang + +hi. + + +I test the git qemu master have the same problem. + + +(gdb) bt + + +#0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, niov=1, +fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 + + +#1 0x00007f658e4aa0c2 in qio_channel_read (address@hidden, address@hidden "", +address@hidden, address@hidden) at io/channel.c:114 + + +#2 0x00007f658e3ea990 in channel_get_buffer (opaque=ï¼optimized outï¼, +buf=0x7f65907cb838 "", pos=ï¼optimized outï¼, size=32768) at +migration/qemu-file-channel.c:78 + + +#3 0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at +migration/qemu-file.c:295 + + +#4 0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, address@hidden) at +migration/qemu-file.c:555 + + +#5 0x00007f658e3ea34b in qemu_get_byte (address@hidden) at +migration/qemu-file.c:568 + + +#6 0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at +migration/qemu-file.c:648 + + +#7 0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, +address@hidden) at migration/colo.c:244 + + +#8 0x00007f658e3e681e in colo_receive_check_message (f=ï¼optimized outï¼, +address@hidden, address@hidden) + + + at migration/colo.c:264 + + +#9 0x00007f658e3e740e in colo_process_incoming_thread (opaque=0x7f658eb30360 +ï¼mis_current.31286ï¼) at migration/colo.c:577 + + +#10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0 + + +#11 0x00007f65881983ed in clone () from /lib64/libc.so.6 + + +(gdb) p ioc-ï¼name + + +$2 = 0x7f658ff7d5c0 "migration-socket-incoming" + + +(gdb) p ioc-ï¼features Do not support QIO_CHANNEL_FEATURE_SHUTDOWN + + +$3 = 0 + + + + + +(gdb) bt + + +#0 socket_accept_incoming_migration (ioc=0x7fdcceeafa90, condition=G_IO_IN, +opaque=0x7fdcceeafa90) at migration/socket.c:137 + + +#1 0x00007fdcc6966350 in g_main_dispatch (context=ï¼optimized outï¼) at +gmain.c:3054 + + +#2 g_main_context_dispatch (context=ï¼optimized outï¼, address@hidden) at +gmain.c:3630 + + +#3 0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213 + + +#4 os_host_main_loop_wait (timeout=ï¼optimized outï¼) at util/main-loop.c:258 + + +#5 main_loop_wait (address@hidden) at util/main-loop.c:506 + + +#6 0x00007fdccb526187 in main_loop () at vl.c:1898 + + +#7 main (argc=ï¼optimized outï¼, argv=ï¼optimized outï¼, envp=ï¼optimized outï¼) at +vl.c:4709 + + +(gdb) p ioc-ï¼features + + +$1 = 6 + + +(gdb) p ioc-ï¼name + + +$2 = 0x7fdcce1b1ab0 "migration-socket-listener" + + + + + +May be socket_accept_incoming_migration should call +qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)?? + + + + + +thank you. + + + + + + + + + + + + + + + +åå§é®ä»¶ + + + +åä»¶äººï¼ address@hidden +æ¶ä»¶äººï¼ç广10165992 address@hidden +æéäººï¼ address@hidden address@hidden +æ¥ æ ï¼2017å¹´03æ16æ¥ 14:46 +主 é¢ ï¼Re: [Qemu-devel] COLO failover hang + + + + + + + +On 03/15/2017 05:06 PM, wangguang wrote: +ï¼ am testing QEMU COLO feature described here [QEMU +ï¼ Wiki]( +http://wiki.qemu-project.org/Features/COLO +). +ï¼ +ï¼ When the Primary Node panic,the Secondary Node qemu hang. +ï¼ hang at recvmsg in qio_channel_socket_readv. +ï¼ And I run { 'execute': 'nbd-server-stop' } and { "execute": +ï¼ "x-colo-lost-heartbeat" } in Secondary VM's +ï¼ monitor,the Secondary Node qemu still hang at recvmsg . +ï¼ +ï¼ I found that the colo in qemu is not complete yet. +ï¼ Do the colo have any plan for development? + +Yes, We are developing. You can see some of patch we pushing. + +ï¼ Has anyone ever run it successfully? Any help is appreciated! + +In our internal version can run it successfully, +The failover detail you can ask Zhanghailiang for help. +Next time if you have some question about COLO, +please cc me and zhanghailiang address@hidden + + +Thanks +Zhang Chen + + +ï¼ +ï¼ +ï¼ +ï¼ centos7.2+qemu2.7.50 +ï¼ (gdb) bt +ï¼ #0 0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0 +ï¼ #1 0x00007f3e0332b738 in qio_channel_socket_readv (ioc=ï¼optimized outï¼, +ï¼ iov=ï¼optimized outï¼, niov=ï¼optimized outï¼, fds=0x0, nfds=0x0, errp=0x0) at +ï¼ io/channel-socket.c:497 +ï¼ #2 0x00007f3e03329472 in qio_channel_read (address@hidden, +ï¼ address@hidden "", address@hidden, +ï¼ address@hidden) at io/channel.c:97 +ï¼ #3 0x00007f3e032750e0 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ buf=0x7f3e05910f38 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ migration/qemu-file-channel.c:78 +ï¼ #4 0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at +ï¼ migration/qemu-file.c:257 +ï¼ #5 0x00007f3e03274a41 in qemu_peek_byte (address@hidden, +ï¼ address@hidden) at migration/qemu-file.c:510 +ï¼ #6 0x00007f3e03274aab in qemu_get_byte (address@hidden) at +ï¼ migration/qemu-file.c:523 +ï¼ #7 0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at +ï¼ migration/qemu-file.c:603 +ï¼ #8 0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00, +ï¼ address@hidden) at migration/colo.c:215 +ï¼ #9 0x00007f3e0327250d in colo_wait_handle_message (errp=0x7f3d62bfaa48, +ï¼ checkpoint_request=ï¼synthetic pointerï¼, f=ï¼optimized outï¼) at +ï¼ migration/colo.c:546 +ï¼ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at +ï¼ migration/colo.c:649 +ï¼ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc.so.6 +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ -- +ï¼ View this message in context: +http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html +ï¼ Sent from the Developer mailing list archive at Nabble.com. +ï¼ +ï¼ +ï¼ +ï¼ + +-- +Thanks +Zhang Chen + +Hi,Wang. + +You can test this branch: +https://github.com/coloft/qemu/tree/colo-v5.1-developing-COLO-frame-v21-with-shared-disk +and please follow wiki ensure your own configuration correctly. +http://wiki.qemu-project.org/Features/COLO +Thanks + +Zhang Chen + + +On 03/21/2017 03:27 PM, address@hidden wrote: +hi. + +I test the git qemu master have the same problem. + +(gdb) bt +#0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, +niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 +#1 0x00007f658e4aa0c2 in qio_channel_read +(address@hidden, address@hidden "", +address@hidden, address@hidden) at io/channel.c:114 +#2 0x00007f658e3ea990 in channel_get_buffer (opaque=ï¼optimized outï¼, +buf=0x7f65907cb838 "", pos=ï¼optimized outï¼, size=32768) at +migration/qemu-file-channel.c:78 +#3 0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at +migration/qemu-file.c:295 +#4 0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, +address@hidden) at migration/qemu-file.c:555 +#5 0x00007f658e3ea34b in qemu_get_byte (address@hidden) at +migration/qemu-file.c:568 +#6 0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at +migration/qemu-file.c:648 +#7 0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, +address@hidden) at migration/colo.c:244 +#8 0x00007f658e3e681e in colo_receive_check_message (f=ï¼optimized +outï¼, address@hidden, +address@hidden) +at migration/colo.c:264 +#9 0x00007f658e3e740e in colo_process_incoming_thread +(opaque=0x7f658eb30360 ï¼mis_current.31286ï¼) at migration/colo.c:577 +#10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0 + +#11 0x00007f65881983ed in clone () from /lib64/libc.so.6 + +(gdb) p ioc-ï¼name + +$2 = 0x7f658ff7d5c0 "migration-socket-incoming" + +(gdb) p ioc-ï¼features Do not support QIO_CHANNEL_FEATURE_SHUTDOWN + +$3 = 0 + + +(gdb) bt +#0 socket_accept_incoming_migration (ioc=0x7fdcceeafa90, +condition=G_IO_IN, opaque=0x7fdcceeafa90) at migration/socket.c:137 +#1 0x00007fdcc6966350 in g_main_dispatch (context=ï¼optimized outï¼) at +gmain.c:3054 +#2 g_main_context_dispatch (context=ï¼optimized outï¼, +address@hidden) at gmain.c:3630 +#3 0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213 +#4 os_host_main_loop_wait (timeout=ï¼optimized outï¼) at +util/main-loop.c:258 +#5 main_loop_wait (address@hidden) at +util/main-loop.c:506 +#6 0x00007fdccb526187 in main_loop () at vl.c:1898 +#7 main (argc=ï¼optimized outï¼, argv=ï¼optimized outï¼, envp=ï¼optimized +outï¼) at vl.c:4709 +(gdb) p ioc-ï¼features + +$1 = 6 + +(gdb) p ioc-ï¼name + +$2 = 0x7fdcce1b1ab0 "migration-socket-listener" +May be socket_accept_incoming_migration should +call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)?? +thank you. + + + + + +åå§é®ä»¶ +address@hidden; +*æ¶ä»¶äººï¼*ç广10165992;address@hidden; +address@hidden;address@hidden; +*æ¥ æ ï¼*2017å¹´03æ16æ¥ 14:46 +*主 é¢ ï¼**Re: [Qemu-devel] COLO failover hang* + + + + +On 03/15/2017 05:06 PM, wangguang wrote: +ï¼ am testing QEMU COLO feature described here [QEMU +ï¼ Wiki]( +http://wiki.qemu-project.org/Features/COLO +). +ï¼ +ï¼ When the Primary Node panic,the Secondary Node qemu hang. +ï¼ hang at recvmsg in qio_channel_socket_readv. +ï¼ And I run { 'execute': 'nbd-server-stop' } and { "execute": +ï¼ "x-colo-lost-heartbeat" } in Secondary VM's +ï¼ monitor,the Secondary Node qemu still hang at recvmsg . +ï¼ +ï¼ I found that the colo in qemu is not complete yet. +ï¼ Do the colo have any plan for development? + +Yes, We are developing. You can see some of patch we pushing. + +ï¼ Has anyone ever run it successfully? Any help is appreciated! + +In our internal version can run it successfully, +The failover detail you can ask Zhanghailiang for help. +Next time if you have some question about COLO, +please cc me and zhanghailiang address@hidden + + +Thanks +Zhang Chen + + +ï¼ +ï¼ +ï¼ +ï¼ centos7.2+qemu2.7.50 +ï¼ (gdb) bt +ï¼ #0 0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0 +ï¼ #1 0x00007f3e0332b738 in qio_channel_socket_readv (ioc=ï¼optimized outï¼, +ï¼ iov=ï¼optimized outï¼, niov=ï¼optimized outï¼, fds=0x0, nfds=0x0, errp=0x0) at +ï¼ io/channel-socket.c:497 +ï¼ #2 0x00007f3e03329472 in qio_channel_read (address@hidden, +ï¼ address@hidden "", address@hidden, +ï¼ address@hidden) at io/channel.c:97 +ï¼ #3 0x00007f3e032750e0 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ buf=0x7f3e05910f38 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ migration/qemu-file-channel.c:78 +ï¼ #4 0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at +ï¼ migration/qemu-file.c:257 +ï¼ #5 0x00007f3e03274a41 in qemu_peek_byte (address@hidden, +ï¼ address@hidden) at migration/qemu-file.c:510 +ï¼ #6 0x00007f3e03274aab in qemu_get_byte (address@hidden) at +ï¼ migration/qemu-file.c:523 +ï¼ #7 0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at +ï¼ migration/qemu-file.c:603 +ï¼ #8 0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00, +ï¼ address@hidden) at migration/colo.c:215 +ï¼ #9 0x00007f3e0327250d in colo_wait_handle_message (errp=0x7f3d62bfaa48, +ï¼ checkpoint_request=ï¼synthetic pointerï¼, f=ï¼optimized outï¼) at +ï¼ migration/colo.c:546 +ï¼ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at +ï¼ migration/colo.c:649 +ï¼ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc.so.6 +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ -- +ï¼ View this message in context: +http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html +ï¼ Sent from the Developer mailing list archive at Nabble.com. +ï¼ +ï¼ +ï¼ +ï¼ + +-- +Thanks +Zhang Chen +-- +Thanks +Zhang Chen + diff --git a/results/classifier/118/unknown/04472277 b/results/classifier/118/unknown/04472277 new file mode 100644 index 00000000..99f9b590 --- /dev/null +++ b/results/classifier/118/unknown/04472277 @@ -0,0 +1,601 @@ +KVM: 0.890 +user-level: 0.889 +register: 0.886 +virtual: 0.876 +risc-v: 0.864 +VMM: 0.858 +architecture: 0.857 +hypervisor: 0.854 +permissions: 0.851 +device: 0.849 +debug: 0.849 +ppc: 0.848 +network: 0.847 +graphic: 0.846 +x86: 0.841 +performance: 0.841 +assembly: 0.841 +kernel: 0.839 +peripherals: 0.838 +boot: 0.831 +vnc: 0.828 +PID: 0.826 +TCG: 0.825 +socket: 0.824 +arm: 0.821 +mistranslation: 0.817 +semantic: 0.815 +i386: 0.805 +files: 0.790 + +[BUG][KVM_SET_USER_MEMORY_REGION] KVM_SET_USER_MEMORY_REGION failed + +Hi all, +I start a VM in openstack, and openstack use libvirt to start qemu VM, but now log show this ERROR. +Is there any one know this? +The ERROR log from /var/log/libvirt/qemu/instance-0000000e.log +``` +2023-03-14T10:09:17.674114Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-14 10:09:18.198+0000: shutting down, reason=crashed +``` +The xml file +``` +root@c1c2:~# cat /etc/libvirt/qemu/instance-0000000e.xml +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit instance-0000000e +or other application using the libvirt API. +--> +<domain type='kvm'> + <name>instance-0000000e</name> + <uuid>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</uuid> + <metadata> +  <nova:instance xmlns:nova=" +http://openstack.org/xmlns/libvirt/nova/1.1 +"> +   <nova:package version="25.1.0"/> +   <nova:name>provider-instance</nova:name> +   <nova:creationTime>2023-03-14 10:09:13</nova:creationTime> +   <nova:flavor name="cirros-os-dpu-test-1"> +    <nova:memory>64</nova:memory> +    <nova:disk>1</nova:disk> +    <nova:swap>0</nova:swap> +    <nova:ephemeral>0</nova:ephemeral> +    <nova:vcpus>1</nova:vcpus> +   </nova:flavor> +   <nova:owner> +    <nova:user uuid="ff627ad39ed94479b9c5033bc462cf78">admin</nova:user> +    <nova:project uuid="512866f9994f4ad8916d8539a7cdeec9">admin</nova:project> +   </nova:owner> +   <nova:root type="image" uuid="9e58cb69-316a-4093-9f23-c1d1bd8edffe"/> +   <nova:ports> +    <nova:port uuid="77c1dc00-af39-4463-bea0-12808f4bc340"> +     <nova:ip type="fixed" address="172.1.1.43" ipVersion="4"/> +    </nova:port> +   </nova:ports> +  </nova:instance> + </metadata> + <memory unit='KiB'>65536</memory> + <currentMemory unit='KiB'>65536</currentMemory> + <vcpu placement='static'>1</vcpu> + <sysinfo type='smbios'> +  <system> +   <entry name='manufacturer'>OpenStack Foundation</entry> +   <entry name='product'>OpenStack Nova</entry> +   <entry name='version'>25.1.0</entry> +   <entry name='serial'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='uuid'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='family'>Virtual Machine</entry> +  </system> + </sysinfo> + <os> +  <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type> +  <boot dev='hd'/> +  <smbios mode='sysinfo'/> + </os> + <features> +  <acpi/> +  <apic/> +  <vmcoreinfo state='on'/> + </features> + <cpu mode='host-model' check='partial'> +  <topology sockets='1' dies='1' cores='1' threads='1'/> + </cpu> + <clock offset='utc'> +  <timer name='pit' tickpolicy='delay'/> +  <timer name='rtc' tickpolicy='catchup'/> +  <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> +  <emulator>/usr/bin/qemu-system-x86_64</emulator> +  <disk type='file' device='disk'> +   <driver name='qemu' type='qcow2' cache='none'/> +   <source file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk'/> +   <target dev='vda' bus='virtio'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> +  </disk> +  <controller type='usb' index='0' model='piix3-uhci'> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> +  </controller> +  <controller type='pci' index='0' model='pci-root'/> +  <interface type='hostdev' managed='yes'> +   <mac address='fa:16:3e:aa:d9:23'/> +   <source> +    <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> +  </interface> +  <serial type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='isa-serial' port='0'> +    <model name='isa-serial'/> +   </target> +  </serial> +  <console type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='serial' port='0'/> +  </console> +  <input type='tablet' bus='usb'> +   <address type='usb' bus='0' port='1'/> +  </input> +  <input type='mouse' bus='ps2'/> +  <input type='keyboard' bus='ps2'/> +  <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> +   <listen type='address' address='0.0.0.0'/> +  </graphics> +  <audio id='1' type='none'/> +  <video> +   <model type='virtio' heads='1' primary='yes'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> +  </video> +  <hostdev mode='subsystem' type='pci' managed='yes'> +   <source> +    <address domain='0x0000' bus='0x01' slot='0x00' function='0x6'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> +  </hostdev> +  <memballoon model='virtio'> +   <stats period='10'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> +  </memballoon> +  <rng model='virtio'> +   <backend model='random'>/dev/urandom</backend> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> +  </rng> + </devices> +</domain> +``` +---- +Simon Jones + +This is happened in ubuntu22.04. +QEMU is install by apt like this: +apt install -y qemu qemu-kvm qemu-system +and QEMU version is 6.2.0 +---- +Simon Jones +Simon Jones < +batmanustc@gmail.com +> äº2023å¹´3æ21æ¥å¨äº 08:40åéï¼ +Hi all, +I start a VM in openstack, and openstack use libvirt to start qemu VM, but now log show this ERROR. +Is there any one know this? +The ERROR log from /var/log/libvirt/qemu/instance-0000000e.log +``` +2023-03-14T10:09:17.674114Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-14 10:09:18.198+0000: shutting down, reason=crashed +``` +The xml file +``` +root@c1c2:~# cat /etc/libvirt/qemu/instance-0000000e.xml +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit instance-0000000e +or other application using the libvirt API. +--> +<domain type='kvm'> + <name>instance-0000000e</name> + <uuid>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</uuid> + <metadata> +  <nova:instance xmlns:nova=" +http://openstack.org/xmlns/libvirt/nova/1.1 +"> +   <nova:package version="25.1.0"/> +   <nova:name>provider-instance</nova:name> +   <nova:creationTime>2023-03-14 10:09:13</nova:creationTime> +   <nova:flavor name="cirros-os-dpu-test-1"> +    <nova:memory>64</nova:memory> +    <nova:disk>1</nova:disk> +    <nova:swap>0</nova:swap> +    <nova:ephemeral>0</nova:ephemeral> +    <nova:vcpus>1</nova:vcpus> +   </nova:flavor> +   <nova:owner> +    <nova:user uuid="ff627ad39ed94479b9c5033bc462cf78">admin</nova:user> +    <nova:project uuid="512866f9994f4ad8916d8539a7cdeec9">admin</nova:project> +   </nova:owner> +   <nova:root type="image" uuid="9e58cb69-316a-4093-9f23-c1d1bd8edffe"/> +   <nova:ports> +    <nova:port uuid="77c1dc00-af39-4463-bea0-12808f4bc340"> +     <nova:ip type="fixed" address="172.1.1.43" ipVersion="4"/> +    </nova:port> +   </nova:ports> +  </nova:instance> + </metadata> + <memory unit='KiB'>65536</memory> + <currentMemory unit='KiB'>65536</currentMemory> + <vcpu placement='static'>1</vcpu> + <sysinfo type='smbios'> +  <system> +   <entry name='manufacturer'>OpenStack Foundation</entry> +   <entry name='product'>OpenStack Nova</entry> +   <entry name='version'>25.1.0</entry> +   <entry name='serial'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='uuid'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='family'>Virtual Machine</entry> +  </system> + </sysinfo> + <os> +  <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type> +  <boot dev='hd'/> +  <smbios mode='sysinfo'/> + </os> + <features> +  <acpi/> +  <apic/> +  <vmcoreinfo state='on'/> + </features> + <cpu mode='host-model' check='partial'> +  <topology sockets='1' dies='1' cores='1' threads='1'/> + </cpu> + <clock offset='utc'> +  <timer name='pit' tickpolicy='delay'/> +  <timer name='rtc' tickpolicy='catchup'/> +  <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> +  <emulator>/usr/bin/qemu-system-x86_64</emulator> +  <disk type='file' device='disk'> +   <driver name='qemu' type='qcow2' cache='none'/> +   <source file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk'/> +   <target dev='vda' bus='virtio'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> +  </disk> +  <controller type='usb' index='0' model='piix3-uhci'> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> +  </controller> +  <controller type='pci' index='0' model='pci-root'/> +  <interface type='hostdev' managed='yes'> +   <mac address='fa:16:3e:aa:d9:23'/> +   <source> +    <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> +  </interface> +  <serial type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='isa-serial' port='0'> +    <model name='isa-serial'/> +   </target> +  </serial> +  <console type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='serial' port='0'/> +  </console> +  <input type='tablet' bus='usb'> +   <address type='usb' bus='0' port='1'/> +  </input> +  <input type='mouse' bus='ps2'/> +  <input type='keyboard' bus='ps2'/> +  <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> +   <listen type='address' address='0.0.0.0'/> +  </graphics> +  <audio id='1' type='none'/> +  <video> +   <model type='virtio' heads='1' primary='yes'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> +  </video> +  <hostdev mode='subsystem' type='pci' managed='yes'> +   <source> +    <address domain='0x0000' bus='0x01' slot='0x00' function='0x6'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> +  </hostdev> +  <memballoon model='virtio'> +   <stats period='10'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> +  </memballoon> +  <rng model='virtio'> +   <backend model='random'>/dev/urandom</backend> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> +  </rng> + </devices> +</domain> +``` +---- +Simon Jones + +This is full ERROR log +2023-03-23 08:00:52.362+0000: starting up libvirt version: 8.0.0, package: 1ubuntu7.4 (Christian Ehrhardt < +christian.ehrhardt@canonical.com +> Tue, 22 Nov 2022 15:59:28 +0100), qemu version: 6.2.0Debian 1:6.2+dfsg-2ubuntu6.6, kernel: 5.19.0-35-generic, hostname: c1c2 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \ +HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=instance-0000000e,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-4-instance-0000000e/master-key.aes"}' \ +-machine pc-i440fx-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel kvm \ +-cpu Cooperlake,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,sha-ni=on,umip=on,waitpkg=on,gfni=on,vaes=on,vpclmulqdq=on,rdpid=on,movdiri=on,movdir64b=on,fsrm=on,md-clear=on,avx-vnni=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,hle=off,rtm=off,avx512f=off,avx512dq=off,avx512cd=off,avx512bw=off,avx512vl=off,avx512vnni=off,avx512-bf16=off,taa-no=off \ +-m 64 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":67108864}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,dies=1,cores=1,threads=1 \ +-uuid ff91d2dc-69a1-43ef-abde-c9e4e9a0305b \ +-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=25.1.0,serial=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,uuid=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,family=Virtual Machine' \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-boot strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/_base/8b58db82a488248e7c5e769599954adaa47a5314","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-add-fd set=1,fd=34 \ +-chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-device usb-tablet,id=input0,bus=usb.0,port=1 \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc +0.0.0.0:0 +,audiodev=audio1 \ +-device virtio-vga,id=video0,max_outputs=1,bus=pci.0,addr=0x2 \ +-device vfio-pci,host=0000:01:00.5,id=hostdev0,bus=pci.0,addr=0x4 \ +-device vfio-pci,host=0000:01:00.6,id=hostdev1,bus=pci.0,addr=0x5 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x7 \ +-device vmcoreinfo \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/3 (label charserial0) +2023-03-23T08:00:53.728550Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-23 08:00:54.201+0000: shutting down, reason=crashed +2023-03-23 08:54:43.468+0000: starting up libvirt version: 8.0.0, package: 1ubuntu7.4 (Christian Ehrhardt < +christian.ehrhardt@canonical.com +> Tue, 22 Nov 2022 15:59:28 +0100), qemu version: 6.2.0Debian 1:6.2+dfsg-2ubuntu6.6, kernel: 5.19.0-35-generic, hostname: c1c2 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \ +HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=instance-0000000e,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-5-instance-0000000e/master-key.aes"}' \ +-machine pc-i440fx-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram \ +-accel kvm \ +-cpu Cooperlake,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,sha-ni=on,umip=on,waitpkg=on,gfni=on,vaes=on,vpclmulqdq=on,rdpid=on,movdiri=on,movdir64b=on,fsrm=on,md-clear=on,avx-vnni=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,hle=off,rtm=off,avx512f=off,avx512dq=off,avx512cd=off,avx512bw=off,avx512vl=off,avx512vnni=off,avx512-bf16=off,taa-no=off \ +-m 64 \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":67108864}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,dies=1,cores=1,threads=1 \ +-uuid ff91d2dc-69a1-43ef-abde-c9e4e9a0305b \ +-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=25.1.0,serial=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,uuid=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,family=Virtual Machine' \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-boot strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/_base/8b58db82a488248e7c5e769599954adaa47a5314","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-add-fd set=1,fd=34 \ +-chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-device usb-tablet,id=input0,bus=usb.0,port=1 \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc +0.0.0.0:0 +,audiodev=audio1 \ +-device virtio-vga,id=video0,max_outputs=1,bus=pci.0,addr=0x2 \ +-device vfio-pci,host=0000:01:00.5,id=hostdev0,bus=pci.0,addr=0x4 \ +-device vfio-pci,host=0000:01:00.6,id=hostdev1,bus=pci.0,addr=0x5 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \ +-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x7 \ +-device vmcoreinfo \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/3 (label charserial0) +2023-03-23T08:54:44.755039Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-23 08:54:45.230+0000: shutting down, reason=crashed +---- +Simon Jones +Simon Jones < +batmanustc@gmail.com +> äº2023å¹´3æ23æ¥å¨å 05:49åéï¼ +This is happened in ubuntu22.04. +QEMU is install by apt like this: +apt install -y qemu qemu-kvm qemu-system +and QEMU version is 6.2.0 +---- +Simon Jones +Simon Jones < +batmanustc@gmail.com +> äº2023å¹´3æ21æ¥å¨äº 08:40åéï¼ +Hi all, +I start a VM in openstack, and openstack use libvirt to start qemu VM, but now log show this ERROR. +Is there any one know this? +The ERROR log from /var/log/libvirt/qemu/instance-0000000e.log +``` +2023-03-14T10:09:17.674114Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument +kvm_set_phys_mem: error registering slot: Invalid argument +2023-03-14 10:09:18.198+0000: shutting down, reason=crashed +``` +The xml file +``` +root@c1c2:~# cat /etc/libvirt/qemu/instance-0000000e.xml +<!-- +WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE +OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: + virsh edit instance-0000000e +or other application using the libvirt API. +--> +<domain type='kvm'> + <name>instance-0000000e</name> + <uuid>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</uuid> + <metadata> +  <nova:instance xmlns:nova=" +http://openstack.org/xmlns/libvirt/nova/1.1 +"> +   <nova:package version="25.1.0"/> +   <nova:name>provider-instance</nova:name> +   <nova:creationTime>2023-03-14 10:09:13</nova:creationTime> +   <nova:flavor name="cirros-os-dpu-test-1"> +    <nova:memory>64</nova:memory> +    <nova:disk>1</nova:disk> +    <nova:swap>0</nova:swap> +    <nova:ephemeral>0</nova:ephemeral> +    <nova:vcpus>1</nova:vcpus> +   </nova:flavor> +   <nova:owner> +    <nova:user uuid="ff627ad39ed94479b9c5033bc462cf78">admin</nova:user> +    <nova:project uuid="512866f9994f4ad8916d8539a7cdeec9">admin</nova:project> +   </nova:owner> +   <nova:root type="image" uuid="9e58cb69-316a-4093-9f23-c1d1bd8edffe"/> +   <nova:ports> +    <nova:port uuid="77c1dc00-af39-4463-bea0-12808f4bc340"> +     <nova:ip type="fixed" address="172.1.1.43" ipVersion="4"/> +    </nova:port> +   </nova:ports> +  </nova:instance> + </metadata> + <memory unit='KiB'>65536</memory> + <currentMemory unit='KiB'>65536</currentMemory> + <vcpu placement='static'>1</vcpu> + <sysinfo type='smbios'> +  <system> +   <entry name='manufacturer'>OpenStack Foundation</entry> +   <entry name='product'>OpenStack Nova</entry> +   <entry name='version'>25.1.0</entry> +   <entry name='serial'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='uuid'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry> +   <entry name='family'>Virtual Machine</entry> +  </system> + </sysinfo> + <os> +  <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type> +  <boot dev='hd'/> +  <smbios mode='sysinfo'/> + </os> + <features> +  <acpi/> +  <apic/> +  <vmcoreinfo state='on'/> + </features> + <cpu mode='host-model' check='partial'> +  <topology sockets='1' dies='1' cores='1' threads='1'/> + </cpu> + <clock offset='utc'> +  <timer name='pit' tickpolicy='delay'/> +  <timer name='rtc' tickpolicy='catchup'/> +  <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> +  <emulator>/usr/bin/qemu-system-x86_64</emulator> +  <disk type='file' device='disk'> +   <driver name='qemu' type='qcow2' cache='none'/> +   <source file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk'/> +   <target dev='vda' bus='virtio'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> +  </disk> +  <controller type='usb' index='0' model='piix3-uhci'> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> +  </controller> +  <controller type='pci' index='0' model='pci-root'/> +  <interface type='hostdev' managed='yes'> +   <mac address='fa:16:3e:aa:d9:23'/> +   <source> +    <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> +  </interface> +  <serial type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='isa-serial' port='0'> +    <model name='isa-serial'/> +   </target> +  </serial> +  <console type='pty'> +   <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/> +   <target type='serial' port='0'/> +  </console> +  <input type='tablet' bus='usb'> +   <address type='usb' bus='0' port='1'/> +  </input> +  <input type='mouse' bus='ps2'/> +  <input type='keyboard' bus='ps2'/> +  <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'> +   <listen type='address' address='0.0.0.0'/> +  </graphics> +  <audio id='1' type='none'/> +  <video> +   <model type='virtio' heads='1' primary='yes'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> +  </video> +  <hostdev mode='subsystem' type='pci' managed='yes'> +   <source> +    <address domain='0x0000' bus='0x01' slot='0x00' function='0x6'/> +   </source> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> +  </hostdev> +  <memballoon model='virtio'> +   <stats period='10'/> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> +  </memballoon> +  <rng model='virtio'> +   <backend model='random'>/dev/urandom</backend> +   <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> +  </rng> + </devices> +</domain> +``` +---- +Simon Jones + diff --git a/results/classifier/118/unknown/1050694 b/results/classifier/118/unknown/1050694 new file mode 100644 index 00000000..7050e233 --- /dev/null +++ b/results/classifier/118/unknown/1050694 @@ -0,0 +1,114 @@ +mistranslation: 0.907 +risc-v: 0.891 +i386: 0.886 +debug: 0.884 +arm: 0.882 +user-level: 0.880 +hypervisor: 0.877 +permissions: 0.870 +PID: 0.865 +virtual: 0.865 +performance: 0.864 +semantic: 0.864 +graphic: 0.863 +ppc: 0.862 +register: 0.861 +architecture: 0.859 +device: 0.857 +assembly: 0.852 +boot: 0.843 +socket: 0.843 +TCG: 0.839 +peripherals: 0.837 +files: 0.836 +vnc: 0.833 +kernel: 0.830 +x86: 0.829 +VMM: 0.824 +KVM: 0.818 +network: 0.807 + +Interrupt 0xffffffff when debug is turned on + +Hi, + +I have been getting a GPF when I enable interrupts, working on implementing processes and a scheduler. When I comment out the scheduler code, I still get the GPF. I used the following QEMU command line to capture a log: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + +Rather than posting the entire log, I need some help interpreting the following section (notice "INT=0xffffffff" on the top line): +Servicing hardware INT=0xffffffff +1: v=ffffffff e=0000 i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 +check_exception old: 0xffffffff new 0xd +2: v=0d e=fffffffa i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 + +To the best of my ability to interpret, I an getting an undefined interrupt, which is then triggering a GPF, which is caught. However, do not know where it might be coming from. + +Some additional information: + + +This command works: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -s -hda "$harddisk_image" -m 3.5G + + +This command works: + +qemu-system-i386 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +And, as above, this does not: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +[adam@os-development ~]$ qemu-system-i386 -version +QEMU emulator version 1.2.0, Copyright (c) 2003-2008 Fabrice Bellard + + +Attached is an image as a test case. Please let me know if you need any additional information. + + + +Original conversation about this issue on osdev.org: http://forum.osdev.org/viewtopic.php?f=1&t=25795 + +Triaging old bug tickets ... is there still something left to do here, or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1052 b/results/classifier/118/unknown/1052 new file mode 100644 index 00000000..bb8c6022 --- /dev/null +++ b/results/classifier/118/unknown/1052 @@ -0,0 +1,109 @@ +ppc: 0.908 +register: 0.898 +VMM: 0.893 +permissions: 0.891 +graphic: 0.888 +hypervisor: 0.887 +debug: 0.886 +performance: 0.881 +peripherals: 0.881 +vnc: 0.874 +TCG: 0.870 +semantic: 0.863 +KVM: 0.862 +device: 0.854 +virtual: 0.854 +x86: 0.851 +mistranslation: 0.842 +i386: 0.840 +architecture: 0.833 +assembly: 0.810 +PID: 0.809 +arm: 0.800 +risc-v: 0.799 +kernel: 0.786 +socket: 0.785 +user-level: 0.779 +network: 0.773 +boot: 0.762 +files: 0.754 + +QEMU monitor hangs after "stop" QMP command called in postcopy-paused migration state +Description of problem: +QEMU monitor hangs when I try to pause virtual CPUs using "stop" QMP command +on the destination host once migration enters postcopy-paused (after it was +paused using "migrate-pause" QMP command on the source host). QEMU just does +not send any reply to the "stop" command. +Steps to reproduce: +1. start migration +2. wait for the first iteration to finish +3. switch to post-copy using "migrate-start-postcopy" +3. break migration with "migrate-pause" +4. send "stop" to the destination monitor +Additional information: +Unfortunately I haven't been able to get a stack trace as gdb just hangs when +I try to attach it to QEMU after step 4. I can see threads getting SIGUSR1 +after the "stop" command, but I cannot get to gdb prompt afterwards: + +``` +(gdb) c +Continuing. +[New Thread 0x7f41ec9be640 (LWP 1112)] +[New Thread 0x7f41d7fff640 (LWP 1113)] +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 5 "CPU 1/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +Thread 4 "CPU 0/KVM" received signal SIGUSR1, User defined signal 1. +``` + +I was able to attach strace to it though (in case it is at least a bit +useful). The first line corresponds to the final '}' of the +{"execute":"stop","id":"libvirt-413"} QMP comamnd: + +``` +[pid 72970] recvmsg(20, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="}", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 1 +[pid 72970] write(4, "\1\0\0\0\0\0\0\0", 8) = 8 +[pid 72949] <... ppoll resumed>) = 1 ([{fd=4, revents=POLLIN}], left {tv_sec=0, tv_nsec=513181335}) +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] read(4, <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... read resumed>"\1\0\0\0\0\0\0\0", 512) = 8 +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}, {fd=46, events=POLLIN}, {fd=47, events=POLLIN}, {fd=48, events=POLLIN}, {fd=49, events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=POLLIN}, {fd=52, events=POLLIN}, {fd=53, events=POLLIN}, {fd=54, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, ...], 74, {tv_sec=0, tv_nsec=0}, NULL, 8 <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... ppoll resumed>) = 0 (Timeout) +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] write(8, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... write resumed>) = 8 +[pid 72970] write(19, "\1\0\0\0\0\0\0\0", 8 <unfinished ...> +[pid 72949] ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=31, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=41, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}, {fd=44, events=POLLIN}, {fd=45, events=POLLIN}, {fd=46, events=POLLIN}, {fd=47, events=POLLIN}, {fd=48, events=POLLIN}, {fd=49, events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=POLLIN}, {fd=52, events=POLLIN}, {fd=53, events=POLLIN}, {fd=54, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, ...], 74, {tv_sec=0, tv_nsec=0}, NULL, 8 <unfinished ...> +[pid 72970] <... write resumed>) = 8 +[pid 72949] <... ppoll resumed>) = 1 ([{fd=8, revents=POLLIN}], left {tv_sec=0, tv_nsec=0}) +[pid 72970] poll([{fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=0}], 3, -1 <unfinished ...> +[pid 72949] rt_sigprocmask(SIG_BLOCK, ~[], <unfinished ...> +[pid 72970] <... poll resumed>) = 1 ([{fd=19, revents=POLLIN}]) +[pid 72949] <... rt_sigprocmask resumed>[BUS USR1 ALRM IO], 8) = 0 +[pid 72970] read(19, <unfinished ...> +[pid 72949] getpid() = 72949 +[pid 72970] <... read resumed>"\5\0\0\0\0\0\0\0", 16) = 8 +[pid 72949] tgkill(72949, 72971, SIGUSR1 <unfinished ...> +[pid 72970] poll([{fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=0}], 3, -1 <unfinished ...> +[pid 72949] <... tgkill resumed>) = 0 +[pid 72949] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0 +[pid 72949] rt_sigprocmask(SIG_BLOCK, ~[], [BUS USR1 ALRM IO], 8) = 0 +[pid 72949] getpid() = 72949 +[pid 72949] tgkill(72949, 72972, SIGUSR1) = 0 +[pid 72949] rt_sigprocmask(SIG_SETMASK, [BUS USR1 ALRM IO], NULL, 8) = 0 +[pid 72949] futex(0x5606f6cb73a8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY +``` + +And that's it, the last futex never returns. diff --git a/results/classifier/118/unknown/1079713 b/results/classifier/118/unknown/1079713 new file mode 100644 index 00000000..04539c83 --- /dev/null +++ b/results/classifier/118/unknown/1079713 @@ -0,0 +1,305 @@ +user-level: 0.909 +debug: 0.881 +virtual: 0.874 +register: 0.866 +files: 0.864 +graphic: 0.864 +mistranslation: 0.859 +network: 0.859 +assembly: 0.858 +architecture: 0.856 +permissions: 0.855 +device: 0.855 +boot: 0.853 +performance: 0.851 +PID: 0.850 +semantic: 0.846 +kernel: 0.843 +KVM: 0.842 +arm: 0.839 +hypervisor: 0.820 +vnc: 0.819 +socket: 0.818 +peripherals: 0.817 +risc-v: 0.811 +x86: 0.788 +ppc: 0.788 +TCG: 0.781 +VMM: 0.775 +i386: 0.743 + +failed to set sndbuf on VMs network interface + +I am trying to set "sndbuf" for a VMs network device to "0". +I inserted to my XML file: + <tune> + <sndbuf>0</sndbuf> + </tune> +The XML file validates, but I am not able to start the virtual machine. + +# virsh edit vm3 +<domain type='kvm'> + <name>vm3</name> + <uuid><HIDDEN></uuid> + <memory unit='KiB'>524288</memory> + <currentMemory unit='KiB'>524288</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc-1.2'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='<HIDDEN>'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <interface type='bridge'> + <mac address='<HIDDEN>'/> + <source bridge='br2'/> + <model type='virtio'/> + <tune> + <sndbuf>0</sndbuf> + </tune> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <target port='0'/> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='-1' autoport='yes'/> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='cirrus' vram='9216' heads='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> +</domain> + +Domain vm3 XML configuration edited. + +# LANG=en_US.utf-8 virsh start vm3 +error: Failed to start domain vm3 +error: internal error Process exited while reading console log output: char device redirected to /dev/pts/4 + + + + + +Thanks for reporting this bug. This is a reqression in qemu-kvm since precise. In precise, the following works fine (meaning, kvm starts up - no idea if it does what it should): + +kvm -vnc :1 -cdrom raring-mini-amd64.iso -hda raring.img -net nic,model=virtio -net tap,script=no,downscript=no,ifname=tap0,sndbuf=0 + +In raring (and presumably quantal) it gives a segfault + +Latest upstream qemu.git still reproduces this, so marking it as affecting QEMU. + +On Mon, Nov 26, 2012 at 1:43 PM, Andreas Färber <email address hidden> wrote: +> Am 26.11.2012 13:10, schrieb Stefan Hajnoczi: +>> visit_type_size() requires either visitor->type_size() or +>> visitor_uint64() to be implemented, otherwise a NULL function pointer is +>> invoked. +>> +>> It is possible to trigger this crash as follows: +>> +>> $ qemu-system-x86_64 -netdev tap,sndbuf=0,id=netdev0 \ +>> -device virtio-blk-pci,netdev=netdev0 +>> +>> The 'sndbuf' option has type "size". +>> +>> Signed-off-by: Stefan Hajnoczi <email address hidden> +>> --- +>> This patch ensures that -netdev tap,sndbuf=X works in QEMU 1.3. +> +> Reviewed-by: Andreas Färber <email address hidden> +> +> Did you check whether any other types were unhandled? + +The visitors do not handle all types. Only the opts visitor and now +the dealloc visitor handle ->type_size(). + +This will not cause a problem yet because only the netdev options +include fields with the 'size' type. That code path is now covered. + +In the longer term we should clean up the int, number, uint64, size +type proliferation and handle them consistently. + +> Should a comment be added somewhere along the lines of "If you add a +> hook here you also need to implement one there" to avoid such +> inconsistency for the future? + +There is no single point like register_visitor() where we could check +that callbacks are set up. That would have been a nice way to prevent +incomplete visitors. + +The issue is that qapi/qapi-visit-core.h says type_uint64 and +type_size may be NULL, but it documents that visit_type_size() falls +back to type_uint64() if type_size() is NULL. The case we hit was +that type_uint64() is also NULL. Should it fall back to type_int() +(int64_t)? + +Stefan + + +On Mon, Nov 26, 2012 at 02:22:58PM +0100, Stefan Hajnoczi wrote: +> On Mon, Nov 26, 2012 at 1:43 PM, Andreas Färber <email address hidden> wrote: +> > Am 26.11.2012 13:10, schrieb Stefan Hajnoczi: +> >> visit_type_size() requires either visitor->type_size() or +> >> visitor_uint64() to be implemented, otherwise a NULL function pointer is +> >> invoked. +> >> +> >> It is possible to trigger this crash as follows: +> >> +> >> $ qemu-system-x86_64 -netdev tap,sndbuf=0,id=netdev0 \ +> >> -device virtio-blk-pci,netdev=netdev0 +> >> +> >> The 'sndbuf' option has type "size". +> >> +> >> Signed-off-by: Stefan Hajnoczi <email address hidden> +> >> --- +> >> This patch ensures that -netdev tap,sndbuf=X works in QEMU 1.3. +> > +> > Reviewed-by: Andreas Färber <email address hidden> +> > +> > Did you check whether any other types were unhandled? +> +> The visitors do not handle all types. Only the opts visitor and now +> the dealloc visitor handle ->type_size(). +> +> This will not cause a problem yet because only the netdev options +> include fields with the 'size' type. That code path is now covered. +> +> In the longer term we should clean up the int, number, uint64, size +> type proliferation and handle them consistently. + +Dealloc visitor is somewhat of a special case, as it only cares about +the underlying C type and not about the visitor-specific representation. +In the case of generated types like these, it only needs to match the +type that QAPI generates (uint64_t in the case of type_size). + +For input/output visitors, new types should either have a compatible +fallback, or abort if there's no compatible fallback and we attempt to +use a visitor that doesn't support the type. AFAIK we don't have one +that falls into the latter category atm (there is one in the QIDL series +for native C arrays, which has no generic fallback and will abort in +cases where we use a visitor that doesn't implement that type +explicitly). + +Dealloc shouldn't use compatibility fallbacks though, which is probably +something we need to clean up. It should have explicit implementations +for all types we introduce, and those implementations should match the +type use for QAPI-generated types. + +> +> > Should a comment be added somewhere along the lines of "If you add a +> > hook here you also need to implement one there" to avoid such +> > inconsistency for the future? +> +> There is no single point like register_visitor() where we could check +> that callbacks are set up. That would have been a nice way to prevent +> incomplete visitors. +> +> The issue is that qapi/qapi-visit-core.h says type_uint64 and +> type_size may be NULL, but it documents that visit_type_size() falls +> back to type_uint64() if type_size() is NULL. The case we hit was +> that type_uint64() is also NULL. Should it fall back to type_int() +> (int64_t)? + +I hit this issue implementing a test case for QIDL that introduces +the usage of type_size() for QmpOutputVisitor. The problem is that it +references ->type_uint64() directly instead of using visit_type_uint64() +which has the fallback handling (->type_int()) for visitors that don't +have a specific implementation for type_uint64. + +I have a patch in the QIDL series that does this, and this would also fix the +issue you're hitting with the dealloc visitor, but as noted above I +think relying on fallbacks for the dealloc visitor is the wrong +approach, so I think we should treat these as 2 seperate issues and take +your patch for 1.3. The error case I hit isn't reachable in 1.3 atm so I +think that should be sufficient for now. + +> +> Stefan +> + + +On Mon, Nov 26, 2012 at 01:10:12PM +0100, Stefan Hajnoczi wrote: +> visit_type_size() requires either visitor->type_size() or +> visitor_uint64() to be implemented, otherwise a NULL function pointer is +> invoked. +> +> It is possible to trigger this crash as follows: +> +> $ qemu-system-x86_64 -netdev tap,sndbuf=0,id=netdev0 \ +> -device virtio-blk-pci,netdev=netdev0 +> +> The 'sndbuf' option has type "size". +> +> Signed-off-by: Stefan Hajnoczi <email address hidden> + +Reviewed-by: Michael Roth <email address hidden> + +> --- +> This patch ensures that -netdev tap,sndbuf=X works in QEMU 1.3. +> +> qapi/qapi-dealloc-visitor.c | 6 ++++++ +> 1 file changed, 6 insertions(+) +> +> diff --git a/qapi/qapi-dealloc-visitor.c b/qapi/qapi-dealloc-visitor.c +> index a154523..a07b171 100644 +> --- a/qapi/qapi-dealloc-visitor.c +> +++ b/qapi/qapi-dealloc-visitor.c +> @@ -132,6 +132,11 @@ static void qapi_dealloc_type_number(Visitor *v, double *obj, const char *name, +> { +> } +> +> +static void qapi_dealloc_type_size(Visitor *v, size_t *obj, const char *name, +> + Error **errp) +> +{ +> +} +> + +> static void qapi_dealloc_type_enum(Visitor *v, int *obj, const char *strings[], +> const char *kind, const char *name, +> Error **errp) +> @@ -164,6 +169,7 @@ QapiDeallocVisitor *qapi_dealloc_visitor_new(void) +> v->visitor.type_bool = qapi_dealloc_type_bool; +> v->visitor.type_str = qapi_dealloc_type_str; +> v->visitor.type_number = qapi_dealloc_type_number; +> + v->visitor.type_size = qapi_dealloc_type_size; +> +> QTAILQ_INIT(&v->stack); +> +> -- +> 1.8.0 +> +> + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1082 b/results/classifier/118/unknown/1082 new file mode 100644 index 00000000..e43e7914 --- /dev/null +++ b/results/classifier/118/unknown/1082 @@ -0,0 +1,122 @@ +graphic: 0.859 +virtual: 0.852 +hypervisor: 0.840 +debug: 0.836 +network: 0.830 +peripherals: 0.821 +register: 0.819 +architecture: 0.817 +TCG: 0.810 +permissions: 0.807 +socket: 0.806 +user-level: 0.798 +mistranslation: 0.797 +device: 0.774 +assembly: 0.762 +kernel: 0.755 +i386: 0.748 +semantic: 0.739 +arm: 0.737 +performance: 0.734 +ppc: 0.732 +vnc: 0.729 +PID: 0.728 +x86: 0.716 +files: 0.711 +boot: 0.705 +VMM: 0.700 +KVM: 0.689 +risc-v: 0.668 + +Unable to compile QEMU in Ubuntu 22.04 LTS - libcommon.fa.p +Description of problem: +Since a couple of months ago I can not compile QEMU from its official GIT location anymore. +I do everything described in the guide: https://wiki.qemu.org/Hosts/Linux + +After the configure, the building resturn me this issue: +``` +1155/9661] Compiling C object libcommon.fa.p/ui_vdagent.c.o +FAILED: libcommon.fa.p/ui_vdagent.c.o +cc -m64 -mcx16 -Ilibcommon.fa.p -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -I../slirp -I../slirp/src -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/local/include/spice-1 -I/usr/include/p11-kit-1 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0 -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/atk-1.0 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu -I/usr/include/vte-2.91 -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/andrea/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/andrea/qemu -iquote /home/andrea/qemu/include -iquote /home/andrea/qemu/disas/libvixl -iquote /home/andrea/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -MD -MQ libcommon.fa.p/ui_vdagent.c.o -MF libcommon.fa.p/ui_vdagent.c.o.d -o libcommon.fa.p/ui_vdagent.c.o -c ../ui/vdagent.c +../ui/vdagent.c:82:6: error: ‘VD_AGENT_CAP_SPARSE_MONITORS_CONFIG’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_MONITORS_CONFIG’? + 82 | [VD_AGENT_CAP_SPARSE_MONITORS_CONFIG] = "sparse-monitors-config", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CAP_MONITORS_CONFIG +../ui/vdagent.c:82:6: error: array index in initializer not of integer type +../ui/vdagent.c:82:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:83:6: error: ‘VD_AGENT_CAP_GUEST_LINEEND_LF’ undeclared here (not in a function) + 83 | [VD_AGENT_CAP_GUEST_LINEEND_LF] = "guest-lineend-lf", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:83:6: error: array index in initializer not of integer type +../ui/vdagent.c:83:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:84:6: error: ‘VD_AGENT_CAP_GUEST_LINEEND_CRLF’ undeclared here (not in a function) + 84 | [VD_AGENT_CAP_GUEST_LINEEND_CRLF] = "guest-lineend-crlf", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:84:6: error: array index in initializer not of integer type +../ui/vdagent.c:84:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:85:6: error: ‘VD_AGENT_CAP_MAX_CLIPBOARD’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_CLIPBOARD’? + 85 | [VD_AGENT_CAP_MAX_CLIPBOARD] = "max-clipboard", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CAP_CLIPBOARD +../ui/vdagent.c:85:6: error: array index in initializer not of integer type +../ui/vdagent.c:85:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:86:6: error: ‘VD_AGENT_CAP_AUDIO_VOLUME_SYNC’ undeclared here (not in a function) + 86 | [VD_AGENT_CAP_AUDIO_VOLUME_SYNC] = "audio-volume-sync", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:86:6: error: array index in initializer not of integer type +../ui/vdagent.c:86:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:87:6: error: ‘VD_AGENT_CAP_MONITORS_CONFIG_POSITION’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_MONITORS_CONFIG’? + 87 | [VD_AGENT_CAP_MONITORS_CONFIG_POSITION] = "monitors-config-position", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CAP_MONITORS_CONFIG +../ui/vdagent.c:87:6: error: array index in initializer not of integer type +../ui/vdagent.c:87:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:88:6: error: ‘VD_AGENT_CAP_FILE_XFER_DISABLED’ undeclared here (not in a function) + 88 | [VD_AGENT_CAP_FILE_XFER_DISABLED] = "file-xfer-disabled", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:88:6: error: array index in initializer not of integer type +../ui/vdagent.c:88:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:89:6: error: ‘VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS’ undeclared here (not in a function) + 89 | [VD_AGENT_CAP_FILE_XFER_DETAILED_ERRORS] = "file-xfer-detailed-errors", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:89:6: error: array index in initializer not of integer type +../ui/vdagent.c:89:6: note: (near initialization for ‘cap_name’) +../ui/vdagent.c:109:6: error: ‘VD_AGENT_FILE_XFER_START’ undeclared here (not in a function) + 109 | [VD_AGENT_FILE_XFER_START] = "file-xfer-start", + | ^~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:109:6: error: array index in initializer not of integer type +../ui/vdagent.c:109:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:110:6: error: ‘VD_AGENT_FILE_XFER_STATUS’ undeclared here (not in a function) + 110 | [VD_AGENT_FILE_XFER_STATUS] = "file-xfer-status", + | ^~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:110:6: error: array index in initializer not of integer type +../ui/vdagent.c:110:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:111:6: error: ‘VD_AGENT_FILE_XFER_DATA’ undeclared here (not in a function) + 111 | [VD_AGENT_FILE_XFER_DATA] = "file-xfer-data", + | ^~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:111:6: error: array index in initializer not of integer type +../ui/vdagent.c:111:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:112:6: error: ‘VD_AGENT_CLIENT_DISCONNECTED’ undeclared here (not in a function) + 112 | [VD_AGENT_CLIENT_DISCONNECTED] = "client-disconnected", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:112:6: error: array index in initializer not of integer type +../ui/vdagent.c:112:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:113:6: error: ‘VD_AGENT_MAX_CLIPBOARD’ undeclared here (not in a function); did you mean ‘VD_AGENT_CAP_CLIPBOARD’? + 113 | [VD_AGENT_MAX_CLIPBOARD] = "max-clipboard", + | ^~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CAP_CLIPBOARD +../ui/vdagent.c:113:6: error: array index in initializer not of integer type +../ui/vdagent.c:113:6: note: (near initialization for ‘msg_name’) +../ui/vdagent.c:114:6: error: ‘VD_AGENT_AUDIO_VOLUME_SYNC’ undeclared here (not in a function) + 114 | [VD_AGENT_AUDIO_VOLUME_SYNC] = "audio-volume-sync", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +../ui/vdagent.c:114:6: error: array index in initializer not of integer type +../ui/vdagent.c:114:6: note: (near initialization for ‘msg_name’) +``` + +I come from a Windows world, so I have no idea what is the "libcommon.fa.p" about. +Can someone help here? +Steps to reproduce: +1. Follow the instruction in https://wiki.qemu.org/Hosts/Linux to compile QEMU +Expected result: QEMU would compile correctly +Observed result: Compilation errors. diff --git a/results/classifier/118/unknown/1089006 b/results/classifier/118/unknown/1089006 new file mode 100644 index 00000000..a968fe58 --- /dev/null +++ b/results/classifier/118/unknown/1089006 @@ -0,0 +1,215 @@ +risc-v: 0.892 +register: 0.882 +user-level: 0.877 +virtual: 0.875 +x86: 0.874 +hypervisor: 0.872 +boot: 0.870 +mistranslation: 0.866 +debug: 0.851 +device: 0.850 +KVM: 0.847 +peripherals: 0.847 +arm: 0.839 +graphic: 0.838 +architecture: 0.836 +PID: 0.835 +assembly: 0.832 +performance: 0.831 +network: 0.828 +semantic: 0.828 +TCG: 0.822 +vnc: 0.812 +socket: 0.810 +ppc: 0.809 +kernel: 0.808 +VMM: 0.803 +permissions: 0.792 +i386: 0.777 +files: 0.754 + +Qemu scrambles order of eth devices in vm + +HV = 12.04 LTS plus libvirt 1.0x +VM = 12.04 LTS + +On the HV there are 12 eth interfaces which we make available to the VM. We have 4 10G virtual function interfaces, and 8 1G conventionally bridged interfaces. No matter what order we present the interfaces in the xml file, they come up in eth0-eth11 order on the VM as follows: ( the interfcaes do work, once you figure out which is which) + +eth0-eth7 not in order as compoared to the bridges on the HV (interfaces file) or compared to the xml file for the VM, or compared to the bus numbers. MAC addresses are random. +eth8-eth11 show up in the VM in order of PCU bus numbers just as you'd expect, always after the bridged interfaces. + +Consulting the libvirt mailing list, the developer says they present the list in bus order to qemu, but qemu scrambles that order. That appears to me too, to be the case. + +There is really no such concept as "NIC order" at the hardware level in QEMU. NIC naming order is something that operating systems invent according to some policy they have. As far as libvirt & QEMU are concerned, you only have control over the PCI device slot numbering. The operating system may choose to number NICs based on their PCI device slot number, or something else entirely. Further after an OS has been booted once, they often record the original mapping of MAC <-> NIC names, so even if you change the PCI slot ordering on later boots, the naming won't change. + +Thank you Daniel. +I understand what you say and agree. However when presented with a mapping and an order by libvirt, shouldn't the order be preserved by default? If the OS scrambles it, then fine, not your problem... + +Are we on the right track here, is there some way to control the order as presented by Qemu when the VM's OS boots? + +If its at all helpful to understand the issue, here is our current proposed workaround: +=start 32 fresh VMs, each with 8 bridged connections and 4 82599 virtual connections= +take one generic xml file +qemu-img one default disk image +examine the HV's lspci output to find out bus numbering for the 82599 virtuals +add correct bus numbering in xml file +virsh create the xml to get randomized MAC addresses ( better ways to do this...) +save xml again +shutdown VM +> heres where the workaround occurs < +mount VM +write to /etc/udev/rules.d file to capture MAC vs PCI numbering in order of presentation for booting +etc etc + +For the benefit of 1) others and 2) me when I forget how this works- + +I did find a solution in formatting the xml file. + +If you leave the vnets out completely, see file below, the generic xml file will cooperate with libvirt and qemu and +order the VM's eth devices as they are ordered on the hypervisor. + +(note: the macvtap entries seen below may also not be needed, sound and usb not tested) + +## sample xml file for libvirt 1.0.0 showing some bridges and some SRIOV ports too ## + +<domain type='kvm' id='1'> + <name>sample</name> + <hostname>sample</hostname> + <memory unit='KiB'>524288</memory> + <currentMemory unit='KiB'>524288</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc-1.0'>hvm</type> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/oa4-vm-sample-cli.qcow2'/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <controller type='usb' index='0'> + <alias name='usb0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <interface type='bridge'> + <source bridge='br4'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br5'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br6'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br7'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br8'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br9'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br10'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br11'/> + <model type='virtio'/> + </interface> + <interface type='bridge'> + <source bridge='br250'/> + <model type='virtio'/> + </interface> + <interface type='hostdev'> + <source dev='eth0' mode='vepa'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x0'/> + </source> + <target dev='macvtap1'/> + <model type='virtio'/> + </interface> + <interface type='hostdev'> + <source dev='eth1' mode='vepa'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x1'/> + </source> + <target dev='macvtap1'/> + <model type='virtio'/> + </interface> + <interface type='hostdev'> + <source dev='eth2' mode='vepa'> + <address type='pci' domain='0x0000' bus='0x16' slot='0x10' function='0x0'/> + </source> + <target dev='macvtap0'/> + </interface> + <interface type='hostdev'> + <source dev='eth3' mode='vepa'> + <address type='pci' domain='0x0000' bus='0x16' slot='0x10' function='0x1'/> + </source> + <target dev='macvtap0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/1'/> + <target port='0'/> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/1'> + <source path='/dev/pts/1'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <input type='mouse' bus='ps2'/> + <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <sound model='ich6'> + <alias name='sound0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='cirrus' vram='9216' heads='1'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> + <seclabel type='none'/> +</domain> + + +On 12/12/2012 11:59 AM, john fisher wrote: +> +> Are we on the right track here, is there some way to control the order +> as presented by Qemu when the VM's OS boots? +> + +-- +John Fisher + + + +Is there still something left to do here, or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1102 b/results/classifier/118/unknown/1102 new file mode 100644 index 00000000..3e8ff7aa --- /dev/null +++ b/results/classifier/118/unknown/1102 @@ -0,0 +1,68 @@ +peripherals: 0.930 +VMM: 0.891 +x86: 0.887 +permissions: 0.885 +hypervisor: 0.876 +architecture: 0.875 +debug: 0.874 +TCG: 0.869 +files: 0.864 +register: 0.855 +device: 0.850 +performance: 0.847 +risc-v: 0.845 +PID: 0.841 +graphic: 0.834 +i386: 0.827 +vnc: 0.827 +socket: 0.824 +user-level: 0.813 +boot: 0.807 +arm: 0.791 +assembly: 0.785 +kernel: 0.785 +mistranslation: 0.783 +network: 0.782 +KVM: 0.774 +semantic: 0.764 +ppc: 0.763 +virtual: 0.743 + +qemu-user: zero_bss might raise segfault when segment is not writable +Description of problem: +When a PT_LOAD segment with the following attributes presented in the user program, +* MemSiz > FileSiz +* NOT Writable + +qemu-aarch64 will crash with segment fault running it. + + + + +in [linux-user/elfload.c: bss_zero](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L2097), the exceeded part is zero'ed without checking if it is writable +``` + if (host_start < host_map_start) { + memset((void *)host_start, 0, host_map_start - host_start); + } +``` +Steps to reproduce: +1. ./qemu-aarch64 ./X.so +Additional information: +readelf output of X.so +``` +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align + PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040 0x0000000000000230 0x0000000000000230 R E 0x8 + LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000110270 0x00000000001c94e0 R E 0x10000 + LOAD 0x0000000000129bd0 0x00000000001d9bd0 0x00000000001d9bd0 0x0000000000000438 0x00000000000004c0 RW 0x10000 + LOAD 0x000000000013a008 0x00000000001ea008 0x00000000001ea008 0x0000000000017bd0 0x0000000000017bd0 RW 0x10000 + LOAD 0x0000000000161bd8 0x0000000000211bd8 0x0000000000211bd8 0x000000000000f740 0x000000000000f740 RW 0x10000 + DYNAMIC 0x0000000000161e60 0x0000000000211e60 0x0000000000211e60 0x00000000000001e0 0x00000000000001e0 RW 0x8 + INTERP 0x0000000000089410 0x0000000000089410 0x0000000000089410 0x0000000000000015 0x0000000000000015 R 0x1 + [Requesting program interpreter: /system/bin/linker64] + NOTE 0x000000000013dbc8 0x00000000001edbc8 0x00000000001edbc8 0x0000000000000011 0x0000000000000011 R 0x1 + GNU_EH_FRAME 0x00000000001c86a4 0x00000000001c86a4 0x00000000001c86a4 0x00000000000002dc 0x00000000000002dc R 0x4 + GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 +``` + +X.so: https://drive.google.com/file/d/1A7mkWRcK2BKkpeevt8T6FVLg-t6mWdgi/view?usp=sharing diff --git a/results/classifier/118/unknown/1143 b/results/classifier/118/unknown/1143 new file mode 100644 index 00000000..6551540f --- /dev/null +++ b/results/classifier/118/unknown/1143 @@ -0,0 +1,108 @@ +permissions: 0.949 +peripherals: 0.939 +graphic: 0.934 +architecture: 0.933 +semantic: 0.919 +user-level: 0.914 +hypervisor: 0.911 +device: 0.910 +network: 0.908 +register: 0.904 +virtual: 0.904 +debug: 0.900 +performance: 0.887 +PID: 0.885 +files: 0.885 +assembly: 0.870 +KVM: 0.867 +vnc: 0.863 +TCG: 0.854 +arm: 0.839 +ppc: 0.827 +kernel: 0.804 +mistranslation: 0.803 +i386: 0.801 +boot: 0.792 +risc-v: 0.787 +x86: 0.784 +VMM: 0.778 +socket: 0.775 + +Breakpoints missed when a function is split into two memory pages. +Description of problem: +Qemu seems to ignore some breakpoints when the start of a function is +in another page than where the breakpoint is set. + +In my case, I've a function `__gnat_debug_raise_exception` which starts at `0x10bff2` and I've set with gdb a breakpoint at `0x10c00e` (in another page). +While running with `qemu -d in_asm,exec`, I can see that the whole function is executed at once and that no breakpoint is fired. + +``` +(gdb) b *0x00108fbc +(gdb) b *0x0010c00e +(gdb) target remote :1234 +(gdb) c + +Trace 0: 0x7f277c0174c0 [0000000000000000/0000000000108fb9/0040c0b0/ff000201] ada__exceptions__complete_occurrence +---------------- + +// gdb hits first breakpoint here. +Breakpoint 3, 0x0000000000108fbc .... +(gdb) ni + +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f277c000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp +0x0010bff3: 48 89 e5 movq %rsp, %rbp +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +0x0010bffa: 48 89 d1 movq %rdx, %rcx +0x0010bffd: 48 89 f0 movq %rsi, %rax +0x0010c000: 48 89 fa movq %rdi, %rdx +0x0010c003: 48 89 ca movq %rcx, %rdx +0x0010c006: 48 89 45 e0 movq %rax, -0x20(%rbp) +0x0010c00a: 48 89 55 e8 movq %rdx, -0x18(%rbp) +0x0010c00e: 48 8b 45 e0 movq -0x20(%rbp), %rax +0x0010c012: 90 nop +0x0010c013: 5d popq %rbp +0x0010c014: c3 retq + +Trace 0: 0x7f277c000100 [0000000000000000/000000000010bff2/0040c0b0/ff000000] __gnat_debug_raise_exception +Digging a bit more, it seems that it seems related to + +// gdb ni stop here. Breakpoints at 0x10c00e have been ignored. +``` + +Note that if I'm setting another breakpoint at `0x0010bffd` (thus not at the start of the function but still in the same page), the execution +will be executed step by step and the breakpoint at 0x10c00e will be triggered normally. + + +``` +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f6af4000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp + +Trace 0: 0x7f6af4000100 [0000000000000000/000000000010bff2/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff3: 48 89 e5 movq %rsp, %rbp + +Trace 0: 0x7f6af4000280 [0000000000000000/000000000010bff3/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +... +``` + +I've dug a bit into qemu translator code and I guess `check_for_breakpoint` should check that the whole function is in the same page before skipping step by step. But I'm not sure if it's possible because the TB is created after `check_for_breakpoint` IIUC. + +Sadly as of now, I don't have a C reproducer. I can try to provide you my "foo" program which is an Ada program. But maybe if you've a better idea how to reproduce that or an idea of to fix that, I'll be glad to help you. + +Thanks, +Clément diff --git a/results/classifier/118/unknown/1151986 b/results/classifier/118/unknown/1151986 new file mode 100644 index 00000000..d1d717ee --- /dev/null +++ b/results/classifier/118/unknown/1151986 @@ -0,0 +1,331 @@ +risc-v: 0.927 +user-level: 0.880 +mistranslation: 0.835 +x86: 0.827 +hypervisor: 0.826 +device: 0.825 +permissions: 0.825 +TCG: 0.824 +vnc: 0.823 +graphic: 0.818 +peripherals: 0.814 +debug: 0.813 +KVM: 0.804 +architecture: 0.803 +VMM: 0.803 +semantic: 0.800 +ppc: 0.799 +assembly: 0.795 +PID: 0.790 +arm: 0.788 +network: 0.784 +virtual: 0.781 +performance: 0.781 +socket: 0.781 +register: 0.779 +boot: 0.767 +i386: 0.764 +kernel: 0.760 +files: 0.736 + +buffer overflow after block-stream via QMP + +When a block-stream is initiated via QMP and the QMP socket is closed on client side before the job is finished, QEMU crashes with a buffer overflow. + +Afterwards I cannot boot from the last active image anymore. + +I was able to reproduce this with qemu-kvm and qemu-system-x86_64 on two different machines. + +Version: +QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard + +I started QEMU with the following script: + +qemu-kvm \ + -monitor vc \ + -m 512 \ + -hda "$1" \ + -net nic,vlan=0 \ + -net user,vlan=0 \ + -localtime \ + -smp 2 \ + -qmp tcp:localhost:4444,server,nowait + + +Backtrace: + +Formatting '/home/helge/images/vm01.2013-03-07_11:30:13.qcow2', fmt=qcow2 size=10485760000 backing_file='/home/helge/images/vm01.qcow2' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off +*** buffer overflow detected ***: qemu-kvm terminated +======= Backtrace: ========= +/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f054e91a8c7] +/usr/lib/libc.so.6(+0xfc9a0)[0x7f054e9189a0] +/usr/lib/libc.so.6(+0xfe837)[0x7f054e91a837] +qemu-kvm(+0xdb0dc)[0x7f055220b0dc] +qemu-kvm(+0x15f581)[0x7f055228f581] +qemu-kvm(main+0xf93)[0x7f05521a3e93] +/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7f054e83da15] +qemu-kvm(+0x77e8d)[0x7f05521a7e8d] +======= Memory map: ======== +7f051bdff000-7f051be00000 rw-p 00000000 00:00 0 +7f051be00000-7f053be00000 rw-p 00000000 00:00 0 +7f053be00000-7f053c000000 rw-p 00000000 00:00 0 +7f053c000000-7f053c021000 rw-p 00000000 00:00 0 +7f053c021000-7f0540000000 ---p 00000000 00:00 0 +7f05421e2000-7f05421f7000 r-xp 00000000 08:12 1175478 /usr/lib/libgcc_s.so.1 +7f05421f7000-7f05423f6000 ---p 00015000 08:12 1175478 /usr/lib/libgcc_s.so.1 +7f05423f6000-7f05423f7000 rw-p 00014000 08:12 1175478 /usr/lib/libgcc_s.so.1 +7f05423f7000-7f05423f8000 ---p 00000000 00:00 0 +7f05423f8000-7f0542bf8000 rw-p 00000000 00:00 0 [stack:27848] +7f0542bf8000-7f0542bfd000 r-xp 00000000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542bfd000-7f0542dfd000 ---p 00005000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542dfd000-7f0542dfe000 r--p 00005000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542dfe000-7f0542dff000 rw-p 00006000 08:12 1198566 /usr/lib/libXfixes.so.3.1.0 +7f0542dff000-7f0542e00000 rw-p 00000000 00:00 0 +7f0542e00000-7f0543e00000 rw-p 00000000 00:00 0 +7f0543e00000-7f0544000000 rw-p 00000000 00:00 0 +7f0544000000-7f0544139000 rw-p 00000000 00:00 0 +7f0544139000-7f0548000000 ---p 00000000 00:00 0 +7f0548014000-7f054801e000 r-xp 00000000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054801e000-7f054821d000 ---p 0000a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054821d000-7f054821e000 r--p 00009000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054821e000-7f054821f000 rw-p 0000a000 08:12 1198746 /usr/lib/libXrender.so.1.3.0 +7f054821f000-7f0548228000 r-xp 00000000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548228000-7f0548427000 ---p 00009000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548427000-7f0548428000 r--p 00008000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548428000-7f0548429000 rw-p 00009000 08:12 1199189 /usr/lib/libXcursor.so.1.0.2 +7f0548429000-7f0548721000 r--p 00000000 08:12 1175421 /usr/lib/locale/locale-archive +7f0548721000-7f0548733000 r-xp 00000000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f0548733000-7f0548932000 ---p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f0548932000-7f0548933000 r--p 00011000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f0548933000-7f0548934000 rw-p 00012000 08:12 1198126 /usr/lib/libXext.so.6.4.0 +7f054895d000-7f05489c0000 rw-p 00000000 00:00 0 +7f054895d000-7f05489c0000 rw-p 00000000 00:00 0 [118/1982] +7f05489d3000-7f0548aed000 rw-s 00000000 00:04 69697543 /SYSV00000000 (deleted) +7f0548aed000-7f0548aee000 ---p 00000000 00:00 0 +7f0548aee000-7f05492ee000 rw-p 00000000 00:00 0 [stack:27612] +7f05492ee000-7f05492ef000 ---p 00000000 00:00 0 +7f05492ef000-7f0549aef000 rw-p 00000000 00:00 0 [stack:27611] +7f0549cef000-7f0549cf0000 rw-p 00000000 00:00 0 +7f0549cf0000-7f0549cf1000 ---p 00000000 00:00 0 +7f0549cf1000-7f054a4f1000 rw-p 00000000 00:00 0 [stack:27858] +7f054a4f1000-7f054a4fd000 r-xp 00000000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a4fd000-7f054a6fc000 ---p 0000c000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a6fc000-7f054a6fd000 r--p 0000b000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a6fd000-7f054a6fe000 rw-p 0000c000 08:12 1175139 /usr/lib/libnss_files-2.17.so +7f054a6fe000-7f054a704000 rw-p 00000000 00:00 0 +7f054a704000-7f054a719000 r-xp 00000000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a719000-7f054a918000 ---p 00015000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a918000-7f054a919000 r--p 00014000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a919000-7f054a91a000 rw-p 00015000 08:12 1175108 /usr/lib/libnsl-2.17.so +7f054a91a000-7f054a91d000 rw-p 00000000 00:00 0 +7f054a91d000-7f054a923000 r-xp 00000000 08:12 1203255 /usr/lib/libogg.so.0.8.0 +7f054a923000-7f054ab22000 ---p 00006000 08:12 1203255 /usr/lib/libogg.so.0.8.0 +7f054ab22000-7f054ab23000 rw-p 00005000 08:12 1203255 /usr/lib/libogg.so.0.8.0 +7f054ab23000-7f054ab4f000 r-xp 00000000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ab4f000-7f054ad4e000 ---p 0002c000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ad4e000-7f054ad4f000 r--p 0002b000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ad4f000-7f054ad50000 rw-p 0002c000 08:12 1203266 /usr/lib/libvorbis.so.0.4.6 +7f054ad50000-7f054b003000 r-xp 00000000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b003000-7f054b202000 ---p 002b3000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b202000-7f054b21e000 r--p 002b2000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b21e000-7f054b21f000 rw-p 002ce000 08:12 1203269 /usr/lib/libvorbisenc.so.2.0.9 +7f054b21f000-7f054b269000 r-xp 00000000 08:12 1203337 /usr/lib/libFLAC.so.8.2.0 +7f054b269000-7f054b468000 ---p 0004a000 08:12 1203337 /usr/lib/libFLAC.so.8.2.0 +7f054b468000-7f054b46a000 rw-p 00049000 08:12 1203337 /usr/lib/libFLAC.so.8.2.0 +7f054b46a000-7f054b46f000 r-xp 00000000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b46f000-7f054b66e000 ---p 00005000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b66e000-7f054b66f000 r--p 00004000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b66f000-7f054b670000 rw-p 00005000 08:12 1196541 /usr/lib/libXdmcp.so.6.0.0 +7f054b670000-7f054b672000 r-xp 00000000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b672000-7f054b872000 ---p 00002000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b872000-7f054b873000 r--p 00002000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b873000-7f054b874000 rw-p 00003000 08:12 1196554 /usr/lib/libXau.so.6.0.0 +7f054b874000-7f054b879000 r-xp 00000000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054b879000-7f054ba78000 ---p 00005000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054ba78000-7f054ba79000 r--p 00004000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054ba79000-7f054ba7a000 rw-p 00005000 08:12 1203313 /usr/lib/libasyncns.so.0.3.1 +7f054ba7a000-7f054bad9000 r-xp 00000000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bad9000-7f054bcd9000 ---p 0005f000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bcd9000-7f054bcdb000 r--p 0005f000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bcdb000-7f054bcdc000 rw-p 00061000 08:12 1203348 /usr/lib/libsndfile.so.1.0.25 +7f054bcdc000-7f054bce0000 rw-p 00000000 00:00 0 +7f054bce0000-7f054bcfe000 r-xp 00000000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054bcfe000-7f054befd000 ---p 0001e000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054befd000-7f054befe000 r--p 0001d000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054befe000-7f054beff000 rw-p 0001e000 08:12 1216246 /usr/lib/libxcb.so.1.1.0 +7f054beff000-7f054bf6c000 r-xp 00000000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054bf6c000-7f054c16b000 ---p 0006d000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054c16b000-7f054c16c000 r--p 0006c000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054c16c000-7f054c175000 rw-p 0006d000 08:12 1182009 /usr/lib/libgmp.so.10.1.1 +7f054c175000-7f054c187000 r-xp 00000000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c187000-7f054c386000 ---p 00012000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c386000-7f054c387000 r--p 00011000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c387000-7f054c388000 rw-p 00012000 08:12 1195339 /usr/lib/libhogweed.so.2.3 +7f054c388000-7f054c3b1000 r-xp 00000000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c3b1000-7f054c5b1000 ---p 00029000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c5b1000-7f054c5b2000 r--p 00029000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c5b2000-7f054c5b3000 rw-p 0002a000 08:12 1195342 /usr/lib/libnettle.so.4.5 +7f054c5b3000-7f054c5c5000 r-xp 00000000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c5c5000-7f054c7c4000 ---p 00012000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c7c4000-7f054c7c5000 r--p 00011000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c7c5000-7f054c7c6000 rw-p 00012000 08:12 1195333 /usr/lib/libtasn1.so.6.1.1 +7f054c7c6000-7f054c7d9000 r-xp 00000000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c7d9000-7f054c9d8000 ---p 00013000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c9d8000-7f054c9d9000 r--p 00012000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c9d9000-7f054c9da000 rw-p 00013000 08:12 1195353 /usr/lib/libp11-kit.so.0.0.0 +7f054c9da000-7f054c9ed000 r-xp 00000000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054c9ed000-7f054cbed000 ---p 00013000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054cbed000-7f054cbee000 r--p 00013000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054cbee000-7f054cbef000 rw-p 00014000 08:12 1175130 /usr/lib/libresolv-2.17.so +7f054cbef000-7f054cbf1000 rw-p 00000000 00:00 0 +7f054cbf1000-7f054cbf9000 r-xp 00000000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cbf9000-7f054cdf8000 ---p 00008000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cdf8000-7f054cdf9000 r--p 00007000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cdf9000-7f054cdfa000 rw-p 00008000 08:12 1175116 /usr/lib/libcrypt-2.17.so +7f054cdfa000-7f054ce28000 rw-p 00000000 00:00 0 +7f054ce28000-7f054ce6c000 r-xp 00000000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054ce6c000-7f054d06c000 ---p 00044000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054d06c000-7f054d06d000 r--p 00044000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054d06d000-7f054d06e000 rw-p 00045000 08:12 1193776 /usr/lib/libdbus-1.so.3.7.2 +7f054d06e000-7f054d0d4000 r-xp 00000000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d0d4000-7f054d2d3000 ---p 00066000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d3000-7f054d2d4000 r--p 00065000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d0d4000-7f054d2d3000 ---p 00066000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d3000-7f054d2d4000 r--p 00065000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d4000-7f054d2d6000 rw-p 00066000 08:12 792323 /usr/lib/pulseaudio/libpulsecommon-3.0.so +7f054d2d6000-7f054d2df000 r-xp 00000000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d2df000-7f054d4de000 ---p 00009000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d4de000-7f054d4df000 r--p 00008000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d4df000-7f054d4e0000 rw-p 00009000 08:12 1184982 /usr/lib/libjson.so.0.1.0 +7f054d4e0000-7f054d6c0000 r-xp 00000000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d6c0000-7f054d8c0000 ---p 001e0000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d8c0000-7f054d8db000 r--p 001e0000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d8db000-7f054d8e6000 rw-p 001fb000 08:12 1216755 /usr/lib/libcrypto.so.1.0.0 +7f054d8e6000-7f054d8ea000 rw-p 00000000 00:00 0 +7f054d8ea000-7f054d94c000 r-xp 00000000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054d94c000-7f054db4b000 ---p 00062000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054db4b000-7f054db4f000 r--p 00061000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054db4f000-7f054db56000 rw-p 00065000 08:12 1216754 /usr/lib/libssl.so.1.0.0 +7f054db56000-7f054db7d000 r-xp 00000000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054db7d000-7f054dd7d000 ---p 00027000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054dd7d000-7f054dd7e000 r--p 00027000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054dd7e000-7f054dd7f000 rw-p 00028000 08:12 1192299 /usr/lib/libssh2.so.1.0.1 +7f054dd7f000-7f054dd80000 rw-p 00000000 00:00 0 +7f054dd80000-7f054dd83000 r-xp 00000000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054dd83000-7f054df82000 ---p 00003000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054df82000-7f054df83000 r--p 00002000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054df83000-7f054df84000 rw-p 00003000 08:12 1175118 /usr/lib/libdl-2.17.so +7f054df84000-7f054df87000 r-xp 00000000 08:12 1195020 /usr/lib/libplds4.so +7f054df87000-7f054e186000 ---p 00003000 08:12 1195020 /usr/lib/libplds4.so +7f054e186000-7f054e187000 r--p 00002000 08:12 1195020 /usr/lib/libplds4.so +7f054e187000-7f054e188000 rw-p 00003000 08:12 1195020 /usr/lib/libplds4.so +7f054e188000-7f054e18c000 r-xp 00000000 08:12 1195021 /usr/lib/libplc4.so +7f054e18c000-7f054e38b000 ---p 00004000 08:12 1195021 /usr/lib/libplc4.so +7f054e38b000-7f054e38c000 r--p 00003000 08:12 1195021 /usr/lib/libplc4.so +7f054e38c000-7f054e38d000 rw-p 00004000 08:12 1195021 /usr/lib/libplc4.so +7f054e38d000-7f054e38e000 rw-p 00000000 00:00 0 +7f054e38e000-7f054e3b3000 r-xp 00000000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e3b3000-7f054e5b2000 ---p 00025000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e5b2000-7f054e5b8000 r--p 00024000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e5b8000-7f054e5b9000 rw-p 0002a000 08:12 1195095 /usr/lib/libnssutil3.so +7f054e5b9000-7f054e61a000 r-xp 00000000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e61a000-7f054e81a000 ---p 00061000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e81a000-7f054e81b000 r--p 00061000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e81b000-7f054e81c000 rw-p 00062000 08:12 1183254 /usr/lib/libpcre.so.1.2.0 +7f054e81c000-7f054e9c0000 r-xp 00000000 08:12 1175073 /usr/lib/libc-2.17.so +7f054e9c0000-7f054ebbf000 ---p 001a4000 08:12 1175073 /usr/lib/libc-2.17.so +7f054ebbf000-7f054ebc3000 r--p 001a3000 08:12 1175073 /usr/lib/libc-2.17.so +7f054ebc3000-7f054ebc5000 rw-p 001a7000 08:12 1175073 /usr/lib/libc-2.17.so +7f054ebc5000-7f054ebca000 rw-p 00000000 00:00 0 +7f054ebca000-7f054ebdf000 r-xp 00000000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054ebdf000-7f054edde000 ---p 00015000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054edde000-7f054eddf000 r--p 00014000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054eddf000-7f054ede0000 rw-p 00015000 08:12 1181365 /usr/lib/libz.so.1.2.7 +7f054ede0000-7f054eedd000 r-xp 00000000 08:12 1175074 /usr/lib/libm-2.17.so +7f054eedd000-7f054f0dc000 ---p 000fd000 08:12 1175074 /usr/lib/libm-2.17.so +7f054f0dc000-7f054f0dd000 r--p 000fc000 08:12 1175074 /usr/lib/libm-2.17.so +7f054f0dd000-7f054f0de000 rw-p 000fd000 08:12 1175074 /usr/lib/libm-2.17.so +7f054f0de000-7f054f211000 r-xp 00000000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f211000-7f054f411000 ---p 00133000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f411000-7f054f412000 r--p 00133000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f412000-7f054f417000 rw-p 00134000 08:12 1197495 /usr/lib/libX11.so.6.3.0 +7f054f417000-7f054f47f000 r-xp 00000000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f47f000-7f054f67f000 ---p 00068000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f67f000-7f054f680000 r--p 00068000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f680000-7f054f681000 rw-p 00069000 08:12 1207484 /usr/lib/libSDL-1.2.so.0.11.4 +7f054f681000-7f054f6af000 rw-p 00000000 00:00 0 +7f054f6af000-7f054f7b1000 r-xp 00000000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 +7f054f7b1000-7f054f9b1000 ---p 00102000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 +7f054f9b1000-7f054f9b9000 r--p 00102000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 +7f054f9b9000-7f054f9bb000 rw-p 0010a000 08:12 1200422 /usr/lib/libgnutls.so.28.16.1 + +On Thu, Mar 07, 2013 at 11:02:07AM -0000, Helge Rausch wrote: +> When a block-stream is initiated via QMP and the QMP socket is closed on +> client side before the job is finished, QEMU crashes with a buffer +> overflow, somewhere at the end of the streaming process. +> +> Without QMP I can stream via the HMP without problems. After crashing, I +> cannot boot from the active image anymore. +> +> I was able to reproduce this with qemu-kvm and qemu-system-x86_64 on two +> different machines. +> +> Version: +> QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard + +I cannot reproduce this with qemu-system-x86-1.2.2-6.fc18.x86_64. + +> I started QEMU with the following script: +> +> qemu-kvm \ +> -monitor vc \ +> -m 512 \ +> -hda "$1" \ +> -net nic,vlan=0 \ +> -net user,vlan=0 \ +> -localtime \ +> -smp 2 \ +> -qmp tcp:localhost:4444,server,nowait + +I used your command-line and the following QMP commands: + +$ QMP/qmp-shell localhost:4444 +(QEMU) blockdev-snapshot-sync device=ide0-hd0 snapshot-file=test2.qcow2 +(QEMU) block-stream ide0-hd0 +(QEMU) query-block-jobs +...output shows the job running... +(QEMU) Ctrl+D + +The block job completes successfully and I get no crash. + +Please try qemu.git/master to see if the bug is still there for you: + +$ git clone git://git.qemu-project.org/qemu.git +$ cd qemu +$ ./configure --target-list=x86_64-softmmu +$ make +$ x86_64-softmmu/qemu-system-x86_64-softmmu -enable-kvm ... + +Stefan + + +I cannot reproduce it anymore on master. One option we now have without building it ourselves is using 1.4.0 from Ubuntu's raring derivate. Would you consider that stable enough for production use (the qemu package, not raring)? + +On Thu, Mar 07, 2013 at 06:14:27PM -0000, Helge Rausch wrote: +> I cannot reproduce it anymore on master. One option we now have without +> building it ourselves is using 1.4.0 from Ubuntu's raring derivate. +> Would you consider that stable enough for production use (the qemu +> package, not raring)? + +QEMU 1.4.0 is a stable release, it is intended for production use. + +I can't speak for Ubuntu packaging of QEMU 1.4.0, perhaps check the bug +tracker to see if there are known issues with the package. + +Stefan + + +Alright. Thank you! + +1.4.0 is the intended stable release for Ubuntu raring. + diff --git a/results/classifier/118/unknown/1170 b/results/classifier/118/unknown/1170 new file mode 100644 index 00000000..0527a2e9 --- /dev/null +++ b/results/classifier/118/unknown/1170 @@ -0,0 +1,86 @@ +TCG: 0.845 +register: 0.815 +debug: 0.798 +hypervisor: 0.784 +permissions: 0.784 +user-level: 0.783 +peripherals: 0.776 +KVM: 0.773 +ppc: 0.764 +graphic: 0.754 +device: 0.752 +semantic: 0.746 +virtual: 0.746 +risc-v: 0.744 +i386: 0.740 +VMM: 0.735 +vnc: 0.733 +network: 0.730 +x86: 0.725 +PID: 0.716 +architecture: 0.715 +arm: 0.711 +assembly: 0.708 +performance: 0.707 +boot: 0.706 +socket: 0.702 +files: 0.691 +mistranslation: 0.688 +kernel: 0.675 + +Unable to compile in Ubuntu 22.04, at compiling linux-user_arm_nwfpe_double_cpdo.c.o +Description of problem: +Compiling of QEMU 7.1.0-rc3 stops here for me: +``` +[7172/9855] Compiling C object libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o +FAILED: libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o +cc -m64 -mcx16 -Ilibqemu-armeb-linux-user.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -Ilinux-user -I../linux-user -Ilinux-user/arm -I../linux-user/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/capstone -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/andrea/Downloads/qemu-7.1.0-rc3/linux-headers -isystem linux-headers -iquote . -iquote /home/andrea/Downloads/qemu-7.1.0-rc3 -iquote /home/andrea/Downloads/qemu-7.1.0-rc3/include -iquote /home/andrea/Downloads/qemu-7.1.0-rc3/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="armeb-linux-user-config-target.h"' '-DCONFIG_DEVICES="armeb-linux-user-config-devices.h"' -MD -MQ libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o -MF libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o.d -o libqemu-armeb-linux-user.fa.p/linux-user_arm_nwfpe_double_cpdo.c.o -c ../linux-user/arm/nwfpe/double_cpdo.c +during RTL pass: expand +../linux-user/arm/nwfpe/double_cpdo.c: In function ‘DoubleCPDO’: +../linux-user/arm/nwfpe/double_cpdo.c:232:1: internal compiler error: Segmentation fault + 232 | } + | ^ +0x7fe5b824251f ??? + ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 +0x7fe5b8229d8f __libc_start_call_main + ../sysdeps/nptl/libc_start_call_main.h:58 +0x7fe5b8229e3f __libc_start_main_impl + ../csu/libc-start.c:392 +Please submit a full bug report, +with preprocessed source if appropriate. +Please include the complete backtrace with any bug report. +See <file:///usr/share/doc/gcc-11/README.Bugs> for instructions. +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:162: run-ninja] Error 1 +make[1]: Leaving directory '/home/andrea/Downloads/qemu-7.1.0-rc3/build' +make: *** [GNUmakefile:11: all] Error 2 +``` + +Configure Output: +[Configure_Output.txt](/uploads/40055846573b79cc2817d5cb338e18c1/Configure_Output.txt) + +Compiles on 7.0.0. +Steps to reproduce: +1. Run 'sudo apt purge qemu-kvm qemu-utils libvirt-daemon-system libvirt-clients bridge-utils virt-manager ovmf' +2. Run 'sudo apt-get install git libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev ninja-build' ([Wiki](https://wiki.qemu.org/Hosts/Linux)) +3. Additional Packages: +``` +sudo apt-get install git-email +sudo apt-get install libaio-dev libbluetooth-dev libcapstone-dev libbrlapi-dev libbz2-dev +sudo apt-get install libcap-ng-dev libcurl4-gnutls-dev libgtk-3-dev +sudo apt-get install libibverbs-dev libjpeg8-dev libncurses5-dev libnuma-dev +sudo apt-get install librbd-dev librdmacm-dev +sudo apt-get install libsasl2-dev libsdl2-dev libseccomp-dev libsnappy-dev libssh-dev +sudo apt-get install libvde-dev libvdeplug-dev libvte-2.91-dev libxen-dev liblzo2-dev +sudo apt-get install valgrind xfslibs-dev + +sudo apt-get install libnfs-dev libiscsi-dev +``` +4. Build instructions for QEMU: +``` +wget https://download.qemu.org/qemu-7.1.0-rc3.tar.xz +tar xvJf qemu-7.1.0-rc3.tar.xz +cd qemu-7.1.0-rc3 +./configure +make +``` diff --git a/results/classifier/118/unknown/1175089 b/results/classifier/118/unknown/1175089 new file mode 100644 index 00000000..c091e56b --- /dev/null +++ b/results/classifier/118/unknown/1175089 @@ -0,0 +1,95 @@ +user-level: 0.868 +risc-v: 0.812 +permissions: 0.797 +architecture: 0.791 +KVM: 0.777 +vnc: 0.775 +virtual: 0.774 +mistranslation: 0.770 +VMM: 0.769 +device: 0.765 +performance: 0.763 +i386: 0.757 +files: 0.757 +graphic: 0.753 +register: 0.748 +network: 0.745 +ppc: 0.744 +x86: 0.744 +boot: 0.741 +socket: 0.739 +debug: 0.739 +TCG: 0.737 +assembly: 0.737 +PID: 0.737 +peripherals: 0.730 +hypervisor: 0.716 +arm: 0.710 +kernel: 0.710 +semantic: 0.709 + +Crash why dragon fly 3.4.1 + +Hello, all is here (kernel 3.8, qemu 1.2.2-r3): +/usr/bin/qemu-system-x86_64 -k fr -alt-grab -m 2048 -vga vmware -net nic,vlan=0,model=virtio -net user -rtc base=localtime -smp 4,cores=4,sockets=1 -boot once=d -cdrom dfly-x86_64-gui-3.4.1_REL.iso +KVM internal error. Suberror: 1 +emulation failure +EAX=00000010 EBX=00009338 ECX=00000000 EDX=00000000 +ESI=000017fc EDI=000017c8 EBP=000364a0 ESP=000017b8 +EIP=00009318 EFL=00003002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00c09300 +CS =0018 00000000 0000ffff 00009b00 +SS =0010 00000000 ffffffff 00c09300 +DS =0010 00000000 ffffffff 00c09300 +FS =0033 0000a000 ffffffff 00c0f300 +GS =0033 0000a000 ffffffff 00c0f300 +LDT=0000 00000000 0000ffff 00008200 +TR =0038 00005f98 00002067 00008b00 +GDT= 00009590 0000003f +IDT= 00005e00 00000197 +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 a3 ea 5d 00 00 66 ea 10 93 18 00 0f 20 c0 fe c8 0f 22 c0 <ea> 1d 93 00 00 31 c0 8e d8 8e d0 0f 01 1e dc 95 66 07 66 1f 66 0f a1 66 0f a9 66 61 bc ea + +Same code for FreeBSD on older devices under openstack/qemu: +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name instance-00000968 -S -machine pc-i440fx-1.5,accel=kvm,usb=off -cpu host -m 2096 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 387ce256-de98-4ae9-89f4-a4c26e970bf1 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2013.2.4,serial=4c4c4544-0034-5210-8058-b4c04f5a344a,uuid=387ce256-de98-4ae9-89f4-a4c26e970bf1 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000968.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/387ce256-de98-4ae9-89f4-a4c26e970bf1/disk,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:0e:59:74,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/387ce256-de98-4ae9-89f4-a4c26e970bf1/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 0.0.0.0:4 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 + +Domain id=41 is tainted: host-cpu +W: kvm binary is deprecated, please use qemu-system-x86_64 instead +Warning: option deprecated, use lost_tick_policy property of kvm-pit instead. +char device redirected to /dev/pts/5 (label charserial1) +KVM internal error. Suberror: 1 +emulation failure +EAX=00000010 EBX=00009336 ECX=00000000 EDX=00000000 +ESI=000017fc EDI=000017c8 EBP=0003b500 ESP=000017b8 +EIP=00009316 EFL=00003002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00c09300 +CS =0018 00000000 0000ffff 00009b00 +SS =0010 00000000 ffffffff 00c09300 +DS =0010 00000000 ffffffff 00c09300 +FS =0033 0000a000 ffffffff 00c0f300 +GS =0033 0000a000 ffffffff 00c0f300 +LDT=0000 00000000 0000ffff 00008200 +TR =0038 00005f98 00002067 00008b00 +GDT= 00009590 0000003f +IDT= 00005e00 00000197 +CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +Code=00 a3 ea 5d 00 00 66 ea 0e 93 18 00 0f 20 c0 fe c8 0f 22 c0 <ea> 1b 93 00 00 31 c0 8e d8 8e d0 0f 01 1e dc 95 66 07 66 1f 66 0f a1 66 0f a9 66 61 bc ea +qemu: terminating on signal 15 from pid 12541 +2015-01-29 14:11:08.678+0000: shutting down + +PowerEdge R210 +qemu: 1.5.0+dfsg-3ubuntu5.4~cloud0 +cpu flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid + +3.8.0-44-generic x86_64 + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1180923 b/results/classifier/118/unknown/1180923 new file mode 100644 index 00000000..1caa4a34 --- /dev/null +++ b/results/classifier/118/unknown/1180923 @@ -0,0 +1,239 @@ +permissions: 0.900 +peripherals: 0.894 +register: 0.873 +hypervisor: 0.863 +i386: 0.857 +device: 0.854 +TCG: 0.849 +debug: 0.842 +semantic: 0.840 +risc-v: 0.838 +performance: 0.835 +mistranslation: 0.833 +files: 0.829 +user-level: 0.829 +vnc: 0.828 +network: 0.828 +graphic: 0.823 +architecture: 0.822 +virtual: 0.822 +assembly: 0.818 +ppc: 0.802 +VMM: 0.800 +socket: 0.787 +arm: 0.777 +KVM: 0.776 +PID: 0.743 +boot: 0.719 +x86: 0.718 +kernel: 0.704 + +unused memory filled with 0x00 instead of 0xFF + +Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem? + +well, actually, memory gets filled with the wrong byte, pardon my original post. + +Yeah, Qemu fills all bytes of the unused memory with 0x00 whereas it should fill them with 0xFF. This causes DOS to incorrectly interpret available memory as used by Option RAM, breaking the operation of EMM386.EXE which then fails to find available upper memory. This also causes problems with running Windows 3.x. + +The problem is specifically about the first 1 MB of RAM. Also, another related problem is that in all Qemu 1.x versions, segments E000-EFFF, possibly even D000-DFFF, get used by an Option RAM that can't be removed. This drastically reduces the amount of available upper memory. + +On Thu, May 16, 2013 at 9:20 PM, Paolo Bonzini <email address hidden> wrote: +> Il 16/05/2013 19:34, TC1988 ha scritto: +>> Public bug reported: +>> +>> Qemu, ever since it was made (so, since 2003), has this problem in DOS +>> (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the +>> memory available when the memory is filled with 0x00 but when it is +>> filled with 0xFF it gets recognized properly, where should I patch qemu +>> to solve this memory problem? +> +> Can you provide reproduction instructions for this bug? + +Sounds like (risky) memory probing. On a PC the memory regions that +are unpopulated produce 0xff. + +But you're supposed to use e820 or other mechanisms to retrieve the +proper memory layout from the firmware. + +Stefan + + +On 16 May 2013 20:52, Stefan Hajnoczi <email address hidden> wrote: +> Sounds like (risky) memory probing. On a PC the memory regions that +> are unpopulated produce 0xff. + +Presumably you could fix the PC model to do that by putting a big +background (overlappable) MemoryRegion across the whole of the +system address space which returned -1 for every access? + +-- PMM + + +>>But you're supposed to use e820 or other mechanisms to retrieve the proper memory layout from the firmware. +Well go back to the early 1990's and tell Microsoft and IBM that. :p +DOS as it is, refuses to recognize memory not filled with 0xFF's as free. It instead thinks such memory is used by Option RAM. +On Qemu 0.9.1, I got around the issues by padding the video BIOS with 0xFF's to the 64 kB boundary, and using the relevant option to load a a 64 kB .BIN file full of 0xFF's as an option ROM, as well as using the BOCHS legacy BIOS which has the first 64 kB filled with 0xFF's, thus getting D000-EFFF + from about CA00 or so to CFFF filled with 0xFF's, making DOS work correctly. +But on Qemu 1.x and later, this no longer works. Well, the video BIOS padding does work, but I am unable to load an option ROM like in 0.9.1. +Also, for some reason, all Qemu VGA BIOS'es are bigger than 32 kB, even the ones for CL-GD 5446 and VMWare SVGA II., even though the real CL-GD 5446 and VMWare SVGA II. BIOS'es are both 32 kB. This messes with the working of Windows 3.0 which expects segments C800-CFFF to be free. + +Also, as for reproduction instruction: +Start MS-DOS and make sure to bypass CONFIG.SYS and AUTOEXEC.BAT. +Then run Microsoft Diagnostics (MSD) and press M for Memory. Look at the Memory Map: areas that are available, get marked as either "potentially available" (which means EMM386 will treat them with caution and not address them unless told to) or "Option RAM", well as anything but "available". +Or just load EMM386.EXE from CONFIG.SYS with a simple DEVICE=EMM386.EXE (preceded by DEVICE=HIMEM.SYS obviously) and reboot. You'll get an error message telling you that EMM386 was unable to find a page frame for EMS, and MEM will report 0 upper memory. + +Paolo Bonzini <email address hidden> writes: + +> Il 16/05/2013 22:00, Peter Maydell ha scritto: +>>> > Sounds like (risky) memory probing. On a PC the memory regions that +>>> > are unpopulated produce 0xff. +>> Presumably you could fix the PC model to do that by putting a big +>> background (overlappable) MemoryRegion across the whole of the +>> system address space which returned -1 for every access? +> +> On a modern PC, there is really no non-present memory region where UMBs +> used to be. Memory between 0xc0000 and 0x100000 will be mostly unused, +> but it is not mentioned in the firmware ("e820") memory map. + +It's not memory (at least not by default). + +> For example on KVM the memory map is: +> +> [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +> [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +> [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +> [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000007ffdfff] usable +> [ 0.000000] BIOS-e820: [mem 0x0000000007ffe000-0x0000000007ffffff] reserved +> [ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved +> [ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +> +> but SeaBIOS says: +> +> Copying option rom (size 36352) from 0xfebc0000 to 0x000c0000 +> Copying option rom (size 65536) from 0xfebd0000 to 0x000c9000 +> Copying option rom (size 1024) from genroms/linuxboot.bin to 0x000ca000 +> Copying option rom (size 9216) from genroms/kvmvapic.bin to 0x000ca800 +> Space available for UMB: cd000-ee800, f0000-f1c20 + +There are a couple things happening here. + +Long before the PCI roms are moved to the option rom space, that space +is made writable via PAM. PAM is a more modern feature that was +introduced to make firmware execution much faster. + +Without PAM, this whole range is mapped to ROM memory which means it's +going to get put out on a bus. If there isn't a ROM mapped, the result +is going to be 0xFF. + +We don't emulate this correctly because we don't emulate execute from +ROM which means that we always treat the option rom space as RAM even +though is it not at start of day. + +> So you can see it in three ways: +> +> 1) It's not a QEMU problem, but a firmware problem. You could initialize +> the UMBs with 0xFF in SeaBIOS for example. + +SeaBIOS is not supposed to do any initialization. Once it's RAM, +there's no guarantee of what the contents will be. The problem is that +it's supposed to be ROM. + +I doubt it's still there, but BIOSes often had an option to disable +ROM shadowing expressly because it breaks applications that assume that +this space is ROM after BIOS loads. + +Perhaps SeaBIOS could support such an option but we can't support it in +KVM at the moment. + +> However, it is probably +> necessary to round the UMBs somehow, because emm386 probably probes +> memory with a larger granularity than 32 bytes. For example, in the case +> above you may want to leave 0x00 outside 0xD0000-0xEC000 (16kb granularity). +> You also need to ensure the UMBs are write-protected (I do not remember if +> that's already the case). +> +> 2) It's not a QEMU prablem, but an EMM386 problem. Simply, EMM386 +> does not support chipsets that have RAM at 0xc0000-0x100000. I found +> some information about a program called UMBPCI that you can use instead +> of EMM386. + +Ack, but this is why it was possible to disable ROM shadowing.... + +> 3) It's a QEMU problem, but it should only work with "-M isapc". This +> would be similar to what Peter suggested, but it would give you very +> small UMBs (something like 0xD0000-0xE0000). To go beyond that you +> need to recompile SeaBIOS so that it fits in a 64kb ROM. It's probably +> possible to make it fit, but you may encounter SeaBIOS bugs because no +> one uses it with such a small ROM. Having a more useful ISA PC emulation +> in QEMU would be a nice project, but no one really has time for that +> among the most active developers. + +I think the first step is to get execute from ROM working and then +implement PAM correctly. Then it wouldn't be that hard to implement +SeaBIOS changes to only conditionally shadow ROMs. + +Regards, + +Anthony Liguori + +> +> Paolo + + +Well about it being an EMM386 problem - no, it's DOS itself that maps the memory incorrectly if it's not filled the way it expects it. EMM386 just asks DOS for a memory map and tries to find the first free segment. But in this case, DOS hasn't mapped any segment as free, so EMM386 is unable to do anything and errors out. +Also, I've used a real PCI machine from the late 1990's - a Celeron 333 MHz, and EMM386 worked fine on it. At least segments D000-DFFF were free. That's not the case on Qemu for some reason - I guess Qemu emulates a 21st century PCI machine instead, with no option to make it emulate one from the late 1990's. +As for using UMBPCI - I already tried it and it's not compatible with Windows 3.x and earlier. And it wouldn't change much anyway since it's not the EMM manager that probes the memory but DOS itself. This is why MSD is able to show a memory map of the upper memory even when neither HIMEM nor EMM386 are loaded. + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + +I know this is expired but it's still a problem in qemu 7.0.0. For example, when running MS-DOS 6.22, "mem" reports 0K of upper memory, and memmaker fails to run, complaining that it could not allocate any. I'd love to know if there's a workaround. + +I create a issue at https://gitlab.com/qemu-project/qemu/-/issues/1133 to +tracking this + +On Mon, Aug 1, 2022 at 5:06 AM David Glover <email address hidden> +wrote: + +> I know this is expired but it's still a problem in qemu 7.0.0. For +> example, when running MS-DOS 6.22, "mem" reports 0K of upper memory, and +> memmaker fails to run, complaining that it could not allocate any. I'd +> love to know if there's a workaround. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1180923 +> +> Title: +> unused memory filled with 0x00 instead of 0xFF +> +> Status in QEMU: +> Expired +> +> Bug description: +> Qemu, ever since it was made (so, since 2003), has this problem in DOS +> (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the +> memory available when the memory is filled with 0x00 but when it is +> filled with 0xFF it gets recognized properly, where should I patch +> qemu to solve this memory problem? +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1180923/+subscriptions +> +> +> + +-- + 此致 +礼 +罗勇刚 +Yours + sincerely, +Yonggang Luo + + +I am using Qemu 8.0.0 and this issue happens only when kvm is enabled, tcg initialized the unused bytes to 0xFF as a real machine and works normally, so a question in my mind, does kvm use those umb area for increased performance? +If emm386 M5 is used for using area D000-D7FF as frame page, emm386 gives a warning that there is an option rom in this location but it still uses this area, seems like a workaround, i do not know if it will have any side effect + diff --git a/results/classifier/118/unknown/1185311 b/results/classifier/118/unknown/1185311 new file mode 100644 index 00000000..1796e193 --- /dev/null +++ b/results/classifier/118/unknown/1185311 @@ -0,0 +1,160 @@ +register: 0.870 +device: 0.869 +semantic: 0.854 +peripherals: 0.854 +permissions: 0.849 +hypervisor: 0.849 +virtual: 0.846 +assembly: 0.845 +PID: 0.844 +socket: 0.842 +debug: 0.841 +graphic: 0.838 +ppc: 0.837 +kernel: 0.837 +architecture: 0.836 +arm: 0.835 +performance: 0.834 +vnc: 0.830 +risc-v: 0.824 +user-level: 0.822 +KVM: 0.821 +network: 0.818 +files: 0.817 +mistranslation: 0.815 +VMM: 0.810 +boot: 0.805 +TCG: 0.805 +x86: 0.797 +i386: 0.786 + +could not hot-remove disabled NIC from Win2012 guest by 'devel_del id1' + +# qemu-latest-upstream -mon chardev=qmp,mode=control,pretty=on \ + -chardev socket,id=qmp,host=localhost,port=1234,server,nowait -vnc :0 \ + -monitor stdio /images/win2012-64-virtio.qcow2 \ + -device virtio-net-pci,netdev=ndev1,id=id1 -netdev tap,id=ndev1 \ + -device e1000,netdev=ndev2,id=id2 -netdev tap,id=ndev2 \ + -device rtl8139,netdev=ndev3,id=id3 -netdev tap,id=ndev3 \ + -smp 4 -m 3000 -usbdevice tablet + +If disable nic in guest's "Network Connections" panel, nic could not be hot-removed through qemu monitor. + +1) if disable nic in guest +(qemu) devel_del id1 (nic still in "Network Connections". if enable nic, nic can work) +(qemu) devel_del id1 +(qemu) devel_del id1 + +2) if enable nic in guest +(qemu) devel_del id1 (nic will be removed, disappear from "Network Connections") +(qemu) devel_del id1 +Device 'id1' not found + +Could not reproduced this problem with all linux guests & other Windows guests +Problem exists with virtio-nic/e1000/rtl8139, it seems the problem of pci-hotplug in piix4. + +Could not reproduce this problem with Vmware + win2012 guest. + +hot-remove a disabled nic: + +(qemu) device_del id1 + irq: -120008472, level :1, pmsts: 1 +acpi_pm_tmr_update: bool :0 +(qemu) gpe read 0 == 2 + irq: -120008472, level :1, pmsts: 0 +acpi_pm_tmr_update: bool :0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 2 <== 0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 3 <== 0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe read 0 == 2 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 0 <== 2 +gpe read 1 == 0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 2 <== 253 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 3 <== 255 +pci_up_read 38 +pci_down_read 8 +... +... +pci_up_read 38 +pci_down_read 8 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 2 <== 255 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 3 <== 255 + + +hot-remove an enabled nic: + +(qemu) device_del id1 + irq: -120008472, level :1, pmsts: 1 +acpi_pm_tmr_update: bool :0 +(qemu) gpe read 0 == 2 + irq: -120008472, level :1, pmsts: 0 +acpi_pm_tmr_update: bool :0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 2 <== 0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 3 <== 0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe read 0 == 2 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 0 <== 2 +gpe read 1 == 0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 2 <== 253 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 3 <== 255 +pci_up_read 38 +pci_down_read 8 +.... +.... +pci_up_read 38 +pci_down_read 8 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 2 <== 255 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 3 <== 255 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 2 <== 255 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 3 <== 255 +pciej write 8 <== 8 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 2 <== 255 + irq: -120008472, level :0, pmsts: 0 +acpi_pm_tmr_update: bool :0 +gpe write 3 <== 255 + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1195882 b/results/classifier/118/unknown/1195882 new file mode 100644 index 00000000..2230a8f7 --- /dev/null +++ b/results/classifier/118/unknown/1195882 @@ -0,0 +1,171 @@ +hypervisor: 0.898 +mistranslation: 0.880 +peripherals: 0.864 +user-level: 0.861 +virtual: 0.859 +i386: 0.853 +risc-v: 0.848 +TCG: 0.840 +vnc: 0.833 +permissions: 0.831 +semantic: 0.830 +register: 0.830 +PID: 0.829 +device: 0.826 +graphic: 0.824 +architecture: 0.822 +VMM: 0.820 +assembly: 0.817 +network: 0.811 +x86: 0.809 +debug: 0.809 +boot: 0.804 +ppc: 0.803 +files: 0.800 +KVM: 0.795 +performance: 0.792 +socket: 0.788 +arm: 0.783 +kernel: 0.783 + +Make fails on Centos - can't find autoreconf + + [root@H002 qemu-1.4.2]# make +\ GEN i386-softmmu/config-devices.mak + GEN x86_64-softmmu/config-devices.mak + GEN alpha-softmmu/config-devices.mak + GEN arm-softmmu/config-devices.mak + GEN cris-softmmu/config-devices.mak + GEN lm32-softmmu/config-devices.mak + +( .... ) + +GEN unicore32-linux-user/config-devices.mak + GEN s390x-linux-user/config-devices.mak + GEN config-all-devices.mak + GEN config-host.h +(cd /opt/qemu/qemu-1.4.2/pixman; autoreconf -v --install) +/bin/sh: autoreconf: command not found +make: *** [/opt/qemu/qemu-1.4.2/pixman/configure] Error 127 + +***************** + +Exact same error for 1.5.1 build +So, qemu not supported on anything but Ubuntu? + +autoreconf is part of the autoconf package. Do you have that installed? + +As far as I know, autoreconf does not exist in the red hat/fedora/centos world. + +Can't find a yum, rpm. or other distro for it on the above os. + +Am I missing something obvious hrte? + +Thanks.... + + +Sent from a mobile device. + +-------- Original message -------- +From: Iggy <email address hidden> +Date: +To: <email address hidden> +Subject: [Bug 1195882] Re: Make fails on Centos - can't find autoreconf + +autoreconf is part of the autoconf package. Do you have that installed? + +-- +You received this bug notification because you are subscribed to the bug +report. +https://bugs.launchpad.net/bugs/1195882 + +Title: + Make fails on Centos - can't find autoreconf + +Status in QEMU: + New + +Bug description: + [root@H002 qemu-1.4.2]# make + \ GEN i386-softmmu/config-devices.mak + GEN x86_64-softmmu/config-devices.mak + GEN alpha-softmmu/config-devices.mak + GEN arm-softmmu/config-devices.mak + GEN cris-softmmu/config-devices.mak + GEN lm32-softmmu/config-devices.mak + + ( .... ) + + GEN unicore32-linux-user/config-devices.mak + GEN s390x-linux-user/config-devices.mak + GEN config-all-devices.mak + GEN config-host.h + (cd /opt/qemu/qemu-1.4.2/pixman; autoreconf -v --install) + /bin/sh: autoreconf: command not found + make: *** [/opt/qemu/qemu-1.4.2/pixman/configure] Error 127 + + ***************** + + Exact same error for 1.5.1 build + So, qemu not supported on anything but Ubuntu? + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1195882/+subscriptions + + +> As far as I know, autoreconf does not exist in the red hat/fedora/centos world. +> +> Can't find a yum, rpm. or other distro for it on the above os. + +You aren't looking very hard; on my RHEL 6.4 box (which has the same +packages as what you can install in CentOS), I see: + +$ rpm -qf `which autoreconf` +autoconf-2.63-5.1.el6.noarch + + +On Friday 28 June 2013 18:20:29 you wrote: +> autoreconf is part of the autoconf package. Do you have that installed? +> +Hi, + +Thanks for the response. + +You're right, it was the lack of autoconf. Actually, on CentOS/RH, you need +to check for + +autoconf +automake (includes autoconf?) +libtools + +Seems to be building happily now. Sorry for the newbie question. + +/T. + + +On Saturday 29 June 2013 00:12:17 you wrote: +> > As far as I know, autoreconf does not exist in the red +> > hat/fedora/centos world. +> > +> > Can't find a yum, rpm. or other distro for it on the above os. +> +> You aren't looking very hard; on my RHEL 6.4 box (which has the same +> packages as what you can install in CentOS), I see: +> +> $ rpm -qf `which autoreconf` +> autoconf-2.63-5.1.el6.noarch +> +You're right. Also installed automake which supplies an 'aclocal' +executable that's not in the autoconf distro, and libtool to fix a 'possibly +undefined macro AC_LIBTOOL' issue. + +Seems to be happily compiling/linking now. + +My apologies for the pseudo-bug report. + +BTW, thank you for your assistance. + +/Todd + + + diff --git a/results/classifier/118/unknown/1218 b/results/classifier/118/unknown/1218 new file mode 100644 index 00000000..55f72fdf --- /dev/null +++ b/results/classifier/118/unknown/1218 @@ -0,0 +1,50 @@ +user-level: 0.902 +permissions: 0.847 +files: 0.840 +virtual: 0.833 +architecture: 0.832 +device: 0.831 +boot: 0.831 +register: 0.824 +mistranslation: 0.824 +hypervisor: 0.823 +network: 0.823 +debug: 0.818 +socket: 0.814 +performance: 0.814 +graphic: 0.812 +kernel: 0.811 +assembly: 0.811 +peripherals: 0.805 +arm: 0.803 +risc-v: 0.800 +PID: 0.800 +KVM: 0.792 +x86: 0.785 +semantic: 0.767 +ppc: 0.754 +TCG: 0.753 +vnc: 0.746 +VMM: 0.729 +i386: 0.723 + +bitmap lost when create snapshot using blockdev-snapshot-sync function +Description of problem: +bitmap will be lost when using the blockdev-snapshot-sync qmp command to create external snapshot. +if we create snapshot with the bitmap ,we have to start our incremental backup chain from a new full-backup. +Steps to reproduce: +1. start the qemu : +qemu-system-x86_64 -name guest=i-00001C,debug-threads=on -machine pc,dump-guest-core=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -smp 4,sockets=1,cores=4,threads=1 -uuid 991c2994-e1c9-48c0-9554-6b23e43900eb -smbios type=1,manufacturer=data,serial=7C1A9ABA-02DD-4E7D-993C-E1CDAB47A19B,family="Virtual Machine" -no-user-config -nodefaults -device sga -rtc base=2022-09-09T02:54:38,clock=host,driftfix=slew -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,splash-time=0,strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x6 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.0,addr=0xa -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x8 -device ich9-usb-ehci1,id=usb1,bus=pci.0,addr=0x9 -device piix4-usb-uhci,id=usb2,bus=pci.0,addr=0xb -device qemu-xhci,id=usb3,bus=pci.0,addr=0xc -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-1,readonly=on -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1,bootindex=2 -drive if=none,id=drive-fdc0-0-0,readonly=on -drive file=/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,num-queues=1,bus=pci.1,addr=0x1,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -device usb-tablet,id=input0,bus=usb.0,port=1 -device intel-hda,id=sound0,bus=pci.0,addr=0x3 -device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -sandbox off -device pvpanic,ioport=1285 -msg timestamp=on -qmp tcp:127.0.0.1:4444,server,nowait + +2. {"execute":"block-dirty-bitmap-add","arguments":{"node":"drive-virtio-disk0", "name":"bitmap-2022-09-19-16-10-23"}} + +3. {"execute":"query-block"} and the result: + {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block173", "backing_file_depth": 0, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "**dirty-bitmaps**": [{"name": "bitmap-2022-09-19-16-10-23", "recording": true, "persistent": false, "busy": false, "granularity": 65536, "count": 0}], "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]} + +4. {"execute":"blockdev-snapshot-sync","arguments":{"device": "drive-virtio-disk0", "snapshot-file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "format": "qcow2"}} +5. {"execute":"query-block"} and the result: + {"return": [{"io-status": "ok", "device": "drive-ide0-1-1", "locked": false, "removable": true, "qdev": "ide0-1-1", "tray_open": false, "type": "unknown"}, {"device": "drive-fdc0-0-0", "locked": false, "removable": true, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 21474836480, "filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "dirty-flag": false}, "backing-filename-format": "qcow2", "virtual-size": 21474836480, "filename": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice", "cluster-size": 65536, "format": "qcow2", "actual-size": 200704, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "compression-type": "zlib", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false, "extended-l2": false}}, "full-backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "backing-filename": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name": "#block618", "backing_file_depth": 1, "drv": "qcow2", "iops": 0, "bps_wr": 0, "write_threshold": 0, "backing_file": "/datastore//c08fee8e-caf4-4217-ab4d-351a021c2c3d", "encrypted": false, "bps": 0, "bps_rd": 0, "cache": {"no-flush": false, "direct": true, "writeback": true}, "file": "/datastore/c08fee8e-caf4-4217-ab4d-351a021c2c3d-actice"}, "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", "type": "unknown"}]} + +we lost the bitmap bitmap-2022-09-19-16-10-23 +Additional information: +the bitmap attach the active bs, when changing the active bs ,the bitmap will be lost... diff --git a/results/classifier/118/unknown/1255303 b/results/classifier/118/unknown/1255303 new file mode 100644 index 00000000..774c284f --- /dev/null +++ b/results/classifier/118/unknown/1255303 @@ -0,0 +1,428 @@ +graphic: 0.897 +hypervisor: 0.889 +socket: 0.885 +peripherals: 0.882 +virtual: 0.880 +register: 0.866 +ppc: 0.866 +permissions: 0.865 +architecture: 0.863 +assembly: 0.860 +PID: 0.858 +semantic: 0.852 +user-level: 0.851 +device: 0.843 +performance: 0.836 +debug: 0.836 +arm: 0.833 +vnc: 0.829 +i386: 0.820 +risc-v: 0.814 +network: 0.810 +TCG: 0.807 +KVM: 0.804 +files: 0.803 +kernel: 0.800 +x86: 0.794 +VMM: 0.790 +boot: 0.782 +mistranslation: 0.729 + +ALSA underruns occurr when using QEMU + +I'm running QEMU 1.6.1 on a 64-bit Gentoo Linux system. The guest operating system is Windows 7 32-bit. I get multiple identical warning messages when using the ac97 or hda sound cards: + +> ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.27.2/work/alsa-lib-1.0.27.2/src/pcm/pcm.c:7843:(snd_pcm_recover) underrun occurred + +The difference between ac97 and hda is that the former works well, while the latter causes the sound to be garbled. + +/var/tmp/portage is the directory where Portage, the Gentoo package manager, builds programs. I don't know why it is mentioned in the error message. + +I also don't know if this is an ALSA problem or a QEMU problem. + +The command I use is: + +> qemu-system-i386 -cpu host -m 1G -k it -drive file=~/QEMU/Windows_7_Privato.qcow2,media=disk,index=0 -vga std -net nic -net user -enable-kvm -display sdl -soundhw ac97 -device usb-ehci,id=ehci -usb -rtc base=localtime -usbdevice tablet + +My real sound card is an Intel HD Audio: + +> lspci | grep "Audio device" + +> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) + +Please tell me if you need other informations. + +QEmu is more or less unusable here because of this: + +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred +ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred + + +More info: + +Host: Linux 4.3.3 vanilla/CentOS 6.7 i686 +ALSA: alsa-lib-1.0.22-3.el6.i686 + +Qemu: 2.5 + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (currently v2.9)? + +I'm still using Gentoo Linux on the same 64-bit system, and I can still reproduce this bug: + +qemu-system-i386 -cpu host -m 1G -k it -drive file=~/qemu/windows-7-ultimate-x86.qcow2,media=disk,index=0 -vga std -net nic -net user -enable-kvm -display sdl -soundhw ac97 -device usb-ehci,id=ehci -usb -rtc base=localtime -usbdevice tablet +audio: Failed to create voice `ac97.pi' +audio: Failed to create voice `ac97.mc' +audio: Failed to create voice `ac97.pi' +audio: Failed to create voice `ac97.mc' +ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.1.4/work/alsa-lib-1.1.4/src/pcm/pcm.c:8321:(snd_pcm_recover) underrun occurred + +$ emerge -pv qemu alsa-lib + +These are the packages that would be merged, in order: + +Calculating dependencies... done! +[ebuild R ] media-libs/alsa-lib-1.1.4::gentoo USE="python -alisp -debug -doc" PYTHON_TARGETS="python2_7" 0 KiB +[ebuild R ] app-emulation/qemu-2.9.0-r54::gentoo USE="aio alsa bzip2 curl fdt gnutls jpeg lzo ncurses nls opengl pin-upstream-blobs png python sdl seccomp usb vhost-net -accessibility -bluetooth -caps -debug -filecaps -glusterfs -gtk -gtk2 -infiniband -iscsi -nfs -numa -pulseaudio -rbd -sasl -sdl2 (-selinux) -smartcard -snappy -spice -ssh -static -static-user -systemtap -tci {-test} -usbredir -vde -virgl -virtfs -vnc -vte -xattr -xen -xfs" LINGUAS="-bg -de_DE -fr_FR -hu -it -tr -zh_CN" PYTHON_TARGETS="python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64 -aarch64 -alpha -arm -cris -lm32 -m68k -microblaze -microblazeel -mips -mips64 -mips64el -mipsel -moxie -nios2 -or1k -ppc -ppc64 -ppcemb -s390x -sh4 -sh4eb -sparc -sparc64 -tricore -unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="-aarch64 -alpha -arm -armeb -cris -hppa -i386 -m68k -microblaze -microblazeel -mips -mips64 -mips64el -mipsel -mipsn32 -mipsn32el -nios2 -or1k -ppc -ppc64 -ppc64abi32 -ppc64le -s390x -sh4 -sh4eb -sparc -sparc32plus -sparc64 -tilegx -x86_64" 0 KiB + + +This is an automated cleanup. This bug report has been moved +to QEMU's new bug tracker on gitlab.com and thus gets marked +as 'expired' now. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/69 + + diff --git a/results/classifier/118/unknown/1285363 b/results/classifier/118/unknown/1285363 new file mode 100644 index 00000000..18365e5c --- /dev/null +++ b/results/classifier/118/unknown/1285363 @@ -0,0 +1,152 @@ +mistranslation: 0.838 +user-level: 0.835 +permissions: 0.789 +peripherals: 0.787 +device: 0.783 +architecture: 0.780 +arm: 0.772 +register: 0.765 +performance: 0.765 +virtual: 0.761 +files: 0.757 +debug: 0.756 +semantic: 0.752 +assembly: 0.742 +ppc: 0.735 +vnc: 0.735 +graphic: 0.733 +PID: 0.729 +VMM: 0.728 +boot: 0.727 +network: 0.726 +risc-v: 0.725 +x86: 0.725 +socket: 0.721 +TCG: 0.718 +KVM: 0.708 +hypervisor: 0.701 +kernel: 0.693 +i386: 0.663 + +qemu-aarch64-static segfaults + +I've found a couple conditions that causes qemu-user-static to core dump fairly reliably - same with upstream git - while a binary built from suse's aarch64-1.6 branch seems to consistently work fine. + +Testing suggests they are resolved by the sigprocmask wrapper patches included in suse's tree. + + 1) dh_fixperms is a script that commonly runs at the end of a package build. + Its basically doing a `find | xargs chmod`. + 2) debootstrap --second-stage + This is used to configure an arm64 chroot that was built using + debootstrap on a non-native host. It is basically invoking a bunch of + shell scripts (postinst, etc). When it blows up, the stack consistently + looks like this: + +Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e +/debootstrap/debootstrap --second-stage'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); +(gdb) bt +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +#1 stq_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:280 +#2 stq_le_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:315 +#3 target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678, +sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167 +#4 target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0 +<sigact_table+512>, info=info@entry=0x0, set=set@entry=0x7fff62ae3530, +env=env@entry=0x62d9c678) + at /mnt/qemu.upstream/linux-user/signal.c:1286 +#5 0x0000000060059f46 in setup_frame (env=0x62d9c678, +set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at +/mnt/qemu.upstream/linux-user/signal.c:1322 +#6 process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/signal.c:5747 +#7 0x0000000060056e60 in cpu_loop (env=env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/main.c:1082 +#8 0x0000000060005079 in main (argc=<optimized out>, argv=<optimized +out>, envp=<optimized out>) at +/mnt/qemu.upstream/linux-user/main.c:4374 + + + +The attachment "qemu.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. + +[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] + +I'm a little nervous about the do_sigprocmask in linux-user/signal.c for all arches. With the comment + +/* Force set state of SIGSEGV, may be best for some apps, maybe not so good +++ * This is not required for qemu to work + +Doing this conditionally for arm64 would be more comforting... + +I'll go ahead and run some tests with it tomorrow on amd64. + +Dann, + +can you confirm that you can reproduce this with the upstream git head (or the qemu-2.0~git package)? + +I'm building a candidate package with a modified version of the patchset (to only change behavior for aarch64 targets) in ppa:serge-hallyn/virt. + +On Thu, Feb 27, 2014 at 3:34 PM, Serge Hallyn +<email address hidden> wrote: +> Dann, +> +> can you confirm that you can reproduce this with the upstream git head +> (or the qemu-2.0~git package)? + +I just reverified with upstream git head @ +9fbee91a131a05e443d7108d7fbdf3ca91020290. +Note that this appears to only be reproducible on systems with > 1 CPU +(easy to reproduce on 4). + + +@Serge: I can confirm that this is fixed in 1.7.0+dfsg-3ubuntu5sig1 from your ppa. + +Doing this only for aarch64 targets seems like a bad idea to me -- this isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own handler (so we can unprotect pages we've marked as read-only in order to catch guest writes to them so we can throw away invalidated translated code), and that's true for all targets. It probably just happens more often on the aarch64 target than others you've tested because aarch64 has a signal-return trampoline on the stack frame, so we'll often see that page get translated and thrown away again. (Other targets with a trampoline include sparc, cris, openrisc and ppc.) + +PS: the comment "this is not required for qemu to work" just means that QEMU will work fine whether we tell the guest a lie about what's going on with SIGSEGV in one way (saying "it's blocked") or the other (saying "it's not blocked"). + + +Quoting Peter Maydell (<email address hidden>): +> Doing this only for aarch64 targets seems like a bad idea to me -- this +> isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own +> handler (so we can unprotect pages we've marked as read-only in order to +> catch guest writes to them so we can throw away invalidated translated +> code), and that's true for all targets. It probably just happens more +> often on the aarch64 target than others you've tested because aarch64 +> has a signal-return trampoline on the stack frame, so we'll often see +> that page get translated and thrown away again. (Other targets with a +> trampoline include sparc, cris, openrisc and ppc.) + +I see. I've just pushed the customized patch to the archive. We can +switch to the original patchset though. But, I'd also like to see what +ends up hitting upstream. + + +This bug was fixed in the package qemu - 1.7.0+dfsg-3ubuntu5 + +--------------- +qemu (1.7.0+dfsg-3ubuntu5) trusty; urgency=medium + + [ dann frazier ] + * Add patches from the susematz tree to avoid intermittent segfaults: + - ubuntu/signal-added-a-wrapper-for-sigprocmask-function.patch + - ubuntu/signal-sigsegv-protection-on-do_sigprocmask.patch + - ubuntu/Don-t-block-SIGSEGV-at-more-places.patch + + [ Serge Hallyn ] + * Modify do_sigprocmask to only change behavior for aarch64. + (LP: #1285363) + -- Serge Hallyn <email address hidden> Thu, 06 Mar 2014 16:15:50 -0600 + +We've now overhauled the signal handling code in upstream QEMU, and it has its own implementation of the basic idea in the patch from comment 1 (which is "don't let the guest block SIGSEGV"). + + diff --git a/results/classifier/118/unknown/1305402 b/results/classifier/118/unknown/1305402 new file mode 100644 index 00000000..306161cb --- /dev/null +++ b/results/classifier/118/unknown/1305402 @@ -0,0 +1,129 @@ +user-level: 0.926 +mistranslation: 0.883 +peripherals: 0.868 +KVM: 0.865 +network: 0.852 +hypervisor: 0.851 +risc-v: 0.848 +graphic: 0.840 +debug: 0.833 +permissions: 0.826 +TCG: 0.826 +x86: 0.822 +vnc: 0.821 +semantic: 0.813 +files: 0.813 +virtual: 0.810 +VMM: 0.808 +performance: 0.801 +ppc: 0.798 +assembly: 0.795 +socket: 0.794 +register: 0.790 +device: 0.789 +architecture: 0.784 +PID: 0.777 +arm: 0.769 +kernel: 0.768 +boot: 0.744 +i386: 0.731 + +libvirt fails to start VirtualMachines + +I've created several kvm based machines with the 'trusty' designation using virtual machine manager. They have operated well over the last 4 days without issue. I did an apt-get upgrade, and qemu was in the list of updates. + +After upgrading, I am unable to start any of the provisioned virtual machines with the following error output + +virsh # start node2 +error: Failed to start domain node2 +error: internal error: process exited while connecting to monitor: qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! + + +virsh # start node3 +error: Failed to start domain node3 +error: internal error: process exited while connecting to monitor: qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! + + + +$ dpkg -l | grep kvm +ii qemu-kvm 2.0.0~rc1+dfsg-0ubuntu3 amd64 QEMU Full virtualization on x86 hardware (transitional package) + +Log snippet from vm 'media' that was verified working, and fails to start after the upgrade. + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name media -S -machine trusty,accel=kvm,usb=off -m 1548 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 60b20f7b-6d20-bcb3-f4fc-808a9b2fe0d0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/media.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/media.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/charles/iso/ubuntu-desktop-12.04.4-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a0:69:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 +char device redirected to /dev/pts/13 (label charserial0) +qemu: terminating on signal 15 from pid 31688 +2014-04-10 03:36:54.593+0000: shutting down +2014-04-10 03:59:25.487+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name media -S -machine trusty,accel=kvm,usb=off -m 1548 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 60b20f7b-6d20-bcb3-f4fc-808a9b2fe0d0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/media.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/media.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/charles/iso/ubuntu-desktop-12.04.4-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a0:69:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 +qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! +2014-04-10 03:59:25.696+0000: shutting down + +After some additional investigating it looks like the XML format for the trusty machine has changed. I created a new VM and got it to boot off my MAAS cluster, The immediate change I see is: + +new: + <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type> + +old: + <type arch='x86_64' machine='trusty'>hvm</type> + +None of the old XML machines were updated with this new machine flag. + +Thanks for reporting this bug. We briefly had a 'trusty' machine type, with a corresponding libvirt patch to handle it. When we renamed the trusty machine type we dropped the libvirt patch to handle it. + +We should either re-introduce the libvirt patch to handle the trusty machine type for those who have stale VM definitions, or mention this in the release notes. In either case we should keep this bug open to guide others who run into this problem. + +This has just happened to me. For some reason, all my machines had machine='pc-i440fx-wily'. +After an update in yakkety, they stopped working. + +$ qemu-system-x86_64 -enable-kvm -machine help | grep wily + +So I updated the machine xml to a supported machine as Charles suggested, and they work again. + +Here's the note for my future self about how to do the update: + +$ virsh dumpxml $machine-name > /tmp/machine.xml +Edit the xml. +$ virsh define /tmp/machine.xml + +Machine type changes may be related to: + +https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1626070 + +There's a PPA in the bug with a fix for at least the wily machine type. + +On Thu, Sep 22, 2016 at 6:05 PM, Leo Arias <email address hidden> wrote: + +> This has just happened to me. For some reason, all my machines had +> machine='pc-i440fx-wily'. +> After an update in yakkety, they stopped working. +> +> $ qemu-system-x86_64 -enable-kvm -machine help | grep wily +> +> So I updated the machine xml to a supported machine as Charles +> suggested, and they work again. +> +> Here's the note for my future self about how to do the update: +> +> $ virsh dumpxml $machine-name > /tmp/machine.xml +> Edit the xml. +> $ virsh define /tmp/machine.xml +> +> -- +> You received this bug notification because you are subscribed to qemu in +> Ubuntu. +> https://bugs.launchpad.net/bugs/1305402 +> +> Title: +> libvirt fails to start VirtualMachines +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1305402/+subscriptions +> + + +Yeah I'm pretty sure this is a dupe of bug 1626070. + diff --git a/results/classifier/118/unknown/1319100 b/results/classifier/118/unknown/1319100 new file mode 100644 index 00000000..d04e5c2e --- /dev/null +++ b/results/classifier/118/unknown/1319100 @@ -0,0 +1,165 @@ +peripherals: 0.895 +permissions: 0.880 +user-level: 0.879 +risc-v: 0.874 +mistranslation: 0.865 +TCG: 0.856 +debug: 0.848 +register: 0.842 +KVM: 0.842 +assembly: 0.839 +x86: 0.830 +hypervisor: 0.826 +device: 0.820 +architecture: 0.818 +vnc: 0.815 +VMM: 0.806 +performance: 0.802 +socket: 0.800 +arm: 0.797 +kernel: 0.795 +semantic: 0.793 +graphic: 0.789 +network: 0.779 +ppc: 0.774 +virtual: 0.765 +PID: 0.761 +boot: 0.761 +i386: 0.734 +files: 0.729 + +qemu-arm-static bug in signal handling causes mono and java to hang + +Note, this bug is already reported to debian, but it seems to also affect the upstream code. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748043 + +running mono in a chroot environment with qemu-user-static is not posible +because at least one signal used during termination of mono is routed to the +host. + +This can be reproduced by: +debootstrap --include=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +cp /usr/bin/qemu-arm-static mono-test/usr/bin +mount -t proc none mono-test/proc +mount -o bind /dev mono-test/dev +mount -o bind /sys mono-test/sys +chroot mono-test +../debootstrap/debootstrap --second-stage +exit +mount -t proc none mono-test/proc +mount -o bind /sys mono-test/sys +chroot mono-test +QEMU_STRACE=1 /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +This will block on a futex: + +--8<-- +18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +--8<-- + +If you use mono within strace on a native x86 box you can see, that signals +between threads are used during termination: + +strace -f -o log.txt /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +--8<-- +14075 sched_yield() = 0 +14075 tgkill(14075, 14083, SIGPWR) = 0 +14075 futex(0x983f00, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...> +14083 <... futex resumed> ) = ? ERESTARTSYS (To be restarted) +14083 --- SIGPWR (Power failure) @ 0 (0) --- +14083 futex(0x983f00, FUTEX_WAKE_PRIVATE, 1) = 1 +14075 <... futex resumed> ) = 0 +14083 rt_sigsuspend(~[INT QUIT ABRT TERM XCPU RTMIN RT_1] <unfinished ...> +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 24) = 3 +14078 <... futex resumed> ) = 0 +14078 futex(0x94da20, FUTEX_WAKE_PRIVATE, 1) = 1 +14077 <... futex resumed> ) = 0 +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 26 <unfinished ...> +--8<-- + +This also blocks the installation of libnunit2.6-cil within a armel chroot, +because it uses mono in its postinst script. +E.g. (/usr/bin/mono /usr/share/mono/MonoGetAssemblyName.exe /usr/lib/cli/nunit.core-2.6/nunit.core.dll) + +Obviously the same as described in: +http://lists.opensuse.org/opensuse-arm/2011-12/msg00000.html +is happening here. + +There is an openSuSE patch against qemu: +https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +This patch also applies against qemu from backports-wheezy and resolves this +issue. + +As it seems, that this issue is not Debian specific i will also report it to +the qemu project and reference this bug report. + +On 13 May 2014 16:56, manut <email address hidden> wrote: +> running mono in a chroot environment with qemu-user-static is not posible +> because at least one signal used during termination of mono is routed to the +> host. +> +> This can be reproduced by: +> debootstrap --include=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +> cp /usr/bin/qemu-arm-static mono-test/usr/bin +> mount -t proc none mono-test/proc +> mount -o bind /dev mono-test/dev +> mount -o bind /sys mono-test/sys +> chroot mono-test +> ../debootstrap/debootstrap --second-stage +> exit +> mount -t proc none mono-test/proc +> mount -o bind /sys mono-test/sys +> chroot mono-test +> QEMU_STRACE=1 /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe +> +> This will block on a futex: +> +> --8<-- +> 18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +> 18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +> 18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +> 18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +> --8<-- +> +> If you use mono within strace on a native x86 box you can see, that signals +> between threads are used during termination: + +Multithreaded guest process are unreliable under qemu +linux-user mode anyway, even ignoring the signal handling +related races here. + +See also: +https://bugs.launchpad.net/qemu/+bug/955379 + +> There is an openSuSE patch against qemu: +> https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +This patch is a very hacky bandaid papering over the +real problem. It is not suitable for upstream (and +personally I wouldn't ship it in a distro either :-)). + +thanks +-- PMM + + +Status changed to 'Confirmed' because the bug affects multiple users. + +also causes problems with java. + +Recent changes to QEMU's handling of signals fix this hang trying to run mono under QEMU; they should be out in QEMU 2.7. + + +Did this fix end up making it into QEMU 2.7? + +Yes it did. + + +Fixed in 2.7 and thereby >=Zesty + +I can't guess very well how important this would be for an SRU (or not), leaving that up for user feedback to be decided. + diff --git a/results/classifier/118/unknown/13442371 b/results/classifier/118/unknown/13442371 new file mode 100644 index 00000000..d94f46bd --- /dev/null +++ b/results/classifier/118/unknown/13442371 @@ -0,0 +1,394 @@ +TCG: 0.901 +user-level: 0.899 +peripherals: 0.889 +ppc: 0.884 +device: 0.883 +assembly: 0.877 +virtual: 0.872 +KVM: 0.872 +hypervisor: 0.872 +register: 0.871 +i386: 0.870 +arm: 0.867 +debug: 0.866 +mistranslation: 0.859 +vnc: 0.858 +permissions: 0.854 +graphic: 0.850 +semantic: 0.850 +PID: 0.849 +architecture: 0.846 +risc-v: 0.846 +VMM: 0.843 +kernel: 0.842 +performance: 0.841 +files: 0.837 +x86: 0.836 +socket: 0.831 +boot: 0.815 +network: 0.811 + +[Qemu-devel] [BUG] nanoMIPS support problem related to extract2 support for i386 TCG target + +Hello, Richard, Peter, and others. + +As a part of activities before 4.1 release, I tested nanoMIPS support +in QEMU (which was officially fully integrated in 4.0, is currently +limited to system mode only, and was tested in a similar fashion right +prior to 4.0). + +This support appears to be broken now. Following command line works in +4.0, but results in kernel panic for the current tip of the tree: + +~/Build/qemu-test-revert-c6fb8c0cf704/mipsel-softmmu/qemu-system-mipsel +-cpu I7200 -kernel generic_nano32r6el_page4k -M malta -serial stdio -m +1G -hda nanomips32r6_le_sf_2017.05-03-59-gf5595d6.ext4 -append +"mem=256m@0x0 rw console=ttyS0 vga=cirrus vesa=0x111 root=/dev/sda" + +(kernel and rootfs image files used in this commend line can be +downloaded from the locations mentioned in our user guide) + +The quick bisect points to the commit: + +commit c6fb8c0cf704c4a1a48c3e99e995ad4c58150dab +Author: Richard Henderson <address@hidden> +Date: Mon Feb 25 11:42:35 2019 -0800 + + tcg/i386: Support INDEX_op_extract2_{i32,i64} + + Signed-off-by: Richard Henderson <address@hidden> + +Please advise on further actions. + +Yours, +Aleksandar + +On Fri, Jul 12, 2019 at 8:09 PM Aleksandar Markovic +<address@hidden> wrote: +> +> +Hello, Richard, Peter, and others. +> +> +As a part of activities before 4.1 release, I tested nanoMIPS support +> +in QEMU (which was officially fully integrated in 4.0, is currently +> +limited to system mode only, and was tested in a similar fashion right +> +prior to 4.0). +> +> +This support appears to be broken now. Following command line works in +> +4.0, but results in kernel panic for the current tip of the tree: +> +> +~/Build/qemu-test-revert-c6fb8c0cf704/mipsel-softmmu/qemu-system-mipsel +> +-cpu I7200 -kernel generic_nano32r6el_page4k -M malta -serial stdio -m +> +1G -hda nanomips32r6_le_sf_2017.05-03-59-gf5595d6.ext4 -append +> +"mem=256m@0x0 rw console=ttyS0 vga=cirrus vesa=0x111 root=/dev/sda" +> +> +(kernel and rootfs image files used in this commend line can be +> +downloaded from the locations mentioned in our user guide) +> +> +The quick bisect points to the commit: +> +> +commit c6fb8c0cf704c4a1a48c3e99e995ad4c58150dab +> +Author: Richard Henderson <address@hidden> +> +Date: Mon Feb 25 11:42:35 2019 -0800 +> +> +tcg/i386: Support INDEX_op_extract2_{i32,i64} +> +> +Signed-off-by: Richard Henderson <address@hidden> +> +> +Please advise on further actions. +> +Just to add a data point: + +If the following change is applied: + +diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h +index 928e8b8..b6a4cf2 100644 +--- a/tcg/i386/tcg-target.h ++++ b/tcg/i386/tcg-target.h +@@ -124,7 +124,7 @@ extern bool have_avx2; + #define TCG_TARGET_HAS_deposit_i32 1 + #define TCG_TARGET_HAS_extract_i32 1 + #define TCG_TARGET_HAS_sextract_i32 1 +-#define TCG_TARGET_HAS_extract2_i32 1 ++#define TCG_TARGET_HAS_extract2_i32 0 + #define TCG_TARGET_HAS_movcond_i32 1 + #define TCG_TARGET_HAS_add2_i32 1 + #define TCG_TARGET_HAS_sub2_i32 1 +@@ -163,7 +163,7 @@ extern bool have_avx2; + #define TCG_TARGET_HAS_deposit_i64 1 + #define TCG_TARGET_HAS_extract_i64 1 + #define TCG_TARGET_HAS_sextract_i64 0 +-#define TCG_TARGET_HAS_extract2_i64 1 ++#define TCG_TARGET_HAS_extract2_i64 0 + #define TCG_TARGET_HAS_movcond_i64 1 + #define TCG_TARGET_HAS_add2_i64 1 + #define TCG_TARGET_HAS_sub2_i64 1 + +... the problem disappears. + + +> +Yours, +> +Aleksandar + +On Fri, Jul 12, 2019 at 8:19 PM Aleksandar Markovic +<address@hidden> wrote: +> +> +On Fri, Jul 12, 2019 at 8:09 PM Aleksandar Markovic +> +<address@hidden> wrote: +> +> +> +> Hello, Richard, Peter, and others. +> +> +> +> As a part of activities before 4.1 release, I tested nanoMIPS support +> +> in QEMU (which was officially fully integrated in 4.0, is currently +> +> limited to system mode only, and was tested in a similar fashion right +> +> prior to 4.0). +> +> +> +> This support appears to be broken now. Following command line works in +> +> 4.0, but results in kernel panic for the current tip of the tree: +> +> +> +> ~/Build/qemu-test-revert-c6fb8c0cf704/mipsel-softmmu/qemu-system-mipsel +> +> -cpu I7200 -kernel generic_nano32r6el_page4k -M malta -serial stdio -m +> +> 1G -hda nanomips32r6_le_sf_2017.05-03-59-gf5595d6.ext4 -append +> +> "mem=256m@0x0 rw console=ttyS0 vga=cirrus vesa=0x111 root=/dev/sda" +> +> +> +> (kernel and rootfs image files used in this commend line can be +> +> downloaded from the locations mentioned in our user guide) +> +> +> +> The quick bisect points to the commit: +> +> +> +> commit c6fb8c0cf704c4a1a48c3e99e995ad4c58150dab +> +> Author: Richard Henderson <address@hidden> +> +> Date: Mon Feb 25 11:42:35 2019 -0800 +> +> +> +> tcg/i386: Support INDEX_op_extract2_{i32,i64} +> +> +> +> Signed-off-by: Richard Henderson <address@hidden> +> +> +> +> Please advise on further actions. +> +> +> +> +Just to add a data point: +> +> +If the following change is applied: +> +> +diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h +> +index 928e8b8..b6a4cf2 100644 +> +--- a/tcg/i386/tcg-target.h +> ++++ b/tcg/i386/tcg-target.h +> +@@ -124,7 +124,7 @@ extern bool have_avx2; +> +#define TCG_TARGET_HAS_deposit_i32 1 +> +#define TCG_TARGET_HAS_extract_i32 1 +> +#define TCG_TARGET_HAS_sextract_i32 1 +> +-#define TCG_TARGET_HAS_extract2_i32 1 +> ++#define TCG_TARGET_HAS_extract2_i32 0 +> +#define TCG_TARGET_HAS_movcond_i32 1 +> +#define TCG_TARGET_HAS_add2_i32 1 +> +#define TCG_TARGET_HAS_sub2_i32 1 +> +@@ -163,7 +163,7 @@ extern bool have_avx2; +> +#define TCG_TARGET_HAS_deposit_i64 1 +> +#define TCG_TARGET_HAS_extract_i64 1 +> +#define TCG_TARGET_HAS_sextract_i64 0 +> +-#define TCG_TARGET_HAS_extract2_i64 1 +> ++#define TCG_TARGET_HAS_extract2_i64 0 +> +#define TCG_TARGET_HAS_movcond_i64 1 +> +#define TCG_TARGET_HAS_add2_i64 1 +> +#define TCG_TARGET_HAS_sub2_i64 1 +> +> +... the problem disappears. +> +It looks the problem is in this code segment in of tcg_gen_deposit_i32(): + + if (ofs == 0) { + tcg_gen_extract2_i32(ret, arg1, arg2, len); + tcg_gen_rotli_i32(ret, ret, len); + goto done; + } + +) + +If that code segment is deleted altogether (which effectively forces +usage of "fallback" part of tcg_gen_deposit_i32()), the problem also +vanishes (without changes from my previous mail). + +> +> +> Yours, +> +> Aleksandar + +Aleksandar Markovic <address@hidden> writes: + +> +Hello, Richard, Peter, and others. +> +> +As a part of activities before 4.1 release, I tested nanoMIPS support +> +in QEMU (which was officially fully integrated in 4.0, is currently +> +limited to system mode only, and was tested in a similar fashion right +> +prior to 4.0). +> +> +This support appears to be broken now. Following command line works in +> +4.0, but results in kernel panic for the current tip of the tree: +> +> +~/Build/qemu-test-revert-c6fb8c0cf704/mipsel-softmmu/qemu-system-mipsel +> +-cpu I7200 -kernel generic_nano32r6el_page4k -M malta -serial stdio -m +> +1G -hda nanomips32r6_le_sf_2017.05-03-59-gf5595d6.ext4 -append +> +"mem=256m@0x0 rw console=ttyS0 vga=cirrus vesa=0x111 root=/dev/sda" +> +> +(kernel and rootfs image files used in this commend line can be +> +downloaded from the locations mentioned in our user guide) +> +> +The quick bisect points to the commit: +> +> +commit c6fb8c0cf704c4a1a48c3e99e995ad4c58150dab +> +Author: Richard Henderson <address@hidden> +> +Date: Mon Feb 25 11:42:35 2019 -0800 +> +> +tcg/i386: Support INDEX_op_extract2_{i32,i64} +> +> +Signed-off-by: Richard Henderson <address@hidden> +> +> +Please advise on further actions. +Please see the fix: + + Subject: [PATCH for-4.1] tcg: Fix constant folding of INDEX_op_extract2_i32 + Date: Tue, 9 Jul 2019 14:19:00 +0200 + Message-Id: <address@hidden> + +> +> +Yours, +> +Aleksandar +-- +Alex Bennée + +On Sat, Jul 13, 2019 at 9:21 AM Alex Bennée <address@hidden> wrote: +> +> +Please see the fix: +> +> +Subject: [PATCH for-4.1] tcg: Fix constant folding of INDEX_op_extract2_i32 +> +Date: Tue, 9 Jul 2019 14:19:00 +0200 +> +Message-Id: <address@hidden> +> +Thanks, this fixed the behavior. + +Sincerely, +Aleksandar + +> +> +> +> +> Yours, +> +> Aleksandar +> +> +> +-- +> +Alex Bennée +> + diff --git a/results/classifier/118/unknown/1385934 b/results/classifier/118/unknown/1385934 new file mode 100644 index 00000000..c554fcc9 --- /dev/null +++ b/results/classifier/118/unknown/1385934 @@ -0,0 +1,183 @@ +user-level: 0.928 +device: 0.904 +risc-v: 0.901 +KVM: 0.899 +hypervisor: 0.891 +graphic: 0.890 +x86: 0.884 +permissions: 0.880 +assembly: 0.875 +virtual: 0.873 +mistranslation: 0.858 +VMM: 0.857 +semantic: 0.856 +architecture: 0.852 +peripherals: 0.841 +TCG: 0.839 +ppc: 0.836 +debug: 0.834 +boot: 0.829 +files: 0.828 +PID: 0.827 +kernel: 0.818 +vnc: 0.814 +register: 0.809 +network: 0.806 +performance: 0.790 +socket: 0.778 +arm: 0.777 +i386: 0.765 + +USB with passthrougth guest cannot enumerate USB host + +Following the guide at http://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest +Qemu is launched with qemu-system-x86_64 /dev/vgstripe/kvm_wifi -enable-kvm -m 512 -k fr -net nic -net tap,ifname=tap1,script=/bin/ifup.script -kernel /usr/src/linux_git/arch/x86_64/boot/bzImage -append root=/dev/sda -usb -device usb-host,hostbus=1,hostaddr=6 +The USB device does not show and USB stack seems not working +On the guest: +dmesg |grep -i usb +[ 1.416966] hub 1-0:1.0: USB hub found +[ 1.420431] usbcore: registered new interface driver usb-storage +[ 1.445374] usbcore: registered new interface driver usbhid +[ 1.446839] usbhid: USB HID core driver +[ 1.863226] usb 1-1: new low-speed USB device number 2 using uhci_hcd +[ 2.126173] usb 1-1: Invalid ep0 maxpacket: 64 +[ 2.373161] usb 1-1: new low-speed USB device number 3 using uhci_hcd +[ 2.648112] usb 1-1: Invalid ep0 maxpacket: 64 +[ 2.892404] usb 1-1: new low-speed USB device number 4 using uhci_hcd +[ 2.913001] usb 1-1: Invalid ep0 maxpacket: 64 +[ 3.161367] usb 1-1: new low-speed USB device number 5 using uhci_hcd +[ 3.180070] usb 1-1: Invalid ep0 maxpacket: 64 +[ 3.181633] usb usb1-port1: unable to enumerate USB device +lsusb +Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub + +On the host: +lsusb +Bus 001 Device 006: ID 0457:0163 Silicon Integrated Systems Corp. SiS163U 802.11 Wireless LAN Adapter +qemu-system-x86_64 --version +QEMU emulator version 2.1.2, Copyright (c) 2003-2008 Fabrice Bellard + +You might try connecting the device to a ehci/xhci bus (instead of the default uhci bus... i.e. USB 1.1). See docs/usb2.txt in the qemu source for more info. + +the problem is this commit: +http://git.qemu.org/?p=qemu.git;a=commit;h=b791c3b38c7969cb9f4acda8229e19fd865a1c08 + +it's easy to reproduce -- plug in a USB flash drive and try to pass it through + +on the host: +$ lsusb +Bus 003 Device 004: ID 1307:0163 Transcend Information, Inc. 256MB/512MB/1GB Flash Drive + +so launch qemu with that: + -usbdevice host:1307:0163 + +and then in the VM, if it fails, you get those errors in dmesg, and the device doesn't show up in `lsusb`. if it passes, `lsusb` reports it fine. + +On 2014/11/9 2:47, MikeFrysinger wrote: + +> the problem is this commit: +> http://git.qemu.org/?p=qemu.git;a=commit;h=b791c3b38c7969cb9f4acda8229e19fd865a1c08 +> +> it's easy to reproduce -- plug in a USB flash drive and try to pass it +> through +> + +What's your USB flash drive's version? USB1.1 or USB2.0 or 3.0? +Please post the value: + +1.cat /sys/bus/usb/device/xx-xx/speed [xx-xx: hostbus-hostport] +2.And your exact command line launched Qemu . + +Best regards, +-Gonglei + +> on the host: +> $ lsusb +> Bus 003 Device 004: ID 1307:0163 Transcend Information, Inc. 256MB/512MB/1GB Flash Drive +> +> so launch qemu with that: +> -usbdevice host:1307:0163 +> +> and then in the VM, if it fails, you get those errors in dmesg, and the +> device doesn't show up in `lsusb`. if it passes, `lsusb` reports it +> fine. +> + + + + + +i've attached the `lsusb -v` output for the device. it is USB 2.0. the sysfs speed file shows 480. + +the qemu cmdline: +qemu-system-x86_64 \ + -hda images/root \ + -hdb images/var \ + -hdc images/usr \ + -append "root=/dev/hda console=ttyS0 panic=3 init=/ginit" \ + -kernel images/bzImage \ + -nographic \ + -no-reboot \ + -m 512 \ + -enable-kvm \ + -usbdevice host:1307:0163 + +On 2014/11/11 1:52, MikeFrysinger wrote: + +> i've attached the `lsusb -v` output for the device. it is USB 2.0. the +> sysfs speed file shows 480. +> + +You should add an ehci controller or xhci for USB2.0 device. +Please use such below cmdline: +-device usb-ehci,id=ehci \ +-device usb-host,bus=ehci.0,vendorid=1307,productid=0163 + +BTW, This is a really bug, and Gerd had posted a patch: + [PATCH] usb-host: fix usb_host_speed_compat tyops +http://lists.gnu.org/archive/html/qemu-devel/2014-11/msg01441.html + +After applying this patch, you will get a warning: + "Warning: speed mismatch trying to attach..." if you use the cmdline as your showing. + +Thanks, +-Gonglei + +> the qemu cmdline: +> qemu-system-x86_64 \ +> -hda images/root \ +> -hdb images/var \ +> -hdc images/usr \ +> -append "root=/dev/hda console=ttyS0 panic=3 init=/ginit" \ +> -kernel images/bzImage \ +> -nographic \ +> -no-reboot \ +> -m 512 \ +> -enable-kvm \ +> -usbdevice host:1307:0163 +> +> ** Attachment added: "lsusb.txt" +> https://bugs.launchpad.net/qemu/+bug/1385934/+attachment/4257409/+files/lsusb.txt +> + + + + + +Can you check if the same error messages appear in /var/log/syslog and /var/log/libvirt/qemu/<machine>.log as I described in bug #1392504? Because I think it is apparmor related. + +looks like 79ae25af1569a50a0ec799901a1bb280c088f121 (which is in qemu-2.2.0) makes it work again for my test case. not sure if the OP wants to verify as well or just close this out now. + +With qemu 2.2.0 I see now the usb dongle but using it give me some problem seen on the host: +libusb: error [submit_control_transfer] submiturb failed error -1 errno=22 +Disabling caps and seccomp change nothing. +I strace the process and I see: +26170 ioctl(20, USBDEVFS_SUBMITURB, 0x7f00c0539eb0) = -1 EINVAL (Invalid argument) +26170 write(2, "libusb: error [submit_control_transfer] submiturb failed error -1 errno=22\n", 75) = 75 + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1401798 b/results/classifier/118/unknown/1401798 new file mode 100644 index 00000000..4d75fdac --- /dev/null +++ b/results/classifier/118/unknown/1401798 @@ -0,0 +1,84 @@ +user-level: 0.881 +architecture: 0.856 +permissions: 0.847 +mistranslation: 0.835 +KVM: 0.824 +device: 0.818 +arm: 0.815 +register: 0.815 +graphic: 0.812 +virtual: 0.806 +TCG: 0.806 +peripherals: 0.805 +assembly: 0.805 +debug: 0.805 +VMM: 0.803 +vnc: 0.801 +x86: 0.798 +files: 0.796 +socket: 0.795 +performance: 0.789 +PID: 0.789 +i386: 0.774 +kernel: 0.771 +network: 0.770 +ppc: 0.766 +semantic: 0.751 +risc-v: 0.750 +hypervisor: 0.745 +boot: 0.738 + +Qemu 2.2.0 savevm crash. + +qemu 2.1.2 is good. + +(gdb) bt +#0 0x00007ffff4aae445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 +#1 0x00007ffff4ab1bab in abort () from /lib/x86_64-linux-gnu/libc.so.6 +#2 0x0000555555997951 in qcow2_cache_find_entry_to_replace (c=0x555556389780) at block/qcow2-cache.c:262 +#3 0x0000555555997a1a in qcow2_cache_do_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528, + read_from_disk=true) at block/qcow2-cache.c:285 +#4 0x0000555555997c45 in qcow2_cache_get (bs=0x5555563836f0, c=0x555556389780, offset=1094713344, table=0x7fffffffc528) + at block/qcow2-cache.c:331 +#5 0x0000555555991ca9 in l2_allocate (bs=0x5555563836f0, l1_index=1, table=0x7fffffffc5a0) at block/qcow2-cluster.c:247 +#6 0x000055555599290c in get_cluster_table (bs=0x5555563836f0, offset=549755813888, new_l2_table=0x7fffffffc610, + new_l2_index=0x7fffffffc62c) at block/qcow2-cluster.c:620 +#7 0x0000555555994213 in discard_single_l2 (bs=0x5555563836f0, offset=549755813888, nb_clusters=156, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1425 +#8 0x0000555555994491 in qcow2_discard_clusters (bs=0x5555563836f0, offset=549755813888, nb_sectors=638976, type=QCOW2_DISCARD_NEVER, + full_discard=false) at block/qcow2-cluster.c:1516 +#9 0x00005555559965c8 in qcow2_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/qcow2-snapshot.c:441 +#10 0x00005555559ad1ad in bdrv_snapshot_create (bs=0x5555563836f0, sn_info=0x7fffffffc830) at block/snapshot.c:167 +#11 0x000055555565e90f in do_savevm (mon=0x555556992d20, qdict=0x5555599d5c00) at /vms/qemu/qemu-2.2.0/savevm.c:1126 + +(gdb) show args +Argument list to give program being debugged when it is started is "-name u1404-01 -S -machine pc,accel=kvm,usb=off -m 1024 -smp 2,sockets=2,cores=1,threads=1 -no-user-config -nodefaults -monitor stdio -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/vms/images/u1404-01.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=directsync -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6". + +Maybe bdrv_snapshot_create() should take s->lock but it's not clear yet what causes all qcow2 cache entries to be referenced. + +How do you reproduce this crash? Please give exact steps including what commands to run inside the guest and what QEMU monitor commands to run. + +Is the crash deterministic (does it happen every time or with a random chance)? + +The bug can be reproduced every time. + +1. I install a Ubuntu 14.04 guest. +2. The monitor command is (qemu) snapshot_blkdev_internal drive-virtio-disk0 s1 +3. Or (qemu) savevm s1 + +I think I get the reason. + +From Qemu 2.2.0, in qcow2_open: l2_cache_size = MAX(DEFAULT_L2_CACHE_BYTE_SIZE/s->cluster_size, MIN_L2_CACHE_SIZE); +Here DEFAULT_L2_CACHE_BYTE_SIZE=1M, MIN_L2_CACHE_SIZE=1. + +If the cluster_size < 1M, the l2_cache_size will be greater than 1, it is ok. + +If the cluster_size>=1M, the l2_cache_size will be 1. After create snapshot, the first qcow2_co_writev will abort at qcow2_cache_find_entry_to_replace, because no free room in l2_table_cache. If change the MIN_L2_CACHE_SIZE to 16, it is ok. + + + + + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + diff --git a/results/classifier/118/unknown/1407 b/results/classifier/118/unknown/1407 new file mode 100644 index 00000000..9c614483 --- /dev/null +++ b/results/classifier/118/unknown/1407 @@ -0,0 +1,106 @@ +graphic: 0.915 +user-level: 0.892 +peripherals: 0.880 +mistranslation: 0.878 +TCG: 0.873 +ppc: 0.861 +register: 0.854 +x86: 0.847 +hypervisor: 0.844 +debug: 0.840 +KVM: 0.834 +permissions: 0.833 +VMM: 0.817 +semantic: 0.816 +vnc: 0.814 +arm: 0.803 +PID: 0.784 +performance: 0.779 +network: 0.777 +architecture: 0.772 +socket: 0.769 +assembly: 0.768 +virtual: 0.763 +boot: 0.761 +risc-v: 0.757 +device: 0.756 +kernel: 0.736 +i386: 0.727 +files: 0.723 + +Assertion failure in fimd_update_memory_section() +Description of problem: +It seems the frame buffer is not properly initialized before usage. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine smdkc210 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0x11c00020 0x3454d403 +writel 0x11c00000 0x61988eaf +EOF +``` +Additional information: +``` +==13250==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x5590b12d2240). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 3376651198 +INFO: Loaded 1 modules (583356 inline 8-bit counters): 583356 [0x5590b4672000, 0x5590b47006bc), +INFO: Loaded 1 PC tables (583356 PCs): 583356 [0x5590b3d8b3b0,0x5590b4671f70), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *exynos4210.fimd* +This process will fuzz the following MemoryRegions: + * exynos4210.fimd[0] (size 4114) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * exynos4210.fimd, EVENT_TYPE_MMIO_READ, 0x11c00000 +0x4114, 4,4 + * exynos4210.fimd, EVENT_TYPE_MMIO_WRITE, 0x11c00000 +0x4114, 4,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 227Mb +Running: poc-qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd-crash-eda3de9b6941dd8c14e22959b56dbe5d8d07dae3 +qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd: ../hw/display/exynos4210_fimd.c:1152: void fimd_update_memory_section(Exynos4210fimdState *, unsigned int): Assertion `w->mem_section.mr' failed. +==13250== ERROR: libFuzzer: deadly signal + #0 0x5590acce30ee in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x5590acc31d61 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x5590acc0ac96 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x5590acc0ad62 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x5590acc0ad62 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f9ed33c741f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f9ed31d900a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f9ed31d900a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f9ed31b8858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f9ed31b8728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f9ed31c9fd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x5590ad56dce3 in fimd_update_memory_section /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1152:5 + #12 0x5590ad565fb7 in exynos4210_fimd_enable /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1198:13 + #13 0x5590ad5590a3 in exynos4210_fimd_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/exynos4210_fimd.c:1387:13 + #14 0x5590b03e7bc3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5 + #15 0x5590b03e7501 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #16 0x5590b03e5e26 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16 + #17 0x5590b047669e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23 + #18 0x5590b046444b in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12 + #19 0x5590b0463f08 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18 + #20 0x5590acd23d38 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5 + #21 0x5590acd220a3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28 + #22 0x5590b12cd6bf in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #23 0x5590b12c4a3d in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #24 0x5590b12c47e4 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #25 0x5590acd2b07c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #26 0x5590b12d250b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #27 0x5590acc0b806 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #28 0x5590acbee434 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x5590acbf93de in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #30 0x5590acbe59c6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7f9ed31ba082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x5590acbe5a1d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-exynos4210-fimd+0x31cea1d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/118/unknown/1412098 b/results/classifier/118/unknown/1412098 new file mode 100644 index 00000000..fb94d1aa --- /dev/null +++ b/results/classifier/118/unknown/1412098 @@ -0,0 +1,131 @@ +graphic: 0.878 +ppc: 0.862 +user-level: 0.858 +KVM: 0.854 +hypervisor: 0.854 +permissions: 0.838 +device: 0.835 +TCG: 0.821 +performance: 0.820 +arm: 0.818 +socket: 0.818 +virtual: 0.816 +register: 0.814 +debug: 0.806 +semantic: 0.792 +network: 0.792 +risc-v: 0.785 +vnc: 0.776 +architecture: 0.775 +i386: 0.773 +peripherals: 0.765 +assembly: 0.761 +VMM: 0.756 +PID: 0.749 +files: 0.748 +boot: 0.745 +x86: 0.737 +kernel: 0.717 +mistranslation: 0.715 + +qemu crashes when ctrl-alt-u is pressed + +Qemu version: 2.2.0 release, compiled from source +Host OS: Windows 7 Ultimate x64 +Guest OS: not applicable, crash occurs even without OS and occurs with all OSs +Executable: qemu-system-i386.exe or qemu-system-i386w.exe + +To reproduce: +Start qemu-system-i386 or qemu-system-i386w without any options. Press CTRL-ALT-U, which is supposed to rescale the window. Instead, qemu just crashes. + +Compilation: +Qemu 2.2.0 release compiled from sources under MinGW on the host. +Configure options used: +'../qemu-2.2.0/configure' '--python=C:/Python27/python' '--prefix=/mingw/build/qemu-2.2.0-bin' '--target-list=i386-softmmu' + + + +I did a git bisect, and the offending commit appears to be this one: + +author Gerd Hoffmann <email address hidden> +Wed, 18 Jun 2014 09:03:15 +0000 (11:03 +0200) +committer Gerd Hoffmann <email address hidden> +Fri, 5 Sep 2014 11:27:11 +0000 (13:27 +0200) +commit 30f1e661b640de58ba1e8178f7f2290179a7e01c +tree dc373a0d374386bc793e67a9e185dbc5ecdfc8f1 tree | snapshot +parent 56bd9ea1a37395012adecca8b9c4762da15b01e7 commit | diff +console: stop using PixelFormat + +With this patch the qemu console core stops using PixelFormat and pixman +format codes side-by-side, pixman format code is the primary way to +specify the DisplaySurface format: + + * DisplaySurface stops carrying a PixelFormat field. + * qemu_create_displaysurface_from() expects a pixman format now. + +Functions to convert PixelFormat to pixman_format_code_t (and back) +exist for those who still use PixelFormat. As PixelFormat allows +easy access to masks and shifts it will probably continue to exist. + +[ xenfb added by Benjamin Herrenschmidt ] + +Signed-off-by: Gerd Hoffmann <email address hidden> + +A build from the current master attached in gdb reveals + +Program received signal SIGSEGV, Segmentation fault. +sdl_switch (dcl=0x7f4db26e4b20, new_surface=new_surface@entry=0x0) at ui/sdl.c:128 +128 PixelFormat pf = qemu_pixelformat_from_pixman(new_surface->format); +(gdb) bt +#0 sdl_switch (dcl=0x7f4db26e4b20, new_surface=new_surface@entry=0x0) at ui/sdl.c:128 +#1 0x00007f4dafdff9c4 in handle_keydown (ev=0x7fff1598ef60) at ui/sdl.c:552 +#2 sdl_refresh (dcl=0x7f4db26e4b20) at ui/sdl.c:799 +#3 0x00007f4dafdf33b2 in dpy_refresh (s=0x7f4db2792b40) at ui/console.c:1473 +#4 gui_update (opaque=0x7f4db2792b40) at ui/console.c:196 +#5 0x00007f4dafe30179 in timerlist_run_timers (timer_list=0x7f4db1dd4900) at qemu-timer.c:502 +#6 0x00007f4dafe30414 in qemu_clock_run_timers (type=<optimized out>) at qemu-timer.c:513 +#7 qemu_clock_run_all_timers () at qemu-timer.c:621 +#8 0x00007f4dafe2ebac in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:500 +#9 0x00007f4dafb8fe66 in main_loop () at vl.c:1794 +#10 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4353 +(gdb) p new_surface +$1 = (DisplaySurface *) 0x0 + + + +Actually in any version this can never work, as you call + + sdl_switch(dcl,NULL); + +in ui/sdl.c:552. So the dereferncing statement + + new_surface->format + +must SEGFAULT. + +The obvious patch is very simple, of course, as just the statement below line 128 asks if(new_surface). So pf should be initialized after this check: + +diff --git a/ui/sdl.c b/ui/sdl.c +index 138ca73..c4fa1f6 100644 +--- a/ui/sdl.c ++++ b/ui/sdl.c +@@ -125,12 +125,13 @@ static void do_sdl_resize(int width, int height, int bpp) + static void sdl_switch(DisplayChangeListener *dcl, + DisplaySurface *new_surface) + { +- PixelFormat pf = qemu_pixelformat_from_pixman(new_surface->format); ++ PixelFormat pf; + + /* temporary hack: allows to call sdl_switch to handle scaling changes */ + if (new_surface) { + surface = new_surface; + } ++ pf = qemu_pixelformat_from_pixman(surface->format); + + if (!scaling_active) { + do_sdl_resize(surface_width(surface), surface_height(surface), 0); + + + +Ingo Krabbe's suggested change fixes the issue for me. + diff --git a/results/classifier/118/unknown/1418 b/results/classifier/118/unknown/1418 new file mode 100644 index 00000000..27c9128d --- /dev/null +++ b/results/classifier/118/unknown/1418 @@ -0,0 +1,117 @@ +mistranslation: 0.878 +peripherals: 0.854 +permissions: 0.852 +user-level: 0.838 +assembly: 0.832 +device: 0.831 +risc-v: 0.831 +architecture: 0.824 +register: 0.822 +hypervisor: 0.817 +semantic: 0.810 +debug: 0.805 +PID: 0.802 +vnc: 0.797 +performance: 0.792 +arm: 0.788 +graphic: 0.781 +socket: 0.770 +files: 0.762 +TCG: 0.758 +network: 0.758 +virtual: 0.749 +VMM: 0.744 +KVM: 0.739 +ppc: 0.735 +kernel: 0.724 +boot: 0.702 +i386: 0.699 +x86: 0.698 + +Underflow in xlnx_dp_aux_pop_tx_fifo() +Description of problem: +Pop from s->tx_fifo but s->tx_fifo has zero element. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xfd4a0100 0x19c4406f +EOF +``` +Additional information: +``` ++ DEFAULT_INPUT_MAXSIZE=10000000 ++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 ./crash-c15714102f0b894dea5c22f38852311567380926.minimized +==14660==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x55db5cf9b840). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 1977030529 +INFO: Loaded 1 modules (618603 inline 8-bit counters): 618603 [0x55db600fa000, 0x55db6019106b), +INFO: Loaded 1 PC tables (618603 PCs): 618603 [0x55db5f788d60,0x55db600f9410), +./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio* +This process will fuzz the following MemoryRegions: + * xlnx.v-dp.core[0] (size 3b0) + * xlnx.v-dp.v_blend[0] (size 1e0) + * xlnx.v-dp.audio[0] (size 50) + * xlnx.v-dp.av_buffer_manager[0] (size 238) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 488Mb +Running: ./crash-c15714102f0b894dea5c22f38852311567380926.minimized +aarch64: xlnx_dp_aux_pop_tx_fifo: TX_FIFO underflow +==14660== ERROR: libFuzzer: deadly signal + #0 0x55db5837410e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x55db582c2d81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x55db5829bcb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x55db5829bd82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x55db5829bd82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f98a612541f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f98a5f3700a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f98a5f3700a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f98a5f16858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x55db583a465a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12 + #10 0x55db58cce4d8 in xlnx_dp_aux_pop_tx_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:476:9 + #11 0x55db58cc9ee7 in xlnx_dp_aux_set_command /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:524:22 + #12 0x55db58cc6a92 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/xlnx_dp.c:800:9 + #13 0x55db5bf4eec3 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5 + #14 0x55db5bf4e801 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #15 0x55db5bf4d126 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16 + #16 0x55db5bfdb2de in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23 + #17 0x55db5bfc941b in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12 + #18 0x55db5bfc8ed8 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18 + #19 0x55db583b40cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1088:5 + #20 0x55db583b2544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1229:28 + #21 0x55db5cf971ff in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #22 0x55db5cf8e57b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #23 0x55db5cf8e450 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #24 0x55db583bb10c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12 + #25 0x55db5cf9bae2 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #26 0x55db5829c826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #27 0x55db5827f454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #28 0x55db5828a3fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #29 0x55db582769e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #30 0x7f98a5f18082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #31 0x55db58276a3d in _start (/root/bugs/metadata/xlnx_dp-06/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3291a3d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x1,0x9,0x0,0x1,0x4a,0xfd,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x6f,0x40,0xc4,0x19,0x0,0x0,0x0,0x0, +\x01\x09\x00\x01J\xfd\x00\x00\x00\x00\x04\x00\x00\x00o@\xc4\x19\x00\x00\x00\x00 +``` diff --git a/results/classifier/118/unknown/1424 b/results/classifier/118/unknown/1424 new file mode 100644 index 00000000..6f4c867d --- /dev/null +++ b/results/classifier/118/unknown/1424 @@ -0,0 +1,133 @@ +mistranslation: 0.826 +user-level: 0.797 +hypervisor: 0.790 +VMM: 0.780 +debug: 0.778 +vnc: 0.753 +TCG: 0.749 +permissions: 0.746 +performance: 0.743 +KVM: 0.740 +peripherals: 0.729 +semantic: 0.729 +virtual: 0.728 +graphic: 0.724 +risc-v: 0.721 +network: 0.707 +register: 0.706 +PID: 0.704 +architecture: 0.704 +assembly: 0.695 +i386: 0.691 +device: 0.691 +x86: 0.683 +arm: 0.669 +socket: 0.669 +ppc: 0.657 +boot: 0.643 +kernel: 0.636 +files: 0.635 + +Overflow in xlnx_dp_aux_push_tx_fifo() +Description of problem: +Invoking xlnx_dp_aux_push_tx_fifo() 17 times overflow the s->tx_fifo. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-aarch64 + +cat << EOF | $QEMU \ +-machine xlnx-zcu102 -monitor none -serial none \ +-display none -nodefaults -qtest stdio +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x666e0fa2 +writel 0xfd4a0104 0x666e0fa2 +writel 0xfd4a0104 0x666e0fa2 +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x66554466 +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x6fed53ba +writel 0xfd4a0104 0x6fed53ba +EOF +``` +Additional information: +``` +root@621cbd136b6f:~/bugs/metadata/xlnx_dp-07# bash -x xlnx_dp-07.videzzo ++ DEFAULT_INPUT_MAXSIZE=10000000 ++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-8070de484ac8d4d9bfff9b439311058e05b8b40f.minimized +==47609==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x564c9e37c2b0). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 2128347645 +INFO: Loaded 1 modules (600768 inline 8-bit counters): 600768 [0x564ca198f000, 0x564ca1a21ac0), +INFO: Loaded 1 PC tables (600768 PCs): 600768 [0x564ca1063b10,0x564ca198e710), +./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio* +This process will fuzz the following MemoryRegions: + * xlnx.v-dp.core[0] (size 3b0) + * xlnx.v-dp.v_blend[0] (size 1e0) + * xlnx.v-dp.audio[0] (size 50) + * xlnx.v-dp.av_buffer_manager[0] (size 238) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4 + * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 510Mb +Running: ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-8070de484ac8d4d9bfff9b439311058e05b8b40f.minimized +qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: ../util/fifo8.c:43: void fifo8_push_all(Fifo8 *, const uint8_t *, uint32_t): Assertion `fifo->num + num <= fifo->capacity' failed. +==47609== ERROR: libFuzzer: deadly signal + #0 0x564c998420fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x564c99790d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x564c99769ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x564c99769d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x564c99769d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7f8ef929941f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7f8ef90ab00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7f8ef90ab00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7f8ef908a858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x7f8ef908a728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3 + #10 0x7f8ef909bfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3 + #11 0x564c9e1cdbb3 in fifo8_push_all /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:43:5 + #12 0x564c9a189c13 in xlnx_dp_aux_push_tx_fifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/xlnx_dp.c:467:5 + #13 0x564c9a1842f2 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/xlnx_dp.c:857:9 + #14 0x564c9d491e93 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5 + #15 0x564c9d4917d1 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18 + #16 0x564c9d4900f6 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16 + #17 0x564c9d5209ce in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23 + #18 0x564c9d50e77b in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12 + #19 0x564c9d50e238 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18 + #20 0x564c99882d48 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5 + #21 0x564c998810b3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28 + #22 0x564c9e37772f in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5 + #23 0x564c9e36eaad in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9 + #24 0x564c9e36e854 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9 + #25 0x564c9988a08c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12 + #26 0x564c9e37c57b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18 + #27 0x564c9976a816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #28 0x564c9974d444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x564c997583ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #30 0x564c997449d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7f8ef908c082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x564c99744a2d in _start (/root/bugs/metadata/xlnx_dp-07/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3453a2d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/118/unknown/1428657 b/results/classifier/118/unknown/1428657 new file mode 100644 index 00000000..7b616084 --- /dev/null +++ b/results/classifier/118/unknown/1428657 @@ -0,0 +1,191 @@ +ppc: 0.885 +permissions: 0.869 +performance: 0.855 +graphic: 0.851 +user-level: 0.849 +peripherals: 0.849 +arm: 0.845 +architecture: 0.843 +debug: 0.842 +risc-v: 0.836 +TCG: 0.828 +device: 0.819 +vnc: 0.817 +i386: 0.809 +x86: 0.809 +semantic: 0.803 +register: 0.801 +virtual: 0.799 +kernel: 0.798 +PID: 0.783 +assembly: 0.782 +VMM: 0.768 +files: 0.762 +hypervisor: 0.758 +socket: 0.747 +mistranslation: 0.739 +KVM: 0.725 +boot: 0.694 +network: 0.694 + +qemu-system-arm does not ignore the lowest bit of pc when returning from interrrupt + +This was observed in qemu v2.1.3, running a sample app from + +FreeRTOS(FreeRTOSV7.5.2/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo) + +In the sample code compiled with arm-none-eabi-gcc , version 4.8.2 (4.8.2-14ubuntu1+6) . + +qemu seems to be executing the wrong instrunction after returning from the SVCHandler. The svc handler changes the PSP register and the new stack contains an add return address, which should be allowed(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html). The lowest bit of the address should be ignored, but it seems that qemu executes garbage after returning from the interrupt. + +qemu is run like this: + +qemu-system-arm -semihosting -machine lm3s6965evb -kernel RTOSDemo.axf -gdb tcp::1234 -S + + +this is the arm-gdb trace +Program received signal SIGINT, Interrupt. +IntDefaultHandler () at startup.c:231 +231 { +(gdb) bt +#0 IntDefaultHandler () at startup.c:231 +#1 0xfffffffc in ?? () + +(gdb) info registers +r0 0x0 0 +r1 0x14b4b4b4 347387060 +r2 0xa5a5a5a5 -1515870811 +r3 0xa5a5a53d -1515870915 +r4 0xa5a5a5a5 -1515870811 +r5 0xa5a5a5a5 -1515870811 +r6 0xa5a5a5a5 -1515870811 +r7 0x40d00542 1087374658 +r8 0xa5a5a5a5 -1515870811 +r9 0xa5a5a5a5 -1515870811 +r10 0xa5a5a5a5 -1515870811 +r11 0xa5a5a5a5 -1515870811 +r12 0xa5a5a5a5 -1515870811 +sp 0x20008380 0x20008380 +lr 0xfffffffd -3 +pc 0xc648 0xc648 <IntDefaultHandler> +cpsr 0x20000173 536871283 + +this exception occur after running SVC handler code + +(gdb) disassemble vPortSVCHandler +Dump of assembler code for function vPortSVCHandler: + 0x0000c24c <+0>: ldr r3, [pc, #24] ; (0xc268 <vPortSVCHandler+28>) + 0x0000c24e <+2>: ldr r1, [r3, #0] + 0x0000c250 <+4>: ldr r0, [r1, #0] + 0x0000c252 <+6>: ldmia.w r0!, {r4, r5, r6, r7, r8, r9, r10, r11} + 0x0000c256 <+10>: msr PSP, r0 + 0x0000c25a <+14>: mov.w r0, #0 + 0x0000c25e <+18>: msr BASEPRI, r0 + 0x0000c262 <+22>: orr.w lr, lr, #13 + 0x0000c266 <+26>: bx lr + 0x0000c268 <+28>: andcs r2, r0, r12, ror #5 +End of assembler dump. + +This stores this stack in PSP register: +(gdb) x /32 0x200052c8 +0x200052c8: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 +0x200052d8: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 +0x200052e8: 0x00000000 0x14b4b4b4 0xa5a5a5a5 0xa5a5a53d +0x200052f8: 0xa5a5a5a5 0x00000000 0x00003b49 0x21000000 +0x20005308: 0xa5a5a5a5 0xa5a5a5a5 0x200081b8 0x00000058 +0x20005318: 0x00000000 0x00000000 0x00000000 0x00000000 +0x20005328: 0x00000000 0x20005330 0xffffffff 0x20005330 +0x20005338: 0x20005330 0x00000000 0x20005344 0xffffffff + +It seems that qemu actually executes 0x00003b49 after the interrupt, but it should execute 0x00003b48 + + + +On 5 March 2015 at 23:15, Anders Esbensen <email address hidden> wrote: +> Public bug reported: +> +> This was observed in qemu v2.1.3, running a sample app from +> +> FreeRTOS(FreeRTOSV7.5.2/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo) +> +> In the sample code compiled with arm-none-eabi-gcc , version 4.8.2 +> (4.8.2-14ubuntu1+6) . +> +> qemu seems to be executing the wrong instrunction after returning from +> the SVCHandler. The svc handler changes the PSP register and the new +> stack contains an add return address, which should be +> allowed(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html). +> The lowest bit of the address should be ignored, but it seems that qemu +> executes garbage after returning from the interrupt. + +So if I understand you correctly, the guest is executing +a return-from-exception (via a bx lr instruction where the +return address is one of the 0xffffffXX special cases), and +the PC value in the exception frame we're restoring has +its least significant bit set? + +If so, then this is a guest bug. In an exception frame the +PC must be halfword aligned (ie must have the ls bit clear), +because the "is this Thumb or not?" information is stored in +the PSR field in the exception frame. If the LSB of the PC +is set then the behaviour is UNPREDICTABLE (see the PopStack +pseudocode in the ARMv7M ARM ARM). Real hardware seems to +ignore the LSbit, but QEMU's behaviour is architecturally +permitted and you should really fix your guest code. + +(The ARM knowledgebase article you give a link to correctly +notes that the LSbit in vector table entries and normal +branch targets is significant, but says nothing about the +PC in exception frames.) + +thanks +-- PMM + + +Yes the situation I'm describing is the bx 0xfffffffx case. + +I see that the article I'm referring to, actually only describes the behaviour of branches and in ISR vector. + +Searching a bit more I see this: + +Cortex™-M3 Technical Reference Manual Revision: r1p1 +Home > Programmer’s Model > Registers > General-purpose registers +2.3.1. General-purpose registers + +-Program counter +Register r15 is the Program Counter (PC). +Bit [0] is always 0, so instructions are always aligned to word or halfword boundaries. + +Which is like you are describing. + +So I agree, I should correct my guest code, which I did :-), but shouldn't qemu reflect the behaviour of the implemented hardware? +So it is "unpredictable" in the same way? + +I'will note the FreeRTOS people they have a bad implementation of their SVC handler for Cortex M3 + +Thanks for the help. + +/Anders + + +Proposed patch: http://patchwork.ozlabs.org/patch/449400/ which could use testing. + + + +I've tested the patch against the FreeRTOS example. An the patch seems +to make the example run. +The FreeRTOS sample now crash for other reasons. But I consider the +issue resolved. + +/Anders + +On 03/12/2015 02:45 PM, Peter Maydell wrote: +> Proposed patch: http://patchwork.ozlabs.org/patch/449400/ which could +> use testing. +> + + + +The patch described in an earlier comment was applied to master and the fix was in QEMU 2.4. + + diff --git a/results/classifier/118/unknown/1433 b/results/classifier/118/unknown/1433 new file mode 100644 index 00000000..fa42f31d --- /dev/null +++ b/results/classifier/118/unknown/1433 @@ -0,0 +1,187 @@ +mistranslation: 0.888 +user-level: 0.886 +ppc: 0.878 +risc-v: 0.878 +x86: 0.826 +i386: 0.812 +graphic: 0.811 +TCG: 0.810 +register: 0.806 +vnc: 0.806 +semantic: 0.799 +debug: 0.793 +permissions: 0.783 +performance: 0.782 +kernel: 0.782 +architecture: 0.777 +PID: 0.774 +assembly: 0.774 +arm: 0.774 +socket: 0.774 +device: 0.767 +boot: 0.763 +files: 0.749 +virtual: 0.740 +KVM: 0.737 +VMM: 0.733 +peripherals: 0.727 +network: 0.711 +hypervisor: 0.694 + +Abort in lan9118_16bit_mode_[read|write]() +Description of problem: +[read|write][w|l] are allowed but [read|write]b are not allowed when mode_16bit is enabled. +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine smdkc210 -monitor none -serial none \ +-display none -qtest stdio +readb 0x5000070 +EOF +``` +Additional information: +``` +==1940==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x5654b8eede90). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 3248453476 +INFO: Loaded 1 modules (601357 inline 8-bit counters): 601357 [0x5654bbdd8000, 0x5654bbe6ad0d), +INFO: Loaded 1 PC tables (601357 PCs): 601357 [0x5654bb4aa340,0x5654bbdd7410), +./qemu-videzzo-arm-target-videzzo-fuzz-lan9118: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes +Matching objects by name , *lan9118-mmio* +This process will fuzz the following MemoryRegions: + * lan9118-mmio[0] (size 100) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * lan9118-mmio, EVENT_TYPE_MMIO_READ, 0x5000000 +0x100, 1,4 + * lan9118-mmio, EVENT_TYPE_MMIO_WRITE, 0x5000000 +0x100, 1,4 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 221Mb +Running: ./crash-663e5408ee573b1e9d073c796ffbaaae9bd583cb +qemu: hardware error: lan9118_read: Bad size 0x1 + +CPU #0: +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +CPU #1: +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00000000 +PSR=400001d3 -Z-- A svc32 +s00=00000000 s01=00000000 d00=0000000000000000 +s02=00000000 s03=00000000 d01=0000000000000000 +s04=00000000 s05=00000000 d02=0000000000000000 +s06=00000000 s07=00000000 d03=0000000000000000 +s08=00000000 s09=00000000 d04=0000000000000000 +s10=00000000 s11=00000000 d05=0000000000000000 +s12=00000000 s13=00000000 d06=0000000000000000 +s14=00000000 s15=00000000 d07=0000000000000000 +s16=00000000 s17=00000000 d08=0000000000000000 +s18=00000000 s19=00000000 d09=0000000000000000 +s20=00000000 s21=00000000 d10=0000000000000000 +s22=00000000 s23=00000000 d11=0000000000000000 +s24=00000000 s25=00000000 d12=0000000000000000 +s26=00000000 s27=00000000 d13=0000000000000000 +s28=00000000 s29=00000000 d14=0000000000000000 +s30=00000000 s31=00000000 d15=0000000000000000 +s32=00000000 s33=00000000 d16=0000000000000000 +s34=00000000 s35=00000000 d17=0000000000000000 +s36=00000000 s37=00000000 d18=0000000000000000 +s38=00000000 s39=00000000 d19=0000000000000000 +s40=00000000 s41=00000000 d20=0000000000000000 +s42=00000000 s43=00000000 d21=0000000000000000 +s44=00000000 s45=00000000 d22=0000000000000000 +s46=00000000 s47=00000000 d23=0000000000000000 +s48=00000000 s49=00000000 d24=0000000000000000 +s50=00000000 s51=00000000 d25=0000000000000000 +s52=00000000 s53=00000000 d26=0000000000000000 +s54=00000000 s55=00000000 d27=0000000000000000 +s56=00000000 s57=00000000 d28=0000000000000000 +s58=00000000 s59=00000000 d29=0000000000000000 +s60=00000000 s61=00000000 d30=0000000000000000 +s62=00000000 s63=00000000 d31=0000000000000000 +FPSCR: 00000000 +==1940== ERROR: libFuzzer: deadly signal + #0 0x5654b48090fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 + #1 0x5654b4757d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38 + #2 0x5654b4730ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18 + #3 0x5654b4730d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1 + #4 0x5654b4730d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19 + #5 0x7fb6db17941f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) + #6 0x7fb6daf8b00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 + #7 0x7fb6daf8b00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #8 0x7fb6daf6a858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7 + #9 0x5654b483964a in __wrap_abort /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/less_crashes_wrappers.c:24:12 + #10 0x5654b6a64d84 in hw_error /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/cpus.c:128:5 + #11 0x5654b5ac50c7 in lan9118_16bit_mode_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/lan9118.c:1319:5 + #12 0x5654b7ee045b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:440:11 + #13 0x5654b7ea0761 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #14 0x5654b7e9db2c in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1424:16 + #15 0x5654b7e9d268 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1457:9 + #16 0x5654b7f1946d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2892:23 + #17 0x5654b7f1aa78 in flatview_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2934:12 + #18 0x5654b7f1a538 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2947:18 + #19 0x5654b483a7ea in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2869:18 + #20 0x5654b483a7ea in qemu_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1010:5 + #21 0x5654b483997e in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1034:35 + #22 0x5654b8ee984f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #23 0x5654b8ee0bcb in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #24 0x5654b8ee0aa0 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #25 0x5654b48500fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1497:12 + #26 0x5654b8eee132 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #27 0x5654b4731816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #28 0x5654b4714444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #29 0x5654b471f3ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #30 0x5654b470b9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #31 0x7fb6daf6c082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #32 0x5654b470ba2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-lan9118+0x300da2d) + +NOTE: libFuzzer has rudimentary signal handlers. + Combine libFuzzer with AddressSanitizer or similar for better crash reports. +SUMMARY: libFuzzer: deadly signal +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +0x4,0x2,0x29,0x92,0xa,0x0,0x0,0x0,0x0,0x0,0x0,0x8,0x70,0x0,0x0,0x5,0x0,0x0,0x0,0x0,0x1,0x0,0x0,0x0,0x1,0x9,0x48,0x0,0x0,0x5,0x0,0x0,0x0,0x0,0x4,0x0,0x0,0x0,0x29,0x1f,0x8e,0x23,0x0,0x0,0x0,0x0, +\x04\x02)\x92\x0a\x00\x00\x00\x00\x00\x00\x08p\x00\x00\x05\x00\x00\x00\x00\x01\x00\x00\x00\x01\x09H\x00\x00\x05\x00\x00\x00\x00\x04\x00\x00\x00)\x1f\x8e#\x00\x00\x00\x00 +``` diff --git a/results/classifier/118/unknown/1452230 b/results/classifier/118/unknown/1452230 new file mode 100644 index 00000000..7358dbd2 --- /dev/null +++ b/results/classifier/118/unknown/1452230 @@ -0,0 +1,53 @@ +peripherals: 0.902 +permissions: 0.893 +socket: 0.853 +debug: 0.851 +architecture: 0.847 +hypervisor: 0.847 +graphic: 0.840 +mistranslation: 0.839 +semantic: 0.832 +virtual: 0.830 +files: 0.827 +user-level: 0.825 +device: 0.824 +performance: 0.818 +network: 0.818 +PID: 0.817 +assembly: 0.816 +vnc: 0.814 +risc-v: 0.796 +VMM: 0.795 +register: 0.789 +i386: 0.785 +arm: 0.784 +TCG: 0.782 +x86: 0.779 +ppc: 0.769 +kernel: 0.761 +KVM: 0.755 +boot: 0.718 + +Qemu 2.3.0 failes to compile with GCC 5.1.0 and -flto + +Compiling Qemu 2.3.0 failes with the following error: + +x86_64-pc-linux-gnu-g++ -I/usr/include/pixman-1 -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/libpng16 -I/usr/include/libusb-1.0 -I/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/work/qemu-2.3.0/tests -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin -Wl,-z,relro -Wl,-z,now -pie -m64 -Wl,-O1 -Wl,--as-needed -march=native -O2 -pipe -ggdb -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -fira-loop-pressure -ftree-vectorize -ftree-loop-linear -flto=5 -fuse-linker-plugin -Wl,-znow -Wl,--sort-common -Wl,--hash-style=gnu -Wl,--enable-new-dtags -o qemu-img qemu-img.o async.o thread-pool.o nbd.o block.o blockjob.o main-loop.o iohandler.o qemu-timer.o aio-posix.o qemu-io-cmds.o qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o qemu-coroutine-sleep.o coroutine-ucontext.o block/raw_bsd.o block/qcow.o block/vdi.o block/vmdk.o block/cloop.o block/dmg.o block/bochs.o block/vpc.o block/vvfat.o block/qcow2.o block/qcow2-refcount.o block/qcow2-cluster.o block/qcow2-snapshot.o block/qcow2-cache.o block/qed.o block/qed-gencb.o block/qed-l2-cache.o block/qed-table.o block/qed-cluster.o block/qed-check.o block/vhdx.o block/vhdx-endian.o block/vhdx-log.o block/parallels.o block/blkdebug.o block/blkverify.o block/block-backend.o block/snapshot.o block/qapi.o block/raw-posix.o block/linux-aio.o block/null.o block/mirror.o block/nbd.o block/nbd-client.o block/sheepdog.o block/accounting.o block/write-threshold.o block/curl.o libqemuutil.a libqemustub.a -lz -lbz2 -laio -lcurl -lm -lgthread-2.0 -pthread -lglib-2.0 -lz -lrt -lz -lcap-ng -luuid -lutil +lto1: error: two or more sections for .gnu.lto_fprintf.2f4a95b725db6827 +(null):0: confused by earlier errors, bailing out +make[1]: *** [/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/temp/ccEUT6Vq.ltrans11.ltrans.o] Error 1 +make[1]: *** Waiting for unfinished jobs.... +lto-wrapper: fatal error: make returned 2 exit status +compilation terminated. +/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed +collect2: error: ld returned 1 exit status +/home/gentoo/tmp/portage/app-emulation/qemu-2.3.0/work/qemu-2.3.0/rules.mak:122: recipe for target 'qemu-img' failed +make: *** [qemu-img] Error 1 + +I've found an old GCC bugreport with the same error: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52159 (which has been marked as dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59000) . I was able to reduce the object list to to three .o files which reproduce the error reliably: qemu-img.o qemu-io-cmds.o block/qapi.o. + +Please let me know if you need further information. + +This seems to be a GCC bug, not a QEMU bug? I'm going to close this bug, since it has been reported upstream with the GCC folks, and they don't seem to think this is an error on our side. + + diff --git a/results/classifier/118/unknown/1467240 b/results/classifier/118/unknown/1467240 new file mode 100644 index 00000000..3197be34 --- /dev/null +++ b/results/classifier/118/unknown/1467240 @@ -0,0 +1,216 @@ +risc-v: 0.892 +device: 0.885 +debug: 0.878 +register: 0.878 +virtual: 0.872 +PID: 0.863 +arm: 0.863 +graphic: 0.861 +semantic: 0.855 +performance: 0.855 +permissions: 0.852 +vnc: 0.852 +user-level: 0.852 +ppc: 0.851 +assembly: 0.846 +hypervisor: 0.843 +TCG: 0.841 +x86: 0.840 +peripherals: 0.839 +socket: 0.837 +kernel: 0.831 +architecture: 0.828 +VMM: 0.825 +KVM: 0.824 +network: 0.810 +files: 0.801 +boot: 0.799 +mistranslation: 0.793 +i386: 0.789 + +Regression - bridged networking broken for Mac OS X guest + +Using the instructions at http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ for running Mac OS X Snow Leopard under QEMU, bridged networking is broken when using QEMU git. The result is that Mac OS X is unable to obtain an IP address using DHCP. It works in the latest stable release - QEMU 2.3.0. + +Replace "-netdev user,id=hub0port0" with "-netdev bridge,br=br0,id=hub0port0" when testing bridged networking. + +Bisecting the git repository shows the following bad commit: +commit a90a7425cf592a3afeff3eaf32f543b83050ee5c +Author: Fam Zheng <email address hidden> +Date: Thu Jun 4 14:45:17 2015 +0800 + + tap: Drop tap_can_send + + This callback is called by main loop before polling s->fd, if it returns + false, the fd will not be polled in this iteration. + + This is redundant with checks inside read callback. After this patch, + the data will be sent to peer when it arrives. If the device can't + receive, it will be queued to incoming_queue, and when the device status + changes, this queue will be flushed. + + Signed-off-by: Fam Zheng <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Stefan Hajnoczi <email address hidden> + +On Sun, Jun 21, 2015 at 11:26:08AM -0000, Jonathan Liu wrote: +> Using the instructions at +> http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/ for running Mac OS X +> Snow Leopard under QEMU, bridged networking is broken when using QEMU +> git. The result is that Mac OS X is unable to obtain an IP address using +> DHCP. It works in the latest stable release - QEMU 2.3.0. +> +> Replace "-netdev user,id=hub0port0" with "-netdev +> bridge,br=br0,id=hub0port0" when testing bridged networking. +> +> Bisecting the git repository shows the following bad commit: +> commit a90a7425cf592a3afeff3eaf32f543b83050ee5c +> Author: Fam Zheng <email address hidden> +> Date: Thu Jun 4 14:45:17 2015 +0800 +> +> tap: Drop tap_can_send + +Please confirm that you are using -device e1000-82545em. + +Please try the following patch to gather debug output: + +diff --git a/hw/net/e1000.c b/hw/net/e1000.c +index bab8e2a..2f68c6d 100644 +--- a/hw/net/e1000.c ++++ b/hw/net/e1000.c +@@ -174,6 +174,7 @@ enum { + static void + e1000_link_down(E1000State *s) + { ++ fprintf(stderr, "%s link down\n", __func__); + s->mac_reg[STATUS] &= ~E1000_STATUS_LU; + s->phy_reg[PHY_STATUS] &= ~MII_SR_LINK_STATUS; + s->phy_reg[PHY_STATUS] &= ~MII_SR_AUTONEG_COMPLETE; +@@ -183,6 +184,7 @@ e1000_link_down(E1000State *s) + static void + e1000_link_up(E1000State *s) + { ++ fprintf(stderr, "%s link up\n", __func__); + s->mac_reg[STATUS] |= E1000_STATUS_LU; + s->phy_reg[PHY_STATUS] |= MII_SR_LINK_STATUS; + } +@@ -923,6 +925,12 @@ e1000_can_receive(NetClientState *nc) + { + E1000State *s = qemu_get_nic_opaque(nc); + ++ fprintf(stderr, "%s lu %d rctl_en %d pci_master %d has_rxbufs %d\n", ++ __func__, s->mac_reg[STATUS] & E1000_STATUS_LU, ++ s->mac_reg[RCTL] & E1000_RCTL_EN, ++ s->parent_obj.config[PCI_COMMAND] & PCI_COMMAND_MASTER, ++ e1000_has_rxbufs(s, 1)); ++ + return (s->mac_reg[STATUS] & E1000_STATUS_LU) && + (s->mac_reg[RCTL] & E1000_RCTL_EN) && + (s->parent_obj.config[PCI_COMMAND] & PCI_COMMAND_MASTER) && +diff --git a/net/tap.c b/net/tap.c +index bd01590..07676ce 100644 +--- a/net/tap.c ++++ b/net/tap.c +@@ -67,6 +67,8 @@ static void tap_writable(void *opaque); + + static void tap_update_fd_handler(TAPState *s) + { ++ fprintf(stderr, "%s read_poll %d write_poll %d enabled %d\n", ++ __func__, s->read_poll, s->write_poll, s->enabled); + qemu_set_fd_handler(s->fd, + s->read_poll && s->enabled ? tap_send : NULL, + s->write_poll && s->enabled ? tap_writable : NULL, + + +Yes, -device e1000-82545em is being used. + +Here is the debug output with the patch applied against QEMU git ad7020a7e7b27d468ecc2aacb04ba4eb09017074 after booting to desktop and waiting for DHCP to fallback to automatic private IP address: +tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +e1000_can_receive lu 2 rctl_en 0 pci_master 0 has_rxbufs 0 +tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +e1000_can_receive lu 2 rctl_en 0 pci_master 4 has_rxbufs 0 +tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +e1000_can_receive lu 2 rctl_en 0 pci_master 4 has_rxbufs 0 +tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +e1000_link_down link down +tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +e1000_can_receive lu 0 rctl_en 0 pci_master 4 has_rxbufs 0 +tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +e1000_can_receive lu 0 rctl_en 0 pci_master 4 has_rxbufs 1 +tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +e1000_can_receive lu 0 rctl_en 2 pci_master 4 has_rxbufs 1 +tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +e1000_link_up link up + + +On another note, it seems the DHCP server is receiving DHCPDISCOVER message and sending back DHCPOFFER response while the guest is trying to obtain an IP address but it seems the guest doesn't see the DHCPOFFER response because it sends more DHCPDISCOVER messages with a delay of some seconds in between. + +On Mon, Jun 22, 2015 at 10:49:29AM -0000, Jonathan Liu wrote: +> Yes, -device e1000-82545em is being used. +> +> Here is the debug output with the patch applied against QEMU git ad7020a7e7b27d468ecc2aacb04ba4eb09017074 after booting to desktop and waiting for DHCP to fallback to automatic private IP address: +> tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +> e1000_can_receive lu 2 rctl_en 0 pci_master 0 has_rxbufs 0 + +The NIC is not ready to receive so incoming packets are queued... + +> tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +> tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +> e1000_can_receive lu 2 rctl_en 0 pci_master 4 has_rxbufs 0 +> tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +> tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +> e1000_can_receive lu 2 rctl_en 0 pci_master 4 has_rxbufs 0 +> tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +> e1000_link_down link down +> tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +> e1000_can_receive lu 0 rctl_en 0 pci_master 4 has_rxbufs 0 +> tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +> tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +> e1000_can_receive lu 0 rctl_en 0 pci_master 4 has_rxbufs 1 +> tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +> tap_update_fd_handler read_poll 1 write_poll 0 enabled 1 +> e1000_can_receive lu 0 rctl_en 2 pci_master 4 has_rxbufs 1 + +Now the NIC is ready to receive packets but the link is still down. +Packets remain queued. + +> tap_update_fd_handler read_poll 0 write_poll 0 enabled 1 +> e1000_link_up link up + +We should flush queued packets now that the link has come back up. + +Please try this patch: + +diff --git a/hw/net/e1000.c b/hw/net/e1000.c +index bab8e2a..ea58373 100644 +--- a/hw/net/e1000.c ++++ b/hw/net/e1000.c +@@ -185,6 +185,7 @@ e1000_link_up(E1000State *s) + { + s->mac_reg[STATUS] |= E1000_STATUS_LU; + s->phy_reg[PHY_STATUS] |= MII_SR_LINK_STATUS; ++ qemu_flush_queued_packets(qemu_get_queue(s->nic)); + } + + static bool + + +The patch seems to resolve the issue. The guest is able to obtain an IP address and communicate with the network. + +Is there anything else you would like me to test? + +On Thu, Jun 25, 2015 at 2:10 AM, Jonathan Liu <email address hidden> wrote: +> Is there anything else you would like me to test? + +Thanks, I will submit a final patch and CC you so you can test it. + +Stefan + + +Patch had been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5df6a1855b62dc6535 + diff --git a/results/classifier/118/unknown/1488363 b/results/classifier/118/unknown/1488363 new file mode 100644 index 00000000..8f835fa7 --- /dev/null +++ b/results/classifier/118/unknown/1488363 @@ -0,0 +1,289 @@ +register: 0.910 +user-level: 0.881 +device: 0.870 +virtual: 0.858 +risc-v: 0.854 +KVM: 0.847 +x86: 0.845 +peripherals: 0.843 +hypervisor: 0.843 +ppc: 0.834 +permissions: 0.828 +assembly: 0.826 +architecture: 0.824 +VMM: 0.822 +arm: 0.814 +graphic: 0.797 +mistranslation: 0.788 +boot: 0.786 +vnc: 0.772 +socket: 0.766 +performance: 0.761 +debug: 0.758 +semantic: 0.757 +files: 0.752 +PID: 0.749 +kernel: 0.747 +i386: 0.747 +network: 0.745 +TCG: 0.724 + +qemu 2.4.0 hangs using vfio for pci passthrough of graphics card + +2.3.0 (manjaro distro package) works fine. 2.4.0 (manjaro or the arch vanilla one) hangs on the SeaBIOS screen when saying "Press F12 for boot menu". All tested with the same hardware, OS, command and configuration. It also starts without the GPU passed through, even with the USB passed through. I am using the latest SeaBIOS 1.8.2. + +The release notes say: + VFIO + Support for resetting AMD Bonaire and Hawaii GPUs + Platform device passthrough support for Calxeda xgmac devices + +So maybe something there broke it. + +I am using the arch qemu 2.4.0 PKGBUILD (modified to have make -j8 and removed iscsi, gluster, ceph, etc.), which uses vanilla sources and no patches. https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/qemu + +I am not using a frontend. I am using a script I wrote that generates the command below. + +Guest OS here would be 64 bit windows 7, but it didn't start so that's not relevant. Also a Manjaro Linux VM won't start. + +CPU is AMD FX-8150; board is Gigabyte GA-990FXA-UD5 (990FX chipset). + +full command line (without the \ after each line) is: + +qemu-system-x86_64 + -enable-kvm + -M q35 + -m 3584 + -cpu host + -boot c + -smp 7,sockets=1,cores=7,threads=1 + -vga none + -device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 + -device vfio-pci,host=04:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=Sapphire.R7260X.1024.131106.rom + -device vfio-pci,host=00:14.2,bus=pcie.0 + -device vfio-pci,host=00:16.0,bus=root.1 + -device vfio-pci,host=00:16.2,bus=root.1 + -usb + -device ahci,bus=pcie.0,id=ahci + -drive file=/dev/data/vm1,id=disk1,format=raw,if=virtio,index=0,media=disk,discard=on + -drive media=cdrom,id=cdrom,index=5,media=cdrom + -netdev type=tap,id=net0,ifname=tap-vm1 + -device virtio-net-pci,netdev=net0,mac=00:01:02:03:04:05 + -monitor stdio + -boot menu=on + + +$ lspci -nn | grep -E "04:00.0|00:14.2|00:16.0|00:16.2" +00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) +00:16.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] +00:16.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] +04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X] [1002:6658] + + +Also I have this one that also hangs: +05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 6770] [1002:68ba] + +I ran a bisect, and here's the result: + + +b8eb5512fd8a115f164edbbe897cdf8884920ccb is the first bad commit +commit b8eb5512fd8a115f164edbbe897cdf8884920ccb +Author: Nadav Amit <email address hidden> +Date: Mon Apr 13 02:32:08 2015 +0300 + + target-i386: disable LINT0 after reset + + Due to old Seabios bug, QEMU reenable LINT0 after reset. This bug is long gone + and therefore this hack is no longer needed. Since it violates the + specifications, it is removed. + + Signed-off-by: Nadav Amit <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Paolo Bonzini <email address hidden> + +:040000 040000 a8ec76841b8d4e837c2cd0d0b82e08c0717a0ec6 d33744231c98c9f588cefbc92f416183f639706f M hw + + +$ git diff 7398dfc7799a50097803db4796c7edb6cd7d47a1 b8eb5512fd8a115f164edbbe897cdf8884920ccb + +diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c +index 042e960..d38d24b 100644 +--- a/hw/intc/apic_common.c ++++ b/hw/intc/apic_common.c +@@ -243,15 +243,6 @@ static void apic_reset_common(DeviceState *dev) + info->vapic_base_update(s); + + apic_init_reset(dev); +- +- if (bsp) { +- /* +- * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization +- * time typically by BIOS, so PIC interrupt can be delivered to the +- * processor when local APIC is enabled. +- */ +- s->lvt[APIC_LVT_LINT0] = 0x700; +- } + } + + /* This function is only used for old state version 1 and 2 */ + + +And then to confirm it: + +git checkout v2.4.0 +git revert b8eb5512fd8a115f164edbbe897cdf8884920ccb + + + +And this build works. :) + +Hi, + +proxmox users report same bug here with qemu 2.4: + +http://forum.proxmox.com/threads/23346-Proxmox-4b1-q35-machines-failing-to-reboot-problems-with-PCI-passthrough + +we are going to test with reverting the commit to see if it's help. + + +----- Mail original ----- +De: "Peter Maloney" <email address hidden> +À: "qemu-devel" <email address hidden> +Envoyé: Mercredi 26 Août 2015 21:48:16 +Objet: [Qemu-devel] [Bug 1488363] Re: qemu 2.4.0 hangs using vfio for pci passthrough of graphics card + +I ran a bisect, and here's the result: + + +b8eb5512fd8a115f164edbbe897cdf8884920ccb is the first bad commit +commit b8eb5512fd8a115f164edbbe897cdf8884920ccb +Author: Nadav Amit <email address hidden> +Date: Mon Apr 13 02:32:08 2015 +0300 + +target-i386: disable LINT0 after reset + +Due to old Seabios bug, QEMU reenable LINT0 after reset. This bug is long gone +and therefore this hack is no longer needed. Since it violates the +specifications, it is removed. + +Signed-off-by: Nadav Amit <email address hidden> +Message-Id: <email address hidden> +Signed-off-by: Paolo Bonzini <email address hidden> + +:040000 040000 a8ec76841b8d4e837c2cd0d0b82e08c0717a0ec6 +d33744231c98c9f588cefbc92f416183f639706f M hw + + +$ git diff 7398dfc7799a50097803db4796c7edb6cd7d47a1 b8eb5512fd8a115f164edbbe897cdf8884920ccb + +diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c +index 042e960..d38d24b 100644 +--- a/hw/intc/apic_common.c ++++ b/hw/intc/apic_common.c +@@ -243,15 +243,6 @@ static void apic_reset_common(DeviceState *dev) +info->vapic_base_update(s); + +apic_init_reset(dev); +- +- if (bsp) { +- /* +- * LINT0 delivery mode on CPU #0 is set to ExtInt at initialization +- * time typically by BIOS, so PIC interrupt can be delivered to the +- * processor when local APIC is enabled. +- */ +- s->lvt[APIC_LVT_LINT0] = 0x700; +- } +} + +/* This function is only used for old state version 1 and 2 */ + + +And then to confirm it: + +git checkout v2.4.0 +git revert b8eb5512fd8a115f164edbbe897cdf8884920ccb + + +And this build works. :) + +-- +You received this bug notification because you are a member of qemu- +devel-ml, which is subscribed to QEMU. +https://bugs.launchpad.net/bugs/1488363 + +Title: +qemu 2.4.0 hangs using vfio for pci passthrough of graphics card + +Status in QEMU: +New + +Bug description: +2.3.0 (manjaro distro package) works fine. 2.4.0 (manjaro or the arch +vanilla one) hangs on the SeaBIOS screen when saying "Press F12 for +boot menu". All tested with the same hardware, OS, command and +configuration. It also starts without the GPU passed through, even +with the USB passed through. I am using the latest SeaBIOS 1.8.2. + +The release notes say: +VFIO +Support for resetting AMD Bonaire and Hawaii GPUs +Platform device passthrough support for Calxeda xgmac devices + +So maybe something there broke it. + +I am using the arch qemu 2.4.0 PKGBUILD (modified to have make -j8 and removed iscsi, gluster, ceph, etc.), which uses vanilla sources and no patches. https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/qemu + +I am not using a frontend. I am using a script I wrote that generates +the command below. + +Guest OS here would be 64 bit windows 7, but it didn't start so that's +not relevant. Also a Manjaro Linux VM won't start. + +CPU is AMD FX-8150; board is Gigabyte GA-990FXA-UD5 (990FX chipset). + +full command line (without the \ after each line) is: + +qemu-system-x86_64 +-enable-kvm +-M q35 +-m 3584 +-cpu host +-boot c +-smp 7,sockets=1,cores=7,threads=1 +-vga none +-device ioh3420,bus=pcie.0,addr=1c.0,port=1,chassis=1,id=root.1 +-device vfio-pci,host=04:00.0,bus=root.1,multifunction=on,x-vga=on,addr=0.0,romfile=Sapphire.R7260X.1024.131106.rom +-device vfio-pci,host=00:14.2,bus=pcie.0 +-device vfio-pci,host=00:16.0,bus=root.1 +-device vfio-pci,host=00:16.2,bus=root.1 +-usb +-device ahci,bus=pcie.0,id=ahci +-drive file=/dev/data/vm1,id=disk1,format=raw,if=virtio,index=0,media=disk,discard=on +-drive media=cdrom,id=cdrom,index=5,media=cdrom +-netdev type=tap,id=net0,ifname=tap-vm1 +-device virtio-net-pci,netdev=net0,mac=00:01:02:03:04:05 +-monitor stdio +-boot menu=on + + +$ lspci -nn | grep -E "04:00.0|00:14.2|00:16.0|00:16.2" +00:14.2 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) +00:16.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] +00:16.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] +04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X] [1002:6658] + + +Also I have this one that also hangs: +05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Juniper XT [Radeon HD 6770] [1002:68ba] + +To manage notifications about this bug go to: +https://bugs.launchpad.net/qemu/+bug/1488363/+subscriptions + + +Version 2.4.1 is affected too, but regression mentioned by Peter Maloney solve this problem. + +This still affects the distro proxmox 4.0 and many users are affected "http://forum.proxmox.com/threads/24362-PCIe-passthrough-does-not-work" , is there any detail you guys need to fix this? + +With seabios 1.9.1-1 and qemu 2.5.0-1 manjaro packages (which as far as I know have no patches), it seems to work now. + +With U14.04_64 and qemu-2.5.0 complied from http://wiki.qemu.org/Download this is a problem unless I use linux-generic-lts-xenial (4.4.0.13.7) so it seems there's a kernel issue here + diff --git a/results/classifier/118/unknown/1488901 b/results/classifier/118/unknown/1488901 new file mode 100644 index 00000000..f9310f1e --- /dev/null +++ b/results/classifier/118/unknown/1488901 @@ -0,0 +1,197 @@ +permissions: 0.870 +device: 0.849 +graphic: 0.834 +architecture: 0.831 +performance: 0.829 +arm: 0.818 +files: 0.816 +assembly: 0.814 +debug: 0.808 +register: 0.804 +network: 0.798 +hypervisor: 0.795 +semantic: 0.795 +TCG: 0.794 +socket: 0.791 +user-level: 0.788 +mistranslation: 0.781 +kernel: 0.780 +virtual: 0.780 +peripherals: 0.773 +risc-v: 0.766 +PID: 0.759 +ppc: 0.741 +boot: 0.733 +VMM: 0.730 +KVM: 0.710 +x86: 0.699 +i386: 0.690 +vnc: 0.682 + +KVM guest crashes when doing a block commit command + +I scripted a simple backup procedure that works like this: + +1. Create snapshot + + virsh snapshot-create-as ${VM} "backup-${VM}" \ + --diskspec vda,file=${SNAP}/backup-snapshot-${VM}.qcow2 \ + --disk-only \ + --atomic \ + --quiesce \ + --no-metadata + +2. Copy disk image to different location + + cp -f --sparse=always /var/lib/libvirt/images/${VM}.img ${DST}/ + +3. Merge snapshot back to base image + + virsh blockcommit ${VM} vda --wait --active --verbose + virsh blockjob ${VM} ${SNAP}/backup-snapshot-${VM}.qcow2 --pivot + +4. Copy XML liver file + + cp -f /etc/libvirt/qemu/${VM}.xml ${DST}/ + +5. Remove old snapshot file + + rm -f ${SNAP}/backup-snapshot-${VM}.qcow2 + +When it comes to the blockcommit operation, the guest receives a SIGABRT. + +(gdb) bt +#0 0x00007f4b6e6ccb8e in raise () from /lib64/libc.so.6 +#1 0x00007f4b6e6ce391 in abort () from /lib64/libc.so.6 +#2 0x0000555a316a8c39 in qemu_coroutine_enter (co=0x555a34651a50, opaque=0x0) + at /var/tmp/portage/app-emulation/qemu-2.4.0/work/qemu-2.4.0/qemu-coroutine.c:111 +#3 0x0000555a316a8eda in qemu_co_queue_run_restart (co=co@entry=0x555a33d271b0) + at /var/tmp/portage/app-emulation/qemu-2.4.0/work/qemu-2.4.0/qemu-coroutine-lock.c:59 +#4 0x0000555a316a8b53 in qemu_coroutine_enter (co=0x555a33d271b0, opaque=<optimized out>) + at /var/tmp/portage/app-emulation/qemu-2.4.0/work/qemu-2.4.0/qemu-coroutine.c:118 +#5 0x0000555a316e3adf in bdrv_co_aio_rw_vector (bs=bs@entry=0x555a336a6be0, + sector_num=sector_num@entry=113551488, qiov=qiov@entry=0x555a3367d2c8, + nb_sectors=nb_sectors@entry=15360, flags=flags@entry=(unknown: 0), + cb=cb@entry=0x555a316e1fe0 <mirror_read_complete>, opaque=0x555a3367d2c0, is_write=is_write@entry=false) + at /var/tmp/portage/app-emulation/qemu-2.4.0/work/qemu-2.4.0/block/io.c:2142 +#6 0x0000555a316e4b1e in bdrv_aio_readv (bs=bs@entry=0x555a336a6be0, + sector_num=sector_num@entry=113551488, qiov=qiov@entry=0x555a3367d2c8, + nb_sectors=nb_sectors@entry=15360, cb=cb@entry=0x555a316e1fe0 <mirror_read_complete>, + opaque=opaque@entry=0x555a3367d2c0) + at /var/tmp/portage/app-emulation/qemu-2.4.0/work/qemu-2.4.0/block/io.c:1744 +#7 0x0000555a316e2ccf in mirror_iteration (s=0x555a34a0c250) + at /var/tmp/portage/app-emulation/qemu-2.4.0/work/qemu-2.4.0/block/mirror.c:302 +#8 mirror_run (opaque=0x555a34a0c250) + at /var/tmp/portage/app-emulation/qemu-2.4.0/work/qemu-2.4.0/block/mirror.c:512 +#9 0x0000555a316a9a5a in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) + at /var/tmp/portage/app-emulation/qemu-2.4.0/work/qemu-2.4.0/coroutine-ucontext.c:80 +#10 0x00007f4b6e6df4a0 in ?? () from /lib64/libc.so.6 +#11 0x00007ffe67b71840 in ?? () +#12 0x0000000000000000 in ?? () +(gdb) + +There is one very interesting aspect: + +After the guest died, I can restart it and if I do the exact same blockcommit and blockjob as shown above, everything succeeds without errors. That's strange. + +This is from my libvirt log. So you can see how the guest was started and the C-routine error message: + +2015-08-24 18:38:13.077+0000: starting up libvirt version: 1.2.18, qemu version: 2.4.0 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name mx.roessner-net.de-TESTING -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu qemu64,+kvm_pv_eoi -m 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid d86b82d5-153f-4dd9-aa66-d98c2e65db8c -no-user-config -nodefaults -device sga -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/mx.roessner-net.de-TESTING.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-shutdown -boot order=cd,menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x8 -drive file=/var/lib/libvirt/images/mx.roessner-net.de-TESTING.img,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=34,id=hostnet0,vhost=on,vhostfd=35 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:00:27:ac:8d,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/mx.roessner-net.de-TESTING.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -vnc 127.0.0.1:7 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device i6300esb,id=watchdog0,bus=pci.0,addr=0x7 -watchdog-action reset -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 -msg timestamp=on +char device redirected to /dev/pts/8 (label charserial0) +Formatting '/var/backups/snapshots/backup-snapshot-mx.roessner-net.de-TESTING.qcow2', fmt=qcow2 size=107374182400 backing_file='/var/lib/libvirt/images/mx.roessner-net.de-TESTING.img' backing_fmt='raw' encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +Formatting '/var/backups/snapshots/backup-snapshot-mx.roessner-net.de-TESTING.qcow2', fmt=qcow2 size=107374182400 backing_file='/var/lib/libvirt/images/mx.roessner-net.de-TESTING.img' backing_fmt='raw' encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 +Co-routine re-entered recursively +2015-08-24 19:43:17.700+0000: shutting down + +Here is my envirmornment information: + +emerge --info qemu +Portage 2.2.20.1 (python 2.7.9-final-0, hardened/linux/amd64/no-multilib, gcc-4.8.4, glibc-2.20-r2, 4.1.6-gentoo x86_64) +================================================================= + System Settings +================================================================= +System uname: Linux-4.1.6-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_L5520_@_2.27GHz-with-gentoo-2.2 +KiB Mem: 49454932 total, 7729532 free +KiB Swap: 2097148 total, 2097148 free +Timestamp of repository gentoo: Tue, 25 Aug 2015 21:15:01 +0000 +sh bash 4.3_p39 +ld GNU ld (Gentoo 2.24 p1.4) 2.24 +ccache version 3.1.9 [enabled] +app-shells/bash: 4.3_p39::gentoo +dev-lang/perl: 5.20.2::gentoo +dev-lang/python: 2.7.9-r1::gentoo, 3.4.1::gentoo +dev-util/ccache: 3.1.9-r4::gentoo +dev-util/cmake: 3.2.2::gentoo +dev-util/pkgconfig: 0.28-r2::gentoo +sys-apps/baselayout: 2.2::gentoo +sys-apps/openrc: 0.17::gentoo +sys-apps/sandbox: 2.6-r1::gentoo +sys-devel/autoconf: 2.69::gentoo +sys-devel/automake: 1.14.1::gentoo, 1.15::gentoo +sys-devel/binutils: 2.24-r3::gentoo +sys-devel/gcc: 4.8.4::gentoo +sys-devel/gcc-config: 1.7.3::gentoo +sys-devel/libtool: 2.4.6::gentoo +sys-devel/make: 4.1-r1::gentoo +sys-kernel/linux-headers: 3.18::gentoo (virtual/os-headers) +sys-libs/glibc: 2.20-r2::gentoo +Repositories: + +gentoo + location: /usr/portage + sync-type: rsync + sync-uri: rsync://rsync.europe.gentoo.org/gentoo-portage + priority: -1000 + +x-portage + location: /usr/local/portage + masters: gentoo + priority: 0 + +ACCEPT_KEYWORDS="amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-O2 -pipe" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/share/easy-rsa /usr/share/gnupg/qualified.txt" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/ /etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" +CXXFLAGS="-O2 -pipe" +DISTDIR="/usr/portage/distfiles" +EMERGE_DEFAULT_OPTS="--keep-going --with-bdeps=y --binpkg-respect-use=y --binpkg-changed-deps=y --usepkg=y --rebuilt-binaries=y --rebuilt-binaries-timestamp=20140405050000" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs ccache compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS="http://de-mirror.org/gentoo/ rsync://de-mirror.org/gentoo/" +LANG="en_US.utf8" +LC_ALL="en_US.UTF-8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed" +MAKEOPTS="-j17" +PKGDIR="/export/packages" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" +PORTAGE_TMPDIR="/var/tmp" +USE="acl adns aio amd64 bacula-clientonly bacula-console bash-completion berkdb bindist btrfs bzip2 caps cli cracklib crypt curl cxx device-mapper dri gdbm hardened iconv ipv6 justify logrotate loop-aes lzo mmap mmx mmxext modules ncurses nls nptl nscd ntp openmp openssl pam pax_kernel pcre pie readline seccomp session sse sse2 ssl ssp systemd tcpd threads unicode urandom vim-syntax xattr xtpax zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog aggregation cgroups contextswitch cpu cpufreq curl curl_json curl_xml disk email entropy ethstat exec filecount fscache hddtemp ipmi iptables logfile multimeter netlink network nfs nginx ntpd numa openvpn ping postgresql processes protocols python sensors snmp uptime users uuid" CPU_FLAGS_X86="mmx sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de en" NGINX_MODULES_HTTP="access auth_basic autoindex browser charset dav empty_gif fastcgi geo gzip headers_more limit_conn limit_req map memcached proxy referer rewrite scgi spdy split_clients ssi upstream_ip_hash userid uwsgi" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" QEMU_SOFTMMU_TARGETS="x86_64 i386" QEMU_USER_TARGETS="x86_64 i386" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON + +================================================================= + Package Settings +================================================================= + +app-emulation/qemu-2.4.0::gentoo was built with the following: +USE="aio caps curl debug fdt filecaps iscsi jpeg lzo ncurses nfs nls pin-upstream-blobs png python sasl seccomp snappy spice ssh systemtap threads tls usb usbredir uuid vhost-net virtfs vnc xattr xfs -accessibility -alsa -bluetooth -glusterfs -gtk -gtk2 -infiniband -numa -opengl -pulseaudio -rbd -sdl -sdl2 (-selinux) -smartcard -static -static-softmmu -static-user -tci -test -vde -vte -xen" PYTHON_TARGETS="python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64 -aarch64 (-alpha) (-arm) -cris -lm32 (-m68k) -microblaze -microblazeel (-mips) -mips64 -mips64el -mipsel -moxie -or32 (-ppc) (-ppc64) -ppcemb -s390x -sh4 -sh4eb (-sparc) -sparc64 -unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="i386 x86_64 -aarch64 (-alpha) (-arm) -armeb -cris (-m68k) -microblaze -microblazeel (-mips) -mips64 -mips64el -mipsel -mipsn32 -mipsn32el -or32 (-ppc) (-ppc64) -ppc64abi32 -s390x -sh4 -sh4eb (-sparc) -sparc32plus -sparc64 -unicore32" + +>>> Attempting to run pkg_info() for 'app-emulation/qemu-2.4.0' +Using: + app-emulation/spice-protocol-0.12.3 + sys-firmware/ipxe-1.0.0_p20130925 + sys-firmware/seabios-1.7.5 + USE=binary + sys-firmware/vgabios-0.7a + +The server hardware is a HP ProLiant SE316M1-R2 (also known as DL160 G6) with 48GB RAM and a RAID1+0 with 15k SAS disks. + +Problem is solved in current master branch + +Closing according to the previous comment + diff --git a/results/classifier/118/unknown/1528214 b/results/classifier/118/unknown/1528214 new file mode 100644 index 00000000..4af8e0dd --- /dev/null +++ b/results/classifier/118/unknown/1528214 @@ -0,0 +1,75 @@ +user-level: 0.910 +mistranslation: 0.907 +x86: 0.894 +semantic: 0.888 +permissions: 0.886 +debug: 0.882 +architecture: 0.871 +graphic: 0.863 +risc-v: 0.851 +ppc: 0.848 +virtual: 0.848 +hypervisor: 0.844 +PID: 0.842 +network: 0.840 +performance: 0.838 +vnc: 0.837 +assembly: 0.837 +register: 0.836 +peripherals: 0.833 +arm: 0.829 +KVM: 0.829 +device: 0.826 +TCG: 0.825 +socket: 0.811 +kernel: 0.807 +files: 0.782 +i386: 0.769 +VMM: 0.767 +boot: 0.750 + +qemu 1.7.0 vhost_net crash + +i find the crash in /var/crash +the crash content is : +<4>Pid: 6949, comm: qemu-system-x86 Not tainted 2.6.32-431.el6.x86_64 #1 Powerleader PR2530G2/SC612DI-8F +<4>RIP: 0010:[<ffffffff8118a849>] [<ffffffff8118a849>] fput+0x9/0x30 +<4>RSP: 0018:ffff88015b601d98 EFLAGS: 00010292 +<4>RAX: 0000000000000382 RBX: ffff881e46590000 RCX: 00000000000001c3 +<4>RDX: 0000000000000000 RSI: ffff881e46590130 RDI: 0000000000000000 +<4>RBP: ffff88015b601d98 R08: ffff881e46598518 R09: 0000000000000000 +<4>R10: 0000000000000000 R11: 0000000000000246 R12: ffff881e46590010 +<4>R13: 0000000000000000 R14: ffff880c29812748 R15: 0000000000000000 +<4>FS: 00007f6a74d20700(0000) GS:ffff8810b8840000(0000) knlGS:0000000000000000 +<4>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b +<4>CR2: 0000000000000030 CR3: 0000001c544cc000 CR4: 00000000001427e0 +<4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +<4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +<4>Process qemu-system-x86 (pid: 6949, threadinfo ffff88015b600000, task ffff880c1ed9c040) +<4>Stack: +<4> ffff88015b601e58 ffffffffa02ac3c8 ffff881e46590000 0000000000000000 +<4><d> ffff881e46590080 ffff881e46590078 ffff88015b601e38 0000000000000286 +<4><d> ffffffff00000000 0000000000000001 ffff88015b601e58 0000000000000282 +<4>Call Trace: +<4> [<ffffffffa02ac3c8>] vhost_net_ioctl+0x328/0x5d0 [vhost_net] +<4> [<ffffffff8119db42>] vfs_ioctl+0x22/0xa0 +<4> [<ffffffff8119dce4>] do_vfs_ioctl+0x84/0x580 +<4> [<ffffffff8118a7d1>] ? __fput+0x1a1/0x210 +<4> [<ffffffff8119e261>] sys_ioctl+0x81/0xa0 +<4> [<ffffffff810e1e5e>] ? __audit_syscall_exit+0x25e/0x290 +<4> [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b +<4>Code: fe ff ff 31 d2 48 89 de 83 cf ff ff d0 e9 da fe ff ff 48 89 df e8 28 64 04 00 e9 bb fe ff ff 0f 1f 00 55 48 89 e5 0f 1f 44 00 00 <f0> 48 ff 4f 30 0f 94 c0 84 c0 75 0b c9 c3 66 0f 1f +84 00 00 00 +<1>RIP [<ffffffff8118a849>] fput+0x9/0x30 +<4> RSP <ffff88015b601d98> +<4>CR2: 0000000000000030 + +how the bug occure + +my envionment is centos6.5 +and libvirt version is 1.2.14 + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU and the kernel? Or could we close this ticket nowadays? ... also, since this looks like a kernel bug instead of a QEMU bug, have you tried to report it to the KVM or virtio mailing list instead? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1589923 b/results/classifier/118/unknown/1589923 new file mode 100644 index 00000000..b6be8da7 --- /dev/null +++ b/results/classifier/118/unknown/1589923 @@ -0,0 +1,195 @@ +TCG: 0.923 +graphic: 0.917 +hypervisor: 0.909 +virtual: 0.908 +KVM: 0.908 +device: 0.904 +risc-v: 0.902 +peripherals: 0.898 +permissions: 0.893 +user-level: 0.891 +vnc: 0.890 +VMM: 0.889 +x86: 0.886 +register: 0.884 +ppc: 0.881 +debug: 0.876 +mistranslation: 0.863 +architecture: 0.853 +PID: 0.848 +performance: 0.843 +network: 0.842 +assembly: 0.836 +arm: 0.830 +semantic: 0.829 +socket: 0.818 +files: 0.817 +i386: 0.806 +kernel: 0.798 +boot: 0.768 + +https websockets not working in 2.5 or 2.6 + +% gdb --args ./x86_64-softmmu/qemu-system-x86_64 -vnc 0.0.0.0:1,tls,x509=/etc/pki/libvirt-le,websocket=5701 + +GNU gdb (GDB) 7.11 +Copyright (C) 2016 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "x86_64-pc-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: +<http://www.gnu.org/software/gdb/documentation/>. +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from ./x86_64-softmmu/qemu-system-x86_64...done. +(gdb) run +Starting program: /home/ben/qemu/qemu-2.6.0/x86_64-softmmu/qemu-system-x86_64 -vnc 0.0.0.0:1,tls,x509=/etc/pki/libvirt-le,websocket=5701 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib/libthread_db.so.1". +[New Thread 0x7fffe16f6700 (LWP 12767)] +[New Thread 0x7fffde2d4700 (LWP 12768)] +[New Thread 0x7fffd3fff700 (LWP 12769)] +Initializing VNC server with x509 no auth +Client sioc=0x55555874d6b0 ws=1 auth=1 subauth=0 +New client on socket 0x55555874d6b0 +vnc_set_share_mode/0x55555874d6b0: undefined -> connecting +TLS Websocket connection required +Start TLS WS handshake process +Handshake failed TLS handshake failed: The TLS connection was non-properly terminated. +Closing down client sock: protocol error +vnc_set_share_mode/0x55555779f510: connecting -> disconnected +Client sioc=0x55555873c6a0 ws=1 auth=1 subauth=0 +New client on socket 0x55555873c6a0 +vnc_set_share_mode/0x55555873c6a0: undefined -> connecting +TLS Websocket connection required +Start TLS WS handshake process +TLS handshake complete, starting websocket handshake +Websocket negotiate starting +Websock handshake complete, starting VNC protocol +Write Plain: Pending output 0x555557b91c60 size 4096 offset 12. Wait SSF 0 +Wrote wire 0x555557b91c60 12 -> 12 + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +0x0000000000000001 in ?? () +(gdb) thread apply all bt + +Thread 4 (Thread 0x7fffd3fff700 (LWP 12769)): +#0 0x00007fffef35a09f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 +#1 0x0000555555a20bd9 in qemu_cond_wait (cond=cond@entry=0x5555587267e0, + mutex=mutex@entry=0x555558726810) at util/qemu-thread-posix.c:123 +#2 0x00005555559770ab in vnc_worker_thread_loop (queue=queue@entry=0x5555587267e0) + at ui/vnc-jobs.c:228 +#3 0x00005555559775e8 in vnc_worker_thread (arg=0x5555587267e0) at ui/vnc-jobs.c:335 +#4 0x00007fffef354474 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007fffea43c69d in clone () from /usr/lib/libc.so.6 + +Thread 3 (Thread 0x7fffde2d4700 (LWP 12768)): +#0 0x00007fffef35a09f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 +#1 0x0000555555a20bd9 in qemu_cond_wait (cond=<optimized out>, +---Type <return> to continue, or q <return> to quit--- + emu_global_mutex>) at util/qemu-thread-posix.c:123 +#2 0x0000555555715edf in qemu_tcg_wait_io_event (cpu=0x5555564ee840) at /home/ben/qemu/qemu-2.6.0/cpus.c:1015 +#3 qemu_tcg_cpu_thread_fn (arg=<optimized out>) at /home/ben/qemu/qemu-2.6.0/cpus.c:1161 +#4 0x00007fffef354474 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007fffea43c69d in clone () from /usr/lib/libc.so.6 + +Thread 2 (Thread 0x7fffe16f6700 (LWP 12767)): +#0 0x00007fffea438229 in syscall () from /usr/lib/libc.so.6 +#1 0x0000555555a20ee8 in futex_wait (val=<optimized out>, ev=<optimized out>) at util/qemu-thread-posix.c:292 +#2 qemu_event_wait (ev=ev@entry=0x55555641ece4 <rcu_call_ready_event>) at util/qemu-thread-posix.c:399 +#3 0x0000555555a2f2ae in call_rcu_thread (opaque=<optimized out>) at util/rcu.c:250 +#4 0x00007fffef354474 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007fffea43c69d in clone () from /usr/lib/libc.so.6 + +Thread 1 (Thread 0x7ffff7f5bb00 (LWP 12763)): +#0 0x0000000000000001 in ?? () +#1 0x00005555559efb53 in qio_task_free (task=0x555558212140) at io/task.c:58 +#2 0x00005555559efd89 in qio_task_complete (task=task@entry=0x555558212140) at io/task.c:145 +#3 0x00005555559ef5aa in qio_channel_websock_handshake_send (ioc=0x55555873c6a0, condition=<optimized out>, + user_data=0x555558212140) at io/channel-websock.c:289 +#4 0x00007fffecf59c8a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#5 0x000055555598a6b3 in glib_pollfds_poll () at main-loop.c:213 +#6 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:258 +#7 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506 +#8 0x00005555556e1fbd in main_loop () at vl.c:1934 +#9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4656 + +The crash in 2.6 is fixed by + + https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01885.html + +The dropped connection in 2.5 is fixed by + + https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01884.html + +Fix has been included in QEMU v2.7.0: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=bc35d51077b33e68a0 + + +Fixed in stable-2.6 branch in + +commit 510531ea442a02048b1837fcf574d03559b38c9e +Author: Daniel P. Berrange <email address hidden> +Date: Tue Jun 7 12:27:51 2016 +0100 + + io: remove mistaken call to object_ref on QTask + + The QTask struct is just a standalone struct, not a QOM Object, + so calling object_ref() on it is not appropriate. This results + in mangling the 'destroy' field in the QTask struct, causing + the later call to qtask_free() to try to call the function + at address 0x1, with predictably segfault happy results. + + There is in fact no need for ref counting with QTask, as the + call to qtask_abort() or qtask_complete() will automatically + free associated memory. + + This fixes the crash shown in + + https://bugs.launchpad.net/qemu/+bug/1589923 + + Reviewed-by: Eric Blake <email address hidden> + Signed-off-by: Daniel P. Berrange <email address hidden> + (cherry picked from commit bc35d51077b33e68a0ab10a057f352747214223f) + Signed-off-by: Michael Roth <email address hidden> + + + +Fixed in >=2.7 and thereby >=Zesty. +Needs to be considered for SRUs now. + +I added this to my list a while ago but now closed out the immediate tasks for artful, so I'm coming back here. +Writing repro steps which will be needed for the SRU. + +# Brute force create dummy keys for this +openssl req -out ca.pem -new -x509 +openssl genrsa -out server.key 1024 +openssl req -key server.key -new -out server.req +echo 00 > file.srl +openssl x509 -req -in server.req -CA ca.pem -CAkey privkey.pem -CAserial file.srl -out server-cert.pem +openssl genrsa -out client.key 1024 +openssl req -key client.key -new -out client.req +openssl x509 -req -in client.req -CA ca.pem -CAkey privkey.pem -CAserial file.srl -out client-cert.pem +ln -s ca.pem ca-cert.pem +ln -s server.key server-key.pem + +# run qemu with x509 websocket +/usr/bin/qemu-system-x86_64 -vnc 0.0.0.0:1,tls,x509=$(pwd),websocket=5707 + +It is not crashing and I can even connect with krdc (likely also other clients) against it without breaking. + +But then I'd think your command above for the crash was the one for the crash in 2.6 which was yakkety. + +But what is left to fix is the dropped connection [1] in 2.5 (Xenial). + +I tried to read a better testcase out of that mail thread but failed, if you'd have a better setup description to still trigger this blocked handshake that eventually fails once the signal sets data - that would be great. +The actual report I found [2] is actually this bug bridges onto the ML so no more info there for me. + +[1]: https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01884.html +[2]: https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01917.html + diff --git a/results/classifier/118/unknown/1596832 b/results/classifier/118/unknown/1596832 new file mode 100644 index 00000000..8207a810 --- /dev/null +++ b/results/classifier/118/unknown/1596832 @@ -0,0 +1,107 @@ +debug: 0.893 +virtual: 0.887 +user-level: 0.883 +permissions: 0.871 +boot: 0.866 +ppc: 0.861 +device: 0.857 +arm: 0.857 +performance: 0.850 +risc-v: 0.849 +PID: 0.847 +register: 0.847 +graphic: 0.842 +peripherals: 0.841 +semantic: 0.840 +assembly: 0.836 +mistranslation: 0.834 +kernel: 0.830 +KVM: 0.823 +hypervisor: 0.816 +VMM: 0.813 +architecture: 0.811 +TCG: 0.809 +x86: 0.796 +vnc: 0.791 +socket: 0.770 +network: 0.757 +files: 0.755 +i386: 0.706 + +e500 -bios/-kernel broken with big images + +This is tested using qemu 2.4.1, but it looks like the code qemu/hw/ppc/e500.c has not changed since. This looks like the source of the problem: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3812c71ffaa2cf733c3087792b859fef30b7545f + + +What works: +---------- + +Basic invocation qemu-system-ppc -machine ppce500 -monitor stdio -bios u-boot.e500 works, I get the uboot prompt and this: + +(qemu) info roms +addr=0000000000f00000 size=0x044b8c mem=ram name="phdr #0: .../qemu/share/qemu/u-boot.e500" +addr=0000000000f81000 size=0x006b00 mem=ram name="phdr #1: .../qemu/share/qemu/u-boot.e500" + + +Passing u-boot.e500 image as kernel (-bios u-boot.e500 -kernel u-boot.e500) appears to work, $qemu_kernel_addr is filled in, though (as expected) uboot complains about the image format. + +(qemu) info roms +addr=0000000000f00000 size=0x044b8c mem=ram name="phdr #0: .../qemu/share/qemu/u-boot.e500" +addr=0000000000f81000 size=0x006b00 mem=ram name="phdr #1: .../qemu/share/qemu/u-boot.e500" +addr=0000000002000000 size=0x054e8c mem=ram name=".../qemu/share/qemu/u-boot.e500 + + + +What doesn't work: +----------------- + +However, once I try to load a big image (>=32 MiB), uboot doesn't even show anything: + +qemu-system-ppc -machine ppce500 -monitor stdio -bios u-boot.e500 -kernel boot/vmlinux -m 1024 + +(qemu) info roms +addr=0000000000f00000 size=0x044b8c mem=ram name="phdr #0: .../qemu/share/qemu/u-boot.e500" +addr=0000000000f81000 size=0x006b00 mem=ram name="phdr #1: .../qemu/share/qemu/u-boot.e500" +addr=0000000002000000 size=0x27aeedc mem=ram name="boot/vmlinux" + +... +(gdb) bt +#0 0x00f2efcc in ?? () +#1 0x00f31554 in ?? () +#2 0x00f03f4c in ?? () +#3 0x00f04458 in ?? () +#4 0x00f028dc in ?? () +#5 0x00f01080 in ?? () + + + +The thing is, this used to work +- before the commit, where I'd just pass the image as -kernel option, and it booted. + + +If I do that now (w/o the -bios option, using the exact same image), the kernel gets loaded twice, only at different addresses (the cause is obvious from the commit), causing overlap error: + +qemu-system-ppc -machine ppce500 -monitor stdio -kernel boot/vmlinux -m 1024 +QEMU 2.4.1 monitor - type 'help' for more information +(qemu) rom: requested regions overlap (rom boot/vmlinux. free=0x00000000027492fc, addr=0x0000000002000000) + +Curious: Is your guest kernel >=3.6 with qemu-ppce500 config ie qemu_ppce500 defined etc? +In case u-boot loads/maps uImage format kernel differently have you tried uImage vs vmlinux? + +And are you able to boot ok with an mpc... machine instead of ppce500 by specifying a dtb file or dtb compatibility? Do you know if more recent qemu (2.8 or 3 or 4.2) has same issue for you? + +Oh wow I just noticed this is from 2016! It would be nice for such bugs to have follow-up, closure, or summary of solution/circumvention/workaround taken by those who posted them :) + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1598 b/results/classifier/118/unknown/1598 new file mode 100644 index 00000000..582b1e95 --- /dev/null +++ b/results/classifier/118/unknown/1598 @@ -0,0 +1,88 @@ +peripherals: 0.878 +permissions: 0.861 +architecture: 0.861 +KVM: 0.843 +performance: 0.839 +risc-v: 0.838 +debug: 0.830 +virtual: 0.822 +device: 0.820 +graphic: 0.820 +kernel: 0.811 +PID: 0.809 +ppc: 0.809 +TCG: 0.808 +x86: 0.805 +boot: 0.804 +vnc: 0.804 +register: 0.802 +i386: 0.800 +arm: 0.794 +VMM: 0.791 +mistranslation: 0.790 +hypervisor: 0.786 +semantic: 0.786 +assembly: 0.773 +network: 0.769 +files: 0.756 +socket: 0.754 +user-level: 0.718 + +vfio-pci - Intel Arc DG2 - host errors +Description of problem: +The host continues to respond (slowly) after the VM is shutdown. Speeds back up to normal after about an hour. However, a reboot is required to get the host to operate normally. + +When shutting down the VM, the host starts to display the following messages in dmesg: + +[Thu Apr 13 01:30:47 2023] vfio-pci 0000:18:00.0: not ready 1023ms after FLR; waiting +[Thu Apr 13 01:30:49 2023] vfio-pci 0000:18:00.0: not ready 2047ms after FLR; waiting +[Thu Apr 13 01:30:52 2023] vfio-pci 0000:18:00.0: not ready 4095ms after FLR; waiting +[Thu Apr 13 01:30:57 2023] vfio-pci 0000:18:00.0: not ready 8191ms after FLR; waiting +[Thu Apr 13 01:31:06 2023] vfio-pci 0000:18:00.0: not ready 16383ms after FLR; waiting +[Thu Apr 13 01:31:25 2023] vfio-pci 0000:18:00.0: not ready 32767ms after FLR; waiting +[Thu Apr 13 01:31:59 2023] vfio-pci 0000:18:00.0: not ready 65535ms after FLR; giving up +[Thu Apr 13 01:32:11 2023] vfio-pci 0000:18:00.0: not ready 1023ms after bus reset; waiting +[Thu Apr 13 01:32:13 2023] vfio-pci 0000:18:00.0: not ready 2047ms after bus reset; waiting +[Thu Apr 13 01:32:16 2023] vfio-pci 0000:18:00.0: not ready 4095ms after bus reset; waiting +[Thu Apr 13 01:32:21 2023] vfio-pci 0000:18:00.0: not ready 8191ms after bus reset; waiting +[Thu Apr 13 01:32:31 2023] vfio-pci 0000:18:00.0: not ready 16383ms after bus reset; waiting +[Thu Apr 13 01:32:48 2023] vfio-pci 0000:18:00.0: not ready 32767ms after bus reset; waiting +[Thu Apr 13 01:33:22 2023] vfio-pci 0000:18:00.0: not ready 65535ms after bus reset; giving up +Steps to reproduce: +1. Shutdown VM. +Additional information: +I have startup and shutdown scripts that detach and reattach the card and these scripts work fine if I test them alone. It's only when I shutdown the VM that issue presents itself. + +revert.sh + +``` +#!/bin/bash +set -x + +systemctl reboot # to workaround host lockup on shutdown + +# Load the config file with our environmental variables +source "/etc/libvirt/hooks/kvm.conf" +source "/etc/libvirt/hooks/vmPreBootSetup" + +cpuSchedutil + +# Unload VFIO-PCI Kernel Driver +modprobe -r vfio_pci +modprobe -r vfio_iommu_type1 +modprobe -r vfio + +# Re-Bind GPU to our display drivers +virsh nodedev-reattach $VIRSH_GPU_VIDEO +virsh nodedev-reattach $VIRSH_GPU_AUDIO + +#modprobe drm_buddy intel_gtt video drm_display_helper cec ttm i915 + +# Restart Display Manager +systemctl restart sddm.service +``` + + + +Full dmesg log: +[vfio_13_april_2023.txt](/uploads/5d5b642595c53cabb3c3608c07d59eb3/vfio_13_april_2023.txt) diff --git a/results/classifier/118/unknown/1617929 b/results/classifier/118/unknown/1617929 new file mode 100644 index 00000000..a5dfb602 --- /dev/null +++ b/results/classifier/118/unknown/1617929 @@ -0,0 +1,116 @@ +hypervisor: 0.880 +mistranslation: 0.877 +user-level: 0.863 +risc-v: 0.862 +permissions: 0.859 +TCG: 0.854 +x86: 0.850 +graphic: 0.850 +peripherals: 0.847 +virtual: 0.844 +KVM: 0.841 +register: 0.840 +i386: 0.828 +arm: 0.828 +semantic: 0.824 +assembly: 0.823 +debug: 0.820 +performance: 0.817 +vnc: 0.811 +device: 0.809 +architecture: 0.809 +ppc: 0.804 +PID: 0.794 +VMM: 0.794 +files: 0.788 +socket: 0.755 +network: 0.701 +kernel: 0.700 +boot: 0.698 + +qemu hangs in pselect syscall + +I'm using git commit d75aa4372f0414c9960534026a562b0302fcff29 (v2.7.0-rc4) configured with; + --enable-linux-user \ + --disable-system \ + --disable-tools \ + --disable-guest-agent \ + --static --disable-linux-aio \ + --disable-fdt \ + --without-pixman \ + --disable-blobs \ +Stable version (v2.6.0) also have the same problem. + +In a chroot environment I ran below command-line to compile some things, different sources each time. + /usr/bin/qemu-arm -0 /usr/bin/edje_cc /usr/bin/edje_cc -id /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/services/SimpleUI/images_mob/ -DBROWSER_RESOLUTION_720x1280=1 -DPROFILE_MOBILE=1 /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/services/SimpleUI/edc/TextPopup_mob.edc /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/build-tizen/services/SimpleUI/720x1280_TextPopup.edj + +Here is back trace with gdb; +#0 safe_syscall_end () at /usr/src/debug/qemu-2.6.94/linux-user/host/i386/safe-syscall.inc.S:78 +#1 0x60049370 in safe_pselect6 (nfds=10, readfds=0xffa31b5c, writefds=0xffa31bdc, exceptfds=0xffa31c5c, timeout=0x0, sig=0x0) + at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:855 +#2 0x6004b2fe in do_select (n=10, rfd_addr=1082122232, wfd_addr=1082122360, efd_addr=1082122488, target_tv_addr=0) + at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:1386 +#3 0x6005e5ba in do_syscall (cpu_env=0x640d0454, num=142, arg1=10, arg2=1082122232, arg3=1082122360, arg4=1082122488, arg5=0, arg6=1087473216, arg7=0, + arg8=0) at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:9690 +#4 0x60045def in cpu_loop (env=0x640d0454) at /usr/src/debug/qemu-2.6.94/linux-user/main.c:876 +#5 0x60047640 in main (argc=10, argv=0xffa33c84, envp=0xffa33cb0) at /usr/src/debug/qemu-2.6.94/linux-user/main.c:4817 + +Attached core file taken from gdb. To see the stack frame, you could try; +$ tar -xf reproduced_118_04.tar.bz2; gdb --core core.1823 qemu-arm + +And recent strace log for PID 1823(stucked one); +79965 [ 313s] 1823 :0x8e _newselect(10,[9,3,],[],[],NULL) +79966 [ 313s] ==>[pselect6(0xa)=] +79967 [ 313s] [pselect6=0x1]<== +79968 [ 313s] 1823 :0x8e _newselect(10,[9,],[],[],NULL) +79969 [ 313s] 1823 :0x8e => = 0x00000001 ([9,],[],[],NULL) +79970 [ 313s] 1823 :0xfc epoll_wait(3,1082121456,32,0,1082121456,3) +79971 [ 313s] 1823 :0xfc epoll_wait(3,1082121456,32,0,1082121456,3) +79972 [ 313s] 1823 :0xfc => = 0 +79973 [ 313s] 1823 :0x3 read(9,0x407fdeec,16) +79974 [ 313s] 1823 :0x3 read(9,0x407fdeec,16) +79975 [ 313s] 1823 :0x3 => = 8 +79976 [ 313s] 1823 :0x107 clock_gettime(1,1082122120,0,1082829144,1082827588,0) +79977 [ 313s] 1823 :0x107 clock_gettime(1,1082122120,0,1082829144,1082827588,0) +79978 [ 313s] 1823 :0x107 => = 0 +79979 [ 313s] 1823 :0x8e _newselect(10,[9,3,],[],[],NULL) +79980 [ 313s] ==>[pselect6(0xa)=] + +I'm using 64-bit Ubuntu with kernel release Linux 3.19.0-25-generic #26~14.04.1-Ubuntu. +Reproducibility is low. One occurrence out of 50+ trials. + + + +FYI, adding a build log with strace enabled. + +Can you provide sufficient instructions for me to reproduce this on my machine, please? + + +Second part of scratch.armv7l.0.tar.gz. + +Third part of scratch.armv7l.0.tar.gz. + +Dear Peter. + +Thank you for the update. +Please find the attached full chroot environment that I used(scratch.armv7l.0.tar.gz, split three parts). +You could try make build with below steps; + +$ sudo su +$ echo -1 > /proc/sys/fs/binfmt_misc/arm +$ echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfa\xff\xff\xff:/usr/bin/qemu-arm-static:' > /proc/sys/fs/binfmt_misc/register + +$ cat scratch.armv7l.0.tar.gz.a* > scratch.armv7l.0.tar.gz; sudo tar -zxf scratch.armv7l.0.tar.gz +$ cd scratch.armv7l.0 +$ chroot . + chroot> cd /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/build-tizen/services/ + chroot> while :; do make clean; make -j32; done + +Reproducibility is ver low but it surely happened. + +Thanks. + + +I can't reproduce this with current git master, and I know we fixed a lot of race conditions in linux-user. So I'm going to close this bug -- if it's still a problem for you with new QEMU, please reopen, preferably with a repro case that's more frequent than 1-in-50-or-less. + + diff --git a/results/classifier/118/unknown/1619991 b/results/classifier/118/unknown/1619991 new file mode 100644 index 00000000..a582aeeb --- /dev/null +++ b/results/classifier/118/unknown/1619991 @@ -0,0 +1,167 @@ +user-level: 0.869 +files: 0.854 +ppc: 0.850 +mistranslation: 0.850 +register: 0.844 +risc-v: 0.842 +graphic: 0.839 +permissions: 0.839 +boot: 0.838 +KVM: 0.838 +device: 0.837 +VMM: 0.834 +TCG: 0.834 +performance: 0.832 +semantic: 0.828 +virtual: 0.826 +arm: 0.825 +debug: 0.824 +network: 0.824 +assembly: 0.823 +PID: 0.822 +socket: 0.817 +vnc: 0.809 +architecture: 0.805 +kernel: 0.802 +hypervisor: 0.797 +peripherals: 0.775 +x86: 0.764 +i386: 0.744 + +Concurrent VMs crash w/ GPU passthrough and multiple disks + +When running multiple VMs with GPU passthrugh, both VMs will crash unless all virtual disks are on the same physical volume as root, likely on all X58 chipset motherboards. I've tested with 3. + +Expected Behavior: No Crash +Result: Both VMs GPU drivers fail and the guest OS are unrecoverable, usually within seconds, though the degree of "fickleness" of it depends on the multidisk setup. +Reproducibility: 100% + + +Steps to reproduce: + +* Install OS (In my case Debian Jessie/Proxmox), and update to latest +* Setup VMs +* Setup up GPU passthrough with 1 GPU per VM, and one for host, as per https://pve.proxmox.com/wiki/Pci_passthrough +* Setup up USB passthrough +* Launch both VM +* Observe "everything is working" +* Stop VMs +* Add a second disk to one of the VMs, which exists on a separate physical disk from Host OS / +* Observe both VMs crash when the virtual disk which exists on separate physical media is used (i.e. copy files to the disk) +* Stop VMs +* Remove new disk, and move Guest OS virtual root disk to separate physical media. +* Observe both VMs crash around the time GPU driver is loaded on one + +As I mentioned earlier, there is some degree of difference in how difficult it is to trigger a crash, depending on the multidisk setup. For instance, when / is ZFS, and the virtual disks exist on a separate ZFS raid-z volume, both VMs must be doing some relatively intensive HW 3d acceleration in order to trigger the crash. + +Passing two GPU to one VM works fine all the time, and running either VM on its in general will not trigger a crash. + +There are many variables I have yet to test, such as using sata instead of virtio for the virtual disks, however unfortunately I do not have anything from std err or logs to indicate what the problem could be. + +kernel verion: Linux test-ve 4.4.15-1-pve (other versions >= 4.2.1 and <= 4.7.? tested) +qemu version: 2.6.0 pve-qemu-kvm_2.6-1 +motherboards tested: rampage iii, ga-ex58-ud5, asus Psomething +CPUs tested: i7 920, X5670 + + +KVM invocation 1: + +/usr/bin/kvm \ +-id 101 \ +-chardev socket,id=qmp,path=/var/run/qemu-server/101.qmp,server,nowait \ +-mon chardev=qmp,mode=control \ +-pidfile /var/run/qemu-server/101.pid \ +-daemonize \ +-smbios type=1,uuid=450e337e-244c-429b-9aa8-afb7aee037e8 \ +-drive if=pflash,format=raw,readonly,file=/usr/share/kvm/OVMF-pure-efi.fd \ +-drive if=pflash,format=raw,file=/root/101-OVMF_VARS-pure-efi.fd \ +-name Madzia-PC \ +-smp 12,sockets=1,cores=12,maxcpus=12 \ +-nodefaults \ +-boot menu=on,strict=on,reboot-timeout=1000 \ +-vga none \ +-nographic \ +-no-hpet \ +-cpu host,hv_vendor_id=Nvidia43FIX,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,+kvm_pv_unhalt,+kvm_pv_eoi,kvm=off \ +-m 8192 \ +-object memory-backend-ram,id=ram-node0,size=8192M \ +-numa node,nodeid=0,cpus=0-11,memdev=ram-node0 \ +-k en-us -readconfig /usr/share/qemu-server/pve-q35.cfg \ +-device usb-tablet,id=tablet,bus=ehci.0,port=1 \ +-device vfio-pci,host=04:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0 \ +-device vfio-pci,host=04:00.1,id=hostpci1,bus=ich9-pcie-port-2,addr=0x0 \ +-device usb-host,hostbus=1,hostport=6.1,id=usb0 \ +-device usb-host,hostbus=1,hostport=6.2.1,id=usb1 \ +-device usb-host,hostbus=1,hostport=6.2.2,id=usb2 \ +-device usb-host,hostbus=1,hostport=6.2.3,id=usb3 \ +-device usb-host,hostbus=1,hostport=6.2,id=usb4 \ +-device usb-host,hostbus=1,hostport=6.3,id=usb5 \ +-device usb-host,hostbus=1,hostport=6.4,id=usb6 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 \ +-iscsi initiator-name=iqn.1993-08.org.debian:01:3f3df5515b13 \ +-drive file=/dev/pve/vm-101-disk-1,if=none,id=drive-virtio0,cache=writeback,format=raw,aio=threads,detect-zeroes=on \ +-device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 \ +-netdev type=tap,id=net0,ifname=tap101i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on \ +-device virtio-net-pci,mac=4E:DD:47:D7:DF:C9,netdev=net0,bus=pci.0,addr=0x12,id=net0 \ +-rtc driftfix=slew,base=localtime \ +-machine type=q35 \ +-global kvm-pit.lost_tick_policy=discard + + +KVM invocation 2: + +/usr/bin/kvm \ +-id 102 \ +-chardev socket,id=qmp,path=/var/run/qemu-server/102.qmp,server,nowait \ +-mon chardev=qmp,mode=control \ +-pidfile /var/run/qemu-server/102.pid \ +-daemonize \ +-smbios type=1,uuid=450e337e-244c-429b-9aa8-afb7aee037e8 \ +-drive if=pflash,format=raw,readonly,file=/usr/share/kvm/OVMF-pure-efi.fd \ +-drive if=pflash,format=raw,file=/root/102-OVMF_VARS-pure-efi.fd \ +-name Madzia-PC \ +-smp 12,sockets=1,cores=12,maxcpus=12 \ +-nodefaults \ +-boot menu=on,strict=on,reboot-timeout=1000 \ +-vga none \ +-nographic \ +-no-hpet \ +-cpu host,hv_vendor_id=Nvidia43FIX,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_reset,hv_vpindex,hv_runtime,hv_relaxed,+kvm_pv_unhalt,+kvm_pv_eoi,kvm=off \ +-m 512 \ +-object memory-backend-ram,id=ram-node0,size=512M \ +-numa node,nodeid=0,cpus=0-11,memdev=ram-node0 \ +-k en-us \ +-readconfig /usr/share/qemu-server/pve-q35.cfg \ +-device usb-tablet,id=tablet,bus=ehci.0,port=1 \ +-device vfio-pci,host=05:00.0,id=hostpci2,bus=ich9-pcie-port-3,addr=0x0 \ +-device vfio-pci,host=05:00.1,id=hostpci3,bus=ich9-pcie-port-4,addr=0x0 \ +-device usb-host,hostbus=2,hostport=2.1,id=usb0 \ +-device usb-host,hostbus=2,hostport=2.2,id=usb1 \ +-device usb-host,hostbus=2,hostport=2.3,id=usb2 \ +-device usb-host,hostbus=2,hostport=2.4,id=usb3 \ +-device usb-host,hostbus=2,hostport=2.5,id=usb4 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 \ +-iscsi initiator-name=iqn.1993-08.org.debian:01:3f3df5515b13 \ +-drive file=/dev/pve/vm-102-disk-1,if=none,id=drive-virtio0,cache=writeback,format=raw,aio=threads,detect-zeroes=on \ +-device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 \ +-netdev type=tap,id=net0,ifname=tap102i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on \ +-device virtio-net-pci,mac=4E:DD:47:D7:DF:C9,netdev=net0,bus=pci.0,addr=0x12,id=net0 \ +-rtc driftfix=slew,base=localtime \ +-machine type=q35 \ +-global kvm-pit.lost_tick_policy=discard + + +Please let me know what additional information may be helpful, or how I can be of any assistance. + +The second invocation should show a second disk on separate physical media, like: + +-drive file=/mnt/images/102/vm-102-disk-1.qcow2,if=none,id=drive-virtio1,cache=writeback,format=qcow2,aio=threads,detect-zeroes=on \ +-device virtio-blk-pci,drive=drive-virtio1,id=virtio1,bus=pci.0,addr=0xb + +I forgot to mention that the Guest OS is Windows 10 64 in both cases. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1648726 b/results/classifier/118/unknown/1648726 new file mode 100644 index 00000000..0916f771 --- /dev/null +++ b/results/classifier/118/unknown/1648726 @@ -0,0 +1,59 @@ +user-level: 0.966 +mistranslation: 0.937 +risc-v: 0.896 +TCG: 0.895 +register: 0.893 +KVM: 0.893 +permissions: 0.892 +ppc: 0.891 +vnc: 0.880 +x86: 0.877 +VMM: 0.874 +performance: 0.873 +hypervisor: 0.871 +peripherals: 0.871 +graphic: 0.860 +debug: 0.854 +arm: 0.853 +semantic: 0.845 +assembly: 0.842 +device: 0.841 +i386: 0.837 +boot: 0.837 +socket: 0.835 +files: 0.829 +network: 0.817 +virtual: 0.813 +architecture: 0.811 +kernel: 0.796 +PID: 0.775 + +[usb-host] Passthrough of UAS devices fails with Windows (10) guests + +Split off from #1579306 as this is a distinct issue. + +Physical USB storage devices that support the UAS protocol do not work correctly when passed through to Windows guests (I've only tested this with Windows 10 x64, build 1607). + +Passing through such a device results in the older BOT/MSC protocol being used: + +<See attachment win10-uas-fail.png> + +Using the same domain configuration with a Linux guest (tested with SystemRescueCD 4.8.0) works correctly: + +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M + |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + + +In both cases, the VM was launched via libvirt, which generated the following command line: + +/usr/bin/qemu-system-x86_64 -name guest=Win10-Edge-IE11,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 47c39707-088c-4edc-8b6a-a7856e09f43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device nec-usb-xhci,id=usb,bus=pci.2,addr=0x6 -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/home/jack/IMG/Win10-Edge-IE11.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:27:94:5d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -device usb-host,hostbus=4,hostaddr=4,id=hostdev0,bus=usb.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on + + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the +inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1665389 b/results/classifier/118/unknown/1665389 new file mode 100644 index 00000000..3f6cd1c2 --- /dev/null +++ b/results/classifier/118/unknown/1665389 @@ -0,0 +1,244 @@ +risc-v: 0.879 +debug: 0.876 +hypervisor: 0.865 +user-level: 0.863 +permissions: 0.862 +peripherals: 0.859 +performance: 0.854 +virtual: 0.850 +mistranslation: 0.850 +VMM: 0.845 +register: 0.843 +semantic: 0.842 +vnc: 0.841 +device: 0.838 +assembly: 0.838 +i386: 0.832 +graphic: 0.829 +files: 0.828 +KVM: 0.826 +architecture: 0.817 +arm: 0.814 +ppc: 0.810 +TCG: 0.810 +socket: 0.809 +boot: 0.804 +PID: 0.801 +network: 0.800 +kernel: 0.794 +x86: 0.752 + +Nested kvm guest fails to start on a emulated Westmere CPU guest under a Broadwell CPU host + +Using latest master(5dae13), qemu fails to start any nested guest in a Westmere emulated guest(layer 1), under a Broadwell host(layer 0), with the error: + +qemu-custom: /root/qemu/target/i386/kvm.c:1849: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +The qemu command used(though other CPUs didn't work either): +/usr/bin/qemu-custom -name guest=12ed9230-vm-el73,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-12ed9230-vm-el73/master-key.aes -machine pc-i440fx-2.9,accel=kvm,usb=off -cpu Westmere,+vmx -m 512 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid f4ce4eba-985f-42a3-94c4-6e4a8a530347 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-5-12ed9230-vm-el73/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/root/lago/.lago/default/images/vm-el73_root.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,serial=1,discard=unmap -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:c0:a7:c8:02,bus=pci.0,addr=0x2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-5-12ed9230-vm-el73/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x9 -msg timestamp=on +2017-02-16T15:14:45.840412Z qemu-custom: -chardev pty,id=charserial0: char device redirected to /dev/pts/2 (label charserial0) +qemu-custom: /root/qemu/target/i386/kvm.c:1849: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + + +The CPU flags in the Westmere guest: +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc rep_good nopl pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm arat tpr_shadow vnmi flexpriority ept vpid + +The guest kernel is 3.10.0-514.2.2.el7.x86_64. + +The CPU flags of the host(Broadwell): +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp + +qemu command on the host - Broadwell(which works): +/usr/bin/qemu-kvm -name 4ffcd448-vm-el73,debug-threads=on -S -machine pc-i440fx-2.6,accel=kvm,usb=off -cpu Westmere,+x2apic,+vmx,+vme -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid 8cc0a2cf-d25a-4014-acdb-f159c376a532 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-4-4ffcd448-vm-el73/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/home/ngoldin/src/nvgoldin.github.com/lago-init-files/.lago/flags-tests/default/images/vm-el73_root.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,serial=1,discard=unmap -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/ngoldin/src/nvgoldin.github.com/lago-init-files/.lago/flags-tests/default/images/vm-el73_additonal.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,serial=2,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=54:52:c0:a8:c9:02,bus=pci.0,addr=0x2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-4-4ffcd448-vm-el73/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x9 -msg timestamp=on + +On the Broadwell host I'm using a distribution package if it matters(qemu-kvm-2.6.2-5.fc24.x86_64 and 4.8.15-200.fc24.x86_64) + +As the error indicates, I think this assertion was put in: +commit 48e1a45c3166d659f781171a47dabf4a187ed7a5 +Author: Paolo Bonzini <email address hidden> +Date: Wed Mar 30 22:55:29 2016 +0200 + + target-i386: assert that KVM_GET/SET_MSRS can set all requested MSRs + + This would have caught the bug in the previous patch. + + Signed-off-by: Paolo Bonzini <email address hidden> + +I tried going back one commit before to 273c515, and then the error is gone and the nested guest comes up as expected. If I try to run with head at the above commit(48e145c) the error output is slightly different, though it looks the same: +/root/qemu/target-i386/kvm.c:1713: kvm_put_msrs: Assertion `ret == n' failed. + +Hi Nadav, + Can you clarify what the host and L1 kernels are please? + +This error means that qemu tried to write some msrs but one of the msr writes failed; we need to figure out which one to understand what's going on. + +1) Edit kvm_msr_entry_add in target/i386/kvm.c to something like: + + assert((void *)(entry + 1) <= limit); + fprintf(stderr,"kvm_msr_entry_add: @%d index=%x value=%lx\n", msrs->nmsrs, index, value); + entry->index = index; + +2) edit kvm_put_msrs near the bottom: + + fprintf(stderr,"kvm_put_msrs: ret=%d expected=%d\n", ret, cpu->kvm_msr_buf->nmsrs); + assert(ret == cpu->kvm_msr_buf->nmsrs); + +Now with any luck the 'ret' value will tell you the entry which is bad, and you can match +that to the @%d value (or maybe it's the entry before that one which failed?) then we get the index, look it up in the intel docs and figure out which MSR it's complaining about. + +Also, does the problem go away if you remove the +x2apic on the top level qemu? + +Dave + +Hi Dave, thanks for looking into this. + +> Can you clarify what the host and L1 kernels are please? + +Host - 4.8.15-200.fc24.x86_64 +Guest - 3.10.0-514.2.2.el7.x86_64 + +Results of adding the debug messages and running a simpler command(with master again - 5dae13): + +[root@vm-el73 ~]# /usr/bin/qemu-custom -s -machine pc,accel=kvm,usb=off -cpu Westmere +kvm_msr_entry_add: @0 index=174 value=0 +kvm_msr_entry_add: @1 index=175 value=0 +kvm_msr_entry_add: @2 index=176 value=0 +kvm_msr_entry_add: @3 index=277 value=7040600070406 +kvm_msr_entry_add: @4 index=c0000081 value=0 +kvm_msr_entry_add: @5 index=c0010117 value=0 +kvm_msr_entry_add: @6 index=3b value=0 +kvm_msr_entry_add: @7 index=1a0 value=1 +kvm_msr_entry_add: @8 index=9e value=30000 +kvm_msr_entry_add: @9 index=d90 value=0 +kvm_msr_entry_add: @10 index=c0000083 value=0 +kvm_msr_entry_add: @11 index=c0000102 value=0 +kvm_msr_entry_add: @12 index=c0000084 value=0 +kvm_msr_entry_add: @13 index=c0000082 value=0 +kvm_msr_entry_add: @14 index=10 value=0 +kvm_msr_entry_add: @15 index=12 value=0 +kvm_msr_entry_add: @16 index=11 value=0 +kvm_msr_entry_add: @17 index=4b564d02 value=0 +kvm_msr_entry_add: @18 index=4b564d04 value=0 +kvm_msr_entry_add: @19 index=4b564d03 value=0 +kvm_msr_entry_add: @20 index=2ff value=0 +kvm_msr_entry_add: @21 index=250 value=0 +kvm_msr_entry_add: @22 index=258 value=0 +kvm_msr_entry_add: @23 index=259 value=0 +kvm_msr_entry_add: @24 index=268 value=0 +kvm_msr_entry_add: @25 index=269 value=0 +kvm_msr_entry_add: @26 index=26a value=0 +kvm_msr_entry_add: @27 index=26b value=0 +kvm_msr_entry_add: @28 index=26c value=0 +kvm_msr_entry_add: @29 index=26d value=0 +kvm_msr_entry_add: @30 index=26e value=0 +kvm_msr_entry_add: @31 index=26f value=0 +kvm_msr_entry_add: @32 index=200 value=0 +kvm_msr_entry_add: @33 index=201 value=0 +kvm_msr_entry_add: @34 index=202 value=0 +kvm_msr_entry_add: @35 index=203 value=0 +kvm_msr_entry_add: @36 index=204 value=0 +kvm_msr_entry_add: @37 index=205 value=0 +kvm_msr_entry_add: @38 index=206 value=0 +kvm_msr_entry_add: @39 index=207 value=0 +kvm_msr_entry_add: @40 index=208 value=0 +kvm_msr_entry_add: @41 index=209 value=0 +kvm_msr_entry_add: @42 index=20a value=0 +kvm_msr_entry_add: @43 index=20b value=0 +kvm_msr_entry_add: @44 index=20c value=0 +kvm_msr_entry_add: @45 index=20d value=0 +kvm_msr_entry_add: @46 index=20e value=0 +kvm_msr_entry_add: @47 index=20f value=0 +kvm_msr_entry_add: @48 index=17a value=0 +kvm_msr_entry_add: @49 index=17b value=ffffffffffffffff +kvm_msr_entry_add: @50 index=400 value=ffffffffffffffff +kvm_msr_entry_add: @51 index=401 value=0 +kvm_msr_entry_add: @52 index=402 value=0 +kvm_msr_entry_add: @53 index=403 value=0 +kvm_msr_entry_add: @54 index=404 value=ffffffffffffffff +kvm_msr_entry_add: @55 index=405 value=0 +kvm_msr_entry_add: @56 index=406 value=0 +kvm_msr_entry_add: @57 index=407 value=0 +kvm_msr_entry_add: @58 index=408 value=ffffffffffffffff +kvm_msr_entry_add: @59 index=409 value=0 +kvm_msr_entry_add: @60 index=40a value=0 +kvm_msr_entry_add: @61 index=40b value=0 +kvm_msr_entry_add: @62 index=40c value=ffffffffffffffff +kvm_msr_entry_add: @63 index=40d value=0 +kvm_msr_entry_add: @64 index=40e value=0 +kvm_msr_entry_add: @65 index=40f value=0 +kvm_msr_entry_add: @66 index=410 value=ffffffffffffffff +kvm_msr_entry_add: @67 index=411 value=0 +kvm_msr_entry_add: @68 index=412 value=0 +kvm_msr_entry_add: @69 index=413 value=0 +kvm_msr_entry_add: @70 index=414 value=ffffffffffffffff +kvm_msr_entry_add: @71 index=415 value=0 +kvm_msr_entry_add: @72 index=416 value=0 +kvm_msr_entry_add: @73 index=417 value=0 +kvm_msr_entry_add: @74 index=418 value=ffffffffffffffff +kvm_msr_entry_add: @75 index=419 value=0 +kvm_msr_entry_add: @76 index=41a value=0 +kvm_msr_entry_add: @77 index=41b value=0 +kvm_msr_entry_add: @78 index=41c value=ffffffffffffffff +kvm_msr_entry_add: @79 index=41d value=0 +kvm_msr_entry_add: @80 index=41e value=0 +kvm_msr_entry_add: @81 index=41f value=0 +kvm_msr_entry_add: @82 index=420 value=ffffffffffffffff +kvm_msr_entry_add: @83 index=421 value=0 +kvm_msr_entry_add: @84 index=422 value=0 +kvm_msr_entry_add: @85 index=423 value=0 +kvm_msr_entry_add: @86 index=424 value=ffffffffffffffff +kvm_msr_entry_add: @87 index=425 value=0 +kvm_msr_entry_add: @88 index=426 value=0 +kvm_msr_entry_add: @89 index=427 value=0 +kvm_put_msrs: ret=9 expected=90 +qemu-custom: /root/qemu/target/i386/kvm.c:1849: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +Aborted + +> Also, does the problem go away if you remove the +x2apic on the top level qemu? + +Don't think so, I actually added it because I thought it would solve something. I can re-try with out it if needed(with the debug messages). + + + + + + kvm_msr_entry_add: @8 index=9e value=30000 + kvm_msr_entry_add: @9 index=d90 value=0 + kvm_msr_entry_add: @10 index=c0000083 value=0 + + kvm_put_msrs: ret=9 expected=90 + +OK, 9... so that's probably the d90; + $ ag d90: + 418:#define MSR_IA32_BNDCFGS 0x00000d90 + +The Intel book says 'IA32_BNDCFGS Supervisor State of MPX Configuration' which I think is pretty new, so I don't know what it's doing trying to do it on a Westmere; ccing in Eduardo and Paolo. + + + > Also, does the problem go away if you remove the +x2apic on the top level qemu? + + Don't think so, I actually added it because I thought it would solve something + I can re-try with out it if needed(with the debug messages). + +Worth a go, but if it's that MPX stuff I doubt it. + +Dave + +Nested is currently supported only with -cpu host. Kernel 4.9 has the necessary support but QEMU doesn't. + +> Nested is currently supported only with -cpu host. Kernel 4.9 has the necessary support but QEMU doesn't. + +1. Just to be sure, you mean '-cpu host' in the bare metal host right? +2. Until it is officially supported in qemu, is there any easy way to work around this? as this setup seemed to have work in earlier versions(prior to v2.6.0 I think). + +Yes, I mean '-cpu host' in the bare metal. There is no workaround; it worked by chance and it triggered other hard to find bugs. + +> Yes, I mean '-cpu host' in the bare metal. There is no workaround; it worked by chance and it triggered other hard to find bugs. + +alright, thanks for clarifying that. + + +Can you still reproduce this issue with the latest version of QEMU (v4.2)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1686390 b/results/classifier/118/unknown/1686390 new file mode 100644 index 00000000..1eade15b --- /dev/null +++ b/results/classifier/118/unknown/1686390 @@ -0,0 +1,145 @@ +user-level: 0.848 +register: 0.819 +device: 0.800 +mistranslation: 0.799 +risc-v: 0.791 +peripherals: 0.785 +files: 0.776 +permissions: 0.772 +hypervisor: 0.769 +virtual: 0.762 +architecture: 0.759 +boot: 0.756 +graphic: 0.748 +TCG: 0.746 +ppc: 0.744 +vnc: 0.742 +arm: 0.742 +KVM: 0.740 +semantic: 0.740 +x86: 0.739 +assembly: 0.739 +debug: 0.736 +network: 0.729 +VMM: 0.726 +socket: 0.721 +performance: 0.717 +PID: 0.716 +i386: 0.688 +kernel: 0.668 + +vnc server closed socket after arrow "down" keyevent + +This is a rewrite for https://bugs.launchpad.net/qemu/+bug/1670377 + +QEMU 2.6 or later +tigervncviwer 1.6 + +Once get into grub boot interface(choose boot os, or recovery mode), keep pressing arrow down button for couple times, qemu will close the connection, vnc used zrle mode. + +Interesting place: +1. when stopped at grub interface, only arrow up and down key could trigger it, +2. only in zrle or tight mode, could work well in raw mode +2. it only triggered by remote connection, not happen if local vncviewer and vnc server + + +A trace is attached. + +Thanks + + + +Find the root reason: qio_channel_write is going to write 290124 data, but only wrote 238644, and for the next write 51489, it returned error, then trigger vnc_client_io_error and disconnect socket. + + +ssize_t vnc_client_write_buf(VncState *vs, const uint8_t *data, size_t datalen) +{ + Error *err = NULL; + ssize_t ret; + ret = qio_channel_write( + vs->ioc, (const char *)data, datalen, &err); + VNC_DEBUG("Wrote wire %p %zd -> %ld\n", data, datalen, ret); + return vnc_client_io_error(vs, ret, &err); +} + +// log file + + +Write Plain: Pending output 0x5579e6bd2c60 size 524288 offset 290124. Wait SSF 0 +32760@1493228975.268871:object_class_dynamic_cast_assert qio-channel-socket->qio-channel (io/channel.c:60:qio_channel_writev_full) +32760@1493228975.268876:object_dynamic_cast_assert qio-channel-socket->qio-channel-socket (io/channel-socket.c:508:qio_channel_socket_writev) +Wrote wire 0x5579e6bd2c60 290124 -> 290124 + + + +Write Plain: Pending output 0x5579e6bd2c60 size 524288 offset 290124. Wait SSF 0 +32760@1493228975.731842:object_class_dynamic_cast_assert qio-channel-socket->qio-channel (io/channel.c:60:qio_channel_writev_full) +32760@1493228975.731846:object_dynamic_cast_assert qio-channel-socket->qio-channel-socket (io/channel-socket.c:508:qio_channel_socket_writev) +Wrote wire 0x5579e6bd2c60 290124 -> 238644 +Write Plain: Pending output 0x5579e6bd2c60 size 65536 offset 51480. Wait SSF 0 +32760@1493228975.731934:object_class_dynamic_cast_assert qio-channel-socket->qio-channel (io/channel.c:60:qio_channel_writev_full) +32760@1493228975.731937:object_dynamic_cast_assert qio-channel-socket->qio-channel-socket (io/channel-socket.c:508:qio_channel_socket_writev) +Wrote wire 0x5579e6bd2c60 51480 -> -2 +vnc_set_share_mode/0x5579e7b6d730: shared -> disconnected + +> Wrote wire 0x5579e6bd2c60 51480 -> -2 + +That is QIO_CHANNEL_ERR_BLOCK, aka EAGAIN. + +This is fixed in the 2.9.0 release with + +commit 537848ee62195fc06c328b1cd64f4218f404a7f1 +Author: Michael Tokarev <email address hidden> +Date: Fri Feb 3 12:52:29 2017 +0300 + + vnc: do not disconnect on EAGAIN + + When qemu vnc server is trying to send large update to clients, + there might be a situation when system responds with something + like EAGAIN, indicating that there's no system memory to send + that much data (depending on the network speed, client and server + and what is happening). In this case, something like this happens + on qemu side (from strace): + + sendmsg(16, {msg_name(0)=NULL, + msg_iov(1)=[{"\244\"..., 729186}], + msg_controllen=0, msg_flags=0}, 0) = 103950 + sendmsg(16, {msg_name(0)=NULL, + msg_iov(1)=[{"lz\346"..., 1559618}], + msg_controllen=0, msg_flags=0}, 0) = -1 EAGAIN + sendmsg(-1, {msg_name(0)=NULL, + msg_iov(1)=[{"lz\346"..., 1559618}], + msg_controllen=0, msg_flags=0}, 0) = -1 EBADF + + qemu closes the socket before the retry, and obviously it gets EBADF + when trying to send to -1. + + This is because there WAS a special handling for EAGAIN, but now it doesn't + work anymore, after commit 04d2529da27db512dcbd5e99d0e26d333f16efcc, because + now in all error-like cases we initiate vnc disconnect. + + This change were introduced in qemu 2.6, and caused numerous grief for many + people, resulting in their vnc clients reporting sporadic random disconnects + from vnc server. + + Fix that by doing the disconnect only when necessary, i.e. omitting this + very case of EAGAIN. + + Hopefully the existing condition (comparing with QIO_CHANNEL_ERR_BLOCK) + is sufficient, as the original code (before the above commit) were + checking for other errno values too. + + Apparently there's another (semi?)bug exist somewhere here, since the + code tries to write to fd# -1, it probably should check if the connection + is open before. But this isn't important. + + Signed-off-by: Michael Tokarev <email address hidden> + Reviewed-by: Daniel P. Berrange <email address hidden> + Message-id: <email address hidden> + Fixes: 04d2529da27db512dcbd5e99d0e26d333f16efcc + Cc: Daniel P. Berrange <email address hidden> + Cc: Gerd Hoffmann <email address hidden> + Cc: <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + + diff --git a/results/classifier/118/unknown/1693649 b/results/classifier/118/unknown/1693649 new file mode 100644 index 00000000..a4c2094c --- /dev/null +++ b/results/classifier/118/unknown/1693649 @@ -0,0 +1,120 @@ +ppc: 0.956 +hypervisor: 0.939 +peripherals: 0.934 +x86: 0.929 +vnc: 0.915 +TCG: 0.906 +user-level: 0.906 +debug: 0.904 +permissions: 0.900 +performance: 0.889 +arm: 0.888 +VMM: 0.888 +risc-v: 0.886 +PID: 0.885 +KVM: 0.880 +assembly: 0.873 +device: 0.848 +semantic: 0.844 +mistranslation: 0.839 +graphic: 0.838 +register: 0.834 +kernel: 0.829 +architecture: 0.821 +boot: 0.821 +network: 0.808 +i386: 0.782 +socket: 0.772 +virtual: 0.771 +files: 0.761 + +x86 pause misbehaves with -cpu haswell + +Using qemu-2.9.0 + +When booting NetBSD using '-cpu haswell -smp 4', the system fails to initialize the additional CPUs. It appears as though the "application processor" enters routine x86_pause() but never returns. + +x86_pause() is simply two assembler instructions: 'pause; ret;' + +Replacing the routine with 'nop; nop; ret;' allows the system to proceed, of course without the benefit of the pause instruction on spin-loops! + +Additionally, booting with '-cpu phenom -smp 4' also works, although the system does seem confused about the type of CPU being used. + +Further investigation shows that pause may be working, but very very slowly. + +The "use-case" in NetBSD is for "hatching" application CPUs. The target CPU runs a loop that does + + while (flag_1 not set) + for (i = 0; i < 10000; i++) + x86_pause(); /* which is assembly code: "pause; ret;" */ + ... + set flag_2; + return; + +The boot CPU executes the following code for each application CPU: + + set flag_1; + for (i = 0; i < 100000 && flag_2 not set; i++) + i8254_delay(10); /* this should be 10usec per iteration, 1.0 sec total */ + if (flag_2 not set) + panic(cpu did not hatch); + .... + +So, the 10k executions of x86_pause are taking in excess of 1 sec to complete. Indeed, reducing that constant value from 10k to only 100 results in the same failure. So it would seem that the pause instruction is taking an extremely long time to complete. (Further reducing the interation count to only 50 results in success, although it "feels" very sluggish.) + + +Can you still reproduce this issue with the latest version of QEMU (currently 5.0)? + +Seems ok now. + +On Fri, 22 May 2020, Thomas Huth wrote: + +> Can you still reproduce this issue with the latest version of QEMU +> (currently 5.0)? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1693649 +> +> Title: +> x86 pause misbehaves with -cpu haswell +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Using qemu-2.9.0 +> +> When booting NetBSD using '-cpu haswell -smp 4', the system fails to +> initialize the additional CPUs. It appears as though the "application +> processor" enters routine x86_pause() but never returns. +> +> x86_pause() is simply two assembler instructions: 'pause; ret;' +> +> Replacing the routine with 'nop; nop; ret;' allows the system to +> proceed, of course without the benefit of the pause instruction on +> spin-loops! +> +> Additionally, booting with '-cpu phenom -smp 4' also works, although +> the system does seem confused about the type of CPU being used. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1693649/+subscriptions +> +> !DSPAM:5ec7625658281532840571! +> +> + ++--------------------+--------------------------+-----------------------+ +| Paul Goyette | PGP Key fingerprint: | E-mail addresses: | +| (Retired) | FA29 0E3B 35AF E8AE 6651 | <email address hidden> | +| Software Developer | 0786 F758 55DE 53BA 7731 | <email address hidden> | ++--------------------+--------------------------+-----------------------+ + + +Ok, thanks for checking again! So I'm closing this ticket now. + diff --git a/results/classifier/118/unknown/1701798 b/results/classifier/118/unknown/1701798 new file mode 100644 index 00000000..c15ff18b --- /dev/null +++ b/results/classifier/118/unknown/1701798 @@ -0,0 +1,453 @@ +architecture: 0.857 +permissions: 0.854 +performance: 0.843 +register: 0.831 +device: 0.831 +files: 0.827 +peripherals: 0.809 +virtual: 0.808 +user-level: 0.808 +arm: 0.796 +assembly: 0.793 +graphic: 0.793 +network: 0.792 +debug: 0.788 +socket: 0.781 +KVM: 0.776 +PID: 0.769 +VMM: 0.765 +boot: 0.755 +risc-v: 0.747 +vnc: 0.745 +hypervisor: 0.742 +semantic: 0.739 +kernel: 0.735 +i386: 0.733 +mistranslation: 0.715 +ppc: 0.703 +TCG: 0.699 +x86: 0.670 + +dynamically linked binaries crash for big-endian targets + +On the targets + hppa + m68k + mips + mips64 + powerpc + powerpc64 + s390x + sparc64 +dynamically linked binaries crash, but statically linked binaries work. +On the targets + aarch64 + alpha + armhf + powerpc64le + sh4 +both dynamically linked and statically linked binaries work. + +How to reproduce: + +1) On Ubuntu 16.04, install the packages +g++-5-aarch64-linux-gnu +g++-5-alpha-linux-gnu +g++-5-arm-linux-gnueabihf +g++-5-hppa-linux-gnu +g++-5-m68k-linux-gnu +g++-5-mips-linux-gnu +g++-5-mips64-linux-gnuabi64 +g++-5-powerpc-linux-gnu +g++-5-powerpc64-linux-gnu +g++-5-powerpc64le-linux-gnu +g++-5-s390x-linux-gnu +g++-5-sh4-linux-gnu +g++-5-sparc64-linux-gnu + +2) Install qemu 2.9.0 from source (for m68k, use the 2.7.0-m68k +code from https://github.com/vivier/qemu-m68k.git): +$ ../configure --prefix=/home/bruno/inst-qemu/2.9.0 --target-list=aarch64-softmmu,alpha-softmmu,arm-softmmu,i386-softmmu,m68k-softmmu,mips-softmmu,mipsel-softmmu,mips64-softmmu,mips64el-softmmu,ppc-softmmu,ppc64-softmmu,s390x-softmmu,sh4-softmmu,sparc-softmmu,sparc64-softmmu,x86_64-softmmu,aarch64-linux-user,alpha-linux-user,arm-linux-user,hppa-linux-user,m68k-linux-user,mips-linux-user,mipsel-linux-user,mips64-linux-user,mips64el-linux-user,ppc-linux-user,ppc64-linux-user,ppc64le-linux-user,s390x-linux-user,sh4-linux-user,sparc-linux-user,sparc64-linux-user --disable-strip --disable-werror --enable-gtk --enable-vnc +$ make +$ make install + +3) Cross-compile the programs: + +$ aarch64-linux-gnu-gcc-5 -O hello.c -o hello.aarch64 +$ alpha-linux-gnu-gcc-5 -O hello.c -o hello.alpha +$ arm-linux-gnueabihf-gcc-5 -O hello.c -o hello.armhf +$ hppa-linux-gnu-gcc-5 -O hello.c -o hello.hppa +$ m68k-linux-gnu-gcc-5 -O hello.c -o hello.m68k +$ mips-linux-gnu-gcc-5 -O hello.c -o hello.mips +$ mips64-linux-gnuabi64-gcc-5 -O hello.c -o hello.mips64 +$ powerpc-linux-gnu-gcc-5 -O hello.c -o hello.powerpc +$ powerpc64-linux-gnu-gcc-5 -O hello.c -o hello.powerpc64 +$ powerpc64le-linux-gnu-gcc-5 -O hello.c -o hello.powerpc64le +$ s390x-linux-gnu-gcc-5 -O hello.c -o hello.s390x +$ sh4-linux-gnu-gcc-5 -O hello.c -o hello.sh4 +$ sparc64-linux-gnu-gcc-5 -O hello.c -o hello.sparc64 + +4) Run the programs: + +* aarch64 works: +$ QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-aarch64 hello.aarch64 +Hello world + +* alpha works: +$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-alpha hello.alpha +Hello world + +* armhf works: +$ QEMU_LD_PREFIX=/usr/arm-linux-gnueabihf ~/inst-qemu/2.9.0/bin/qemu-arm hello.armhf +Hello world + +* powerpc64le works: +$ QEMU_LD_PREFIX=/usr/powerpc64le-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc64le hello.powerpc64le +Hello world + +* sh4 works: +$ QEMU_LD_PREFIX=/usr/sh4-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sh4 hello.sh4 +Hello world + +* ===== sparc64 does not work: +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sparc64 hello.sparc64 +Segmentation fault (core dumped) + +When I copy the file to a machine with `uname -srm` = "Linux 4.5.0-2-sparc64 sparc64", +it works: +$ ./hello.sparc64 +Hello world + +When I copy the file and its execution environment /usr/sparc64-linux-gnu to the +same machine and run the binary in a chroot environment: +# /bin/hello.sparc64 +Hello world + +* ===== mips does not work: +$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-mips hello.mips +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +When I copy the file to a machine with `uname -srm` = "Linux 3.16.0-4-4kc-malta mips", +it works: +$ ./hello.mips +Hello world + +When I copy the file and its execution environment /usr/mips-linux-gnu to the +same machine and run the binary in a chroot environment: +# /bin/hello.mips +Hello world + +* ===== mips64 does not work: +$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.9.0/bin/qemu-mips64 hello.mips64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +When I copy the file to a machine with `uname -srm` = "Linux 3.16.0-4-5kc-malta mips64", +it works: +$ ./hello.mips64 +Hello world + +* ===== powerpc does not work: +$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc hello.powerpc +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +When I copy the file to a machine with `uname -srm` = "Linux 3.17.2-200.fc20.ppc64p7 ppc64", +it works: +$ ./hello.powerpc +Hello world + +* ===== powerpc64 does not work: +$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc64 hello.powerpc64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +When I copy the file to a machine with `uname -srm` = "Linux 3.17.2-200.fc20.ppc64p7 ppc64", +it works: +$ ./hello.powerpc64 +Hello world + +* ===== s390x does not work: +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-s390x hello.s390x +<hangs> +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.8.1/bin/qemu-s390x hello.s390x +qemu-s390x: /media/develdata/devel/build/qemu-2.8.1/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +Segmentation fault (core dumped) + +When I copy the file to a machine with `uname -srm` = "Linux 3.16.0-4-s390x s390x", +it works: +$ ./hello.s390x +Hello world + +* ===== hppa does not work: +$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-hppa hello.hppa +Segmentation fault (core dumped) + +* ===== m68k does not work: +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.9.0/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.7.0-m68k/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + + +The set of targets where it does not work is exactly the big-endian targets. + +I would guess that the problem comes from a missing (or an extra) BSWAP call in one of the files + include/elf.h + include/hw/elf_ops.h + linux-user/elfload.c + + +I think I hit this problem trying to use qemu-s390x-static in the s390x/ubuntu:16.04 docker image. Running qemu-s390x-static 2.9.0 on binaries in that image (e.g. /bin/echo) results in a hang. + +I've noticed that doing the same in a s390x/debian:jessie image does NOT have the same problem. No hang. Looks like the binaries are built for different kernel versions, could that be why? + +$ file ubuntu16.04/bin/echo +ubuntu16.04/bin/echo: ELF 64-bit MSB shared object, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=4befa0df07957e117e8cc44d0dd14a3df6d44619, stripped + +$ file debian/bin/echo +debian/bin/echo: ELF 64-bit MSB executable, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 2.6.32, BuildID[sha1]=4bd45eb0ae5287ba9271a9daa9809166dd2eeab5, stripped + +The behaviour in qemu-2.10 is nearly the same as in qemu-2.9. The only difference is a different kind of crash for m68k: + +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.9.0/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10.0/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + + +Can you check whether these work if you copy the QEMU and the dynamically linked target binary into a chroot (which does not have the x86 host ld.so or /etc in it) instead of using QEMU_LD_PREFIX ? There is a problem I've seen before where: + 1) QEMU when run with QEMU_LD_PREFIX or -L works by "first try in -L, then try in the host filesystem" + 2) files like /etc/ld.so.cache (and other things the dynamic linker uses) are not in the -L directory but are in the host + 3) the ld.so.cache format is not endian-agnostic + 4) glibc's dynamic linker code does not ignore a wrong-endian ld.so.cache but crashes instead + +Using a chroot instead of QEMU_LD_PREFIX will work as a test of whether this is the kind of problem you're running into. Personally I think that (4) is a glibc bug... + + +For s390x, the hang definitely still occurs using a chroot with qemu-s390x-static copied in and no QEMU_LD_PREFIX. I'm not in a good position to test other big-endian architectures though. + +I just tested with powerpc and current head-of-git QEMU and it works: + +e104462:xenial:bug-1701798$ cat hello.c +#include <stdio.h> +int main(void) { + printf("hello world\n"); + return 0; +} +e104462:xenial:bug-1701798$ powerpc-linux-gnu-gcc-5 -O hello.c -o hello.powerpc +e104462:xenial:bug-1701798$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/linaro/qemu-from-laptop/qemu/build/all-linux-static/ppc-linux-user/qemu-ppc ./hello.powerpc +hello world + +Similarly mips, sparc64, powerpc64, hppa, mips64 are fine. + +m68k is known to be not working for real m68k currently (it's mostly a coldfire target), so not surprising that that doesn't work. + +s390x still crashes: +qemu-s390x: /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/translate-all.c:189: tb_lock: Assertion `!have_tb_lock' failed. + +So either we've fixed a bug here, or the problem is in your environment. + +For s390, it looks like the guest is trying to use an insn we don't implement: +#0 0x0000000060215018 in raise () +#1 0x000000006021573a in abort () +#2 0x0000000060079a96 in op_risbg (s=0x7fffffffda10, o=0x7fffffffd950) + at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:3450 +#3 0x0000000060082c8b in translate_one (env=0x627f0350, s=0x7fffffffda10) + at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:5824 +#4 0x0000000060082f3f in gen_intermediate_code (cs=0x627e80b0, + tb=0x60794d40 <static_code_gen_buffer+56064>) + at /home/petmay01/linaro/qemu-from-laptop/qemu/target/s390x/translate.c:5925 +#5 0x00000000600369aa in tb_gen_code (cpu=0x627e80b0, pc=274886359240, + cs_base=0, flags=3, cflags=0) + at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/translate-all.c:1286 +#6 0x00000000600343ff in tb_find (cpu=0x627e80b0, + last_tb=0x60794c00 <static_code_gen_buffer+55744>, tb_exit=0, cf_mask=0) + at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:402 +#7 0x0000000060034b36 in cpu_exec (cpu=0x627e80b0) + at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:722 +#8 0x000000006003ac78 in cpu_loop (env=0x627f0350) + at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/main.c:3255 +---Type <return> to continue, or q <return> to quit--- +#9 0x000000006003c68c in main (argc=2, argv=0x7fffffffe458, envp=0x7fffffffe470) + at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/main.c:4882 + +where the abort is in op_risbg() because s->fields->op2 is 0x59, which we don't handle. + +We then fail to correctly report that abort(), because linux-user has never been very good with reporting signals caused by QEMU itself -- it assumes signals including SIGABRT are due to the guest code and tries to deliver them as guest signals, usually tripping itself up in the process. We then run into the bug described in https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg01506.html which is why we get the have_tb_lock assertion. + + + +This patch fixes the s390 issue: +https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01103.html + +which is the only part of this (ignoring m68k) that I could reproduce. Bruno: can you still reproduce any of the other problems with a new QEMU? + + +> can you still reproduce any of the other problems with a new QEMU? + +On the same system (Ubuntu 16.04 x86_64, not a chroot environment), I still observe the same symptoms with QEMU as of today than with 2.9.0 or 2.10.0: + +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-sparc64 hello.sparc64 +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-sparc64 hello.sparc64 +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-mips hello.mips +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-mips hello.mips +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.9.0/bin/qemu-mips64 hello.mips64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.10+-20171107/bin/qemu-mips64 hello.mips64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc hello.powerpc +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc hello.powerpc +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-ppc64 hello.powerpc64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc64 hello.powerpc64 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-s390x hello.s390x +Killed +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-s390x hello.s390x +Killed + +$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-hppa hello.hppa +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-hppa hello.hppa +Segmentation fault (core dumped) + +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10.0/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10+-20171107/bin/qemu-m68k hello.m68k +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + + +Re #4: +> 2) files like /etc/ld.so.cache (and other things the dynamic linker uses) are not in the -L directory but are in the host +> 3) the ld.so.cache format is not endian-agnostic +> 4) glibc's dynamic linker code does not ignore a wrong-endian ld.so.cache but crashes instead + +Indeed the problem is with /etc/ld.so.cache, and ONLY /etc/ld.so.cache. When I hack the do_openat function in linux-user/syscall.c, to pretend that no /etc/ld.so.cache exists, - see attached hide-ld.so.cache.diff - the dynamically-linked binaries work (except the s390x case, which you identified as a different issue): + +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-sparc64 hello.sparc64 +Hello world +$ QEMU_LD_PREFIX=/usr/mips-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-mips hello.mips +Hello world +$ QEMU_LD_PREFIX=/usr/mips64-linux-gnuabi64 ~/inst-qemu/2.10+-20171107/bin/qemu-mips64 hello.mips64 +Hello world +$ QEMU_LD_PREFIX=/usr/powerpc-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc hello.powerpc +Hello world +$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-ppc64 hello.powerpc64 +Hello world +$ QEMU_LD_PREFIX=/usr/s390x-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-s390x hello.s390x +Killed +$ QEMU_LD_PREFIX=/usr/hppa-linux-gnu ~/inst-qemu/2.10+-20171107/bin/qemu-hppa hello.hppa +Hello world +$ QEMU_LD_PREFIX=/usr/m68k-linux-gnu QEMU_CPU=m68020 ~/inst-qemu/2.10+-20171107/bin/qemu-m68k hello.m68k +Hello world + +Hurray! This bug that has seriously limited the value of linux-user emulation is now gone for me! + +> Can you check whether these work if you copy the QEMU and the dynamically linked target binary into a chroot + +This is way too cumbersome for me: + - Need to copy my workspaces into specific file locations on the disk, + - Need to use 'chroot' command before anything else, + - Need to use a statically-linked qemu. + +> Personally I think that (4) is a glibc bug... + +Maybe, but if you can fix it in 5 to 10 lines code in qemu, I doubt it's worth reporting it to the glibc people. + +Small improvement: In my hack, I just pretended /etc/ld.so.cache is absent. Possibly it's better to map it to $QEMU_LD_PREFIX/etc/ld.so.cache . + +That patch would prevent us from picking up a legitimate ld.so.cache for the guest (in a chroot, for instance), so I don't think we should take it. (I'm also not a fan of trying to work around specific guest code issues: I'd much rather this was just fixed in ld.so where it ought to be, so I'd encourage you to report it to the glibc folks.) + +You can probably also work around this by creating an empty ld.so.cache in the QEMU_LD_PREFIX directory, though it's awkward if you wanted that to be the /usr/whatever directory. + +The underlying problem here is that the -L option is not really a very good one compared to a proper chroot -- it doesn't really present a proper guest filesystem to the guest. + + +> That patch would prevent us from picking up a legitimate ld.so.cache for the guest (in a chroot, for instance), so I don't think we should take it. +But in a chroot, QEMU_LD_PREFIX is most likely NOT set. So how about this pseudocode? + + if (strcmp (pathname, "/etc/ld.so.cache") == 0 && getenv ("QEMU_LD_PREFIX") != NULL) { + pathname = concat (getenv ("QEMU_LD_PREFIX"), pathname); + } + +That is, redirect /etc/ld.so.cache to $QEMU_LD_PREFIX/etc/ld.so.cache if and only if $QEMU_LD_PREFIX is set. + +> You can probably also work around this by creating an empty ld.so.cache in the QEMU_LD_PREFIX directory, though it's awkward if you wanted that to be the /usr/whatever directory. + +Indeed, qemu already analyzes the QEMU_LD_PREFIX, stores a cache of its contents in the static variable 'base', and uses it in the do_openat() function. + +The following provides a workaround for me that does not require any change to qemu: + +sudo mkdir -p $QEMU_LD_PREFIX/etc +sudo ln -s /nonexistent $QEMU_LD_PREFIX/etc/ld.so.cache + + +I still feel we shouldn't be working around guest code bugs in QEMU, so I'm not sure there's anything more for QEMU to do here. You should report the dynamic linker bug to glibc upstream. + + +My feeling is that glibc upstream will not want to care about cross qemu situations. I would prefer to report it to the Ubuntu cross-tools maintainers: The package libc6-<cpu>-cross contains the file /usr/<cpu>-linux-gnu/lib/libc.so.6; they could surely add the symlink for /usr/<cpu>-linux-gnu/etc/ld.so.cache as well. + +I believe this same bug affects me on Linux Mint 18.3 Sylvia which is based on Ubuntu Xenial. +The suggestion from #12 helped me. Thank you @bruno-clisp! + +Did we open a precise glibc upstream bug for this so I can go upvote it? :-) + +Workaround from #12 also worked for me. + +Tested on Buildroot with this precise setup: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/e855a262fd872171156894e9045814cb0f346dab#stack-smashing-detected + +For Google, the error message in that setup is: + +*** stack smashing detected ***: <unknown> terminated +qemu: uncaught target signal 6 (Aborted) - core dumped + +but must be the same as reported here just with a different glibc setup leading to slightly different crash. + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +The issue seems to be fixed, even without the symlink for /usr/<cpu>-linux-gnu/etc/ld.so.cache. +For m68k: since version 2.10.0. +For s390x: since version 2.11.0. +For the other platforms, already since 2.9.0 (strange, this contradicts my original report...). + +My last comment ("The issue seems to be fixed, even without the symlink for /usr/<cpu>-linux-gnu/etc/ld.so.cache.") was incorrect. When this symlink is set, the program accesses /etc/ld.so.cache after accessing /usr/<cpu>-linux-gnu/etc/ld.so.cache. In some cases, it works, in some cases it doesn't — depending on the contents of /etc/ld.so.cache. + +The better fix is to replace /usr/<cpu>-linux-gnu/etc/ld.so.cache with an empty file: + +rm -f "/usr/<cpu>-linux-gnu/etc/ld.so.cache" +mkdir -p "/usr/<cpu>-linux-gnu/etc" +: > "/usr/<cpu>-linux-gnu/etc/ld.so.cache" + + diff --git a/results/classifier/118/unknown/1704 b/results/classifier/118/unknown/1704 new file mode 100644 index 00000000..669d5cf1 --- /dev/null +++ b/results/classifier/118/unknown/1704 @@ -0,0 +1,99 @@ +risc-v: 0.805 +virtual: 0.799 +VMM: 0.796 +user-level: 0.791 +performance: 0.765 +boot: 0.760 +KVM: 0.760 +TCG: 0.759 +hypervisor: 0.755 +vnc: 0.754 +device: 0.752 +register: 0.751 +i386: 0.749 +ppc: 0.744 +debug: 0.741 +architecture: 0.738 +x86: 0.736 +permissions: 0.732 +peripherals: 0.728 +graphic: 0.726 +PID: 0.722 +semantic: 0.716 +assembly: 0.714 +arm: 0.713 +files: 0.712 +kernel: 0.711 +socket: 0.687 +network: 0.645 +mistranslation: 0.626 + +Booting arm64 Linux in TCG mode fails with "ERROR:../tcg/tcg.c:4317:temp_load: code should not be reached" +Description of problem: +Linux seems to boot successfully, but around loading/executing userspace, QEMU crashes with an error: + +``` +[ 4.047919] EXT4-fs (vda): mounted filesystem 59b147ee-5613-43a2-aab4-eaceb6e95be5 with ordered data mode. Quota mode: none. +[ 4.049630] VFS: Mounted root (ext4 filesystem) on device 254:0. +[ 4.055437] devtmpfs: mounted +[ 4.160039] Freeing unused kernel memory: 8256K +[ 4.161855] Run /sbin/init as init process +[ 4.547387] EXT4-fs (vda): re-mounted 59b147ee-5613-43a2-aab4-eaceb6e95be5. Quota mode: none. +** +ERROR:../tcg/tcg.c:4317:temp_load: code should not be reached +Bail out! ERROR:../tcg/tcg.c:4317:temp_load: code should not be reached +zsh: abort /home/mark/.opt/apps/qemu-v8.0.0-1645-ge6dd5e782b/bin/qemu-system-aarch64 -sm +``` +Steps to reproduce: +1. Run the provided qemu commandline +2. Wait for QEMU to crash +Additional information: +I attempted a bisect, which suggests that the first bad commit is: + +``` +[e6dd5e782becfe6d51f3575c086f5bd7162421d0] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r +``` + +The full bisect log is: + +``` +[mark@lakrids:~/src/qemu]% git bisect log +git bisect start +# good: [f7f686b61cf7ee142c9264d2e04ac2c6a96d37f8] Update version for 8.0.2 release +git bisect good f7f686b61cf7ee142c9264d2e04ac2c6a96d37f8 +# bad: [5f9dd6a8ce3961db4ce47411ed2097ad88bdf5fc] Merge tag 'pull-9p-20230608' of https://github.com/cschoenebeck/qemu into staging +git bisect bad 5f9dd6a8ce3961db4ce47411ed2097ad88bdf5fc +# good: [c1eb2ddf0f8075faddc5f7c3d39feae3e8e9d6b4] Update version for v8.0.0 release +git bisect good c1eb2ddf0f8075faddc5f7c3d39feae3e8e9d6b4 +# good: [1a42d9d472b61e4db2fb16800495d402cb9b94af] tcg/sparc64: Split out tcg_out_movi_s32 +git bisect good 1a42d9d472b61e4db2fb16800495d402cb9b94af +# good: [a30498fcea5a8b9c544324ccfb0186090104b229] tcg/riscv: Support CTZ, CLZ from Zbb +git bisect good a30498fcea5a8b9c544324ccfb0186090104b229 +# good: [759573d05b808344f7047f893d2dd095884dfa4d] test-cutils: Add coverage of qemu_strtod +git bisect good 759573d05b808344f7047f893d2dd095884dfa4d +# good: [dc2a070d125772fe30384596d4d4ce6d9950b004] hw/arm/allwinner-r40: add Clock Control Unit +git bisect good dc2a070d125772fe30384596d4d4ce6d9950b004 +# good: [c0dde5fc5ccce56b69095bc29af72987efd65d1e] accel/tcg: Fix undefined shift in store_whole_le16 +git bisect good c0dde5fc5ccce56b69095bc29af72987efd65d1e +# bad: [e58e55dd8d5777f8a58ce30cfe04a8023282eb80] meson: fix "static build" entry in summary +git bisect bad e58e55dd8d5777f8a58ce30cfe04a8023282eb80 +# bad: [5c13983e23de4095e2dfa8bc52333ef40ebe40db] target/arm: Sink gen_mte_check1 into load/store_exclusive +git bisect bad 5c13983e23de4095e2dfa8bc52333ef40ebe40db +# good: [6c4f229a2e0d6f882bae389ce0c5bdaea712ce0f] tests: avocado: boot_linux_console: Add test case for bpim2u +git bisect good 6c4f229a2e0d6f882bae389ce0c5bdaea712ce0f +# good: [e452ca5af88fc49b3026c2de0f1e65fd18d1a656] target/arm: Introduce finalize_memop_{atom,pair} +git bisect good e452ca5af88fc49b3026c2de0f1e65fd18d1a656 +# good: [d450bd0157be43d273116c3e3617883c8a0ac3d1] target/arm: Use tcg_gen_qemu_{st, ld}_i128 for do_fp_{st, ld} +git bisect good d450bd0157be43d273116c3e3617883c8a0ac3d1 +# bad: [e6dd5e782becfe6d51f3575c086f5bd7162421d0] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r +git bisect bad e6dd5e782becfe6d51f3575c086f5bd7162421d0 +# good: [e6073d88cc1fb43b00be16f79d9d6b0f9d2276f5] target/arm: Use tcg_gen_qemu_st_i128 for STZG, STZ2G +git bisect good e6073d88cc1fb43b00be16f79d9d6b0f9d2276f5 +# first bad commit: [e6dd5e782becfe6d51f3575c086f5bd7162421d0] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r +``` + +Each build step was performed with: + +``` + git clean -fdx && ./configure --prefix=/home/mark/.opt/apps/qemu-$(git describe --long HEAD) --enable-debug-info --disable-strip && make -j64 && make install +``` diff --git a/results/classifier/118/unknown/1715162 b/results/classifier/118/unknown/1715162 new file mode 100644 index 00000000..2ed871d1 --- /dev/null +++ b/results/classifier/118/unknown/1715162 @@ -0,0 +1,107 @@ +TCG: 0.903 +graphic: 0.898 +hypervisor: 0.897 +peripherals: 0.891 +KVM: 0.889 +debug: 0.888 +ppc: 0.884 +performance: 0.874 +virtual: 0.866 +x86: 0.854 +permissions: 0.851 +assembly: 0.851 +arm: 0.851 +semantic: 0.845 +architecture: 0.839 +device: 0.838 +register: 0.837 +vnc: 0.833 +PID: 0.821 +VMM: 0.818 +files: 0.806 +boot: 0.800 +mistranslation: 0.793 +i386: 0.781 +socket: 0.781 +network: 0.773 +kernel: 0.767 +user-level: 0.764 +risc-v: 0.717 + +qemu-user crashing when writing core dump + +I've a binary I'm running in qemux86-64 but it is segfaulting. Whilst qemu writes the core dump for that, qemu itself is segfaulting. + +(gdb) bt full +#0 0x00007efdd962e32e in sigsuspend () from /data/poky-tmp/master/build/sysroots-uninative/x86_64-linux/lib/libc.so.6 +No symbol table info available. +#1 0x0000559176d74da4 in dump_core_and_abort (target_sig=target_sig@entry=11) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:598 + cpu = <optimized out> + env = <optimized out> + ts = 0x55917a42d160 + core_dumped = <optimized out> + act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {18446744067267099647, + 18446744073709551615 <repeats 15 times>}}, sa_flags = 0, sa_restorer = 0x559100004010} +#2 0x0000559176d75a38 in handle_pending_signal (cpu_env=cpu_env@entry=0x55917a41c2a0, sig=sig@entry=11, + k=k@entry=0x55917a42d190) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6596 + handler = <optimized out> + set = {__val = {4294967297, 4294967297, 94083256460867, 14, 128, 0, 8, 3, 0, 1, 0, 4243635, 139628765215104, + 94083255852784, 94083309703424, 3351315493}} + target_old_set = {sig = {0}} + sa = <optimized out> + ts = 0x55917a42d160 +#3 0x0000559176d765ac in process_pending_signals (cpu_env=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6674 + sig = 11 + ts = 0x55917a42d160 + set = {__val = {18446744067267100671, 18446744073709551615 <repeats 15 times>}} + blocked_set = <optimized out> +#4 0x0000559176d5e0d8 in cpu_loop (env=0x55917a41c2a0) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:369 + trapnr = 14 + pc = <optimized out> + ret = <optimized out> + info = {si_signo = 11, si_errno = 0, si_code = 196609, _sifields = {_pad = {101897450, 192, -647518572, 32509, + 842, 0, 1993519912, 21905, 2051194736, 21905, 1997320506, 21905, 2051195440, 21905, 1993546713, 0, + 12767276, 64, 1997233696, 21905, 42, 0, 1997233824, 21905, 1997320464, 21905, 350755584, -1438022877}, + _kill = {_pid = 101897450, _uid = 192}, _timer = {_timer1 = 101897450, _timer2 = 192}, _rt = { + _pid = 101897450, _uid = 192, _sigval = {sival_int = -647518572, sival_ptr = 139628739274388}}, + _sigchld = {_pid = 101897450, _uid = 192, _status = -647518572, _utime = 842, _stime = 94083252138792}, + _sigfault = {_addr = 824735618282}, _sigpoll = {_band = 101897450, _fd = 192}}} +#5 0x0000559176d2a4b8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:4862 + regs1 = {r15 = 0, r14 = 0, r13 = 0, r12 = 0, rbp = 0, rbx = 0, r11 = 0, r10 = 0, r9 = 0, r8 = 0, rax = 0, + rcx = 0, rdx = 0, rsi = 0, rdi = 0, orig_rax = 0, rip = 274888416832, cs = 0, eflags = 0, + rsp = 274888401360, ss = 0} + regs = 0x7ffda5b29fc0 + info1 = {load_bias = 274888413184, load_addr = 274877906944, start_code = 274877906944, + end_code = 274877917360, start_data = 274880015120, end_data = 274880016400, start_brk = 0, + brk = 274880016472, start_mmap = 183251939328, start_stack = 274888401360, stack_limit = 274880024576, + entry = 274888416832, code_offset = 0, data_offset = 0, saved_auxv = 274888402256, + auxv_len = 18446744073709550728, arg_start = 274888401368, arg_end = 274888401408, + arg_strings = 274888402550, env_strings = 274888402788, file_string = 274888413067, elf_flags = 0, + personality = 0} + info = 0x7ffda5b2a070 + bprm = { + buf = "\177ELF\002\001\001\000\000\000\000\000\000\000\000\000\003\000>\000\001\000\000\000@\016\000\000\000\000\000\000@\000\000\000\000\000\000\000\230`\002\000\000\000\000\000\000\000\000\000@\000\070\000\006\000@\000\027\000\026\000\001\000\000\000\005", '\000' <repeats 27 times>, "\264C\002\000\000\000\000\000\264C\002\000\000\000\000\000\000\000 \000\000\000\000\000\001\000\000\000\006\000\000\000\240G\002\000\000\000\000\000\240G\"\000\000\000\000\000\240G\"\000\000\000\000\000\330\027\000\000\000\000\000\000p\031\000\000\000\000\000\000\000\000 \000\000\000\000\000\002\000\000\000\006\000\000\000\030N\002\000\000\000\000\000\030N\"\000\000\000\000\000"..., p = 274888401360, fd = 3, + e_uid = 1000, e_gid = 1000, argc = 5, envc = 104, argv = 0x55917a42d120, envp = 0x55917a42a8f0, + filename = 0x7ffda5b2c683 "/data/poky-tmp/master/build/work/intel_corei7_64-poky-linux/core-image-weston/1.0-r0/rootfs/usr/bin/fc-cache", core_dump = 0x559176d76ed0 <elf_core_dump>} + ts = <optimized out> + env = 0x55917a41c2a0 + cpu = 0x55917a414010 + target_environ = 0x55917a42a8f0 + wrk = 0x55917a42ac30 + target_argv = 0x55917a42d120 + target_argc = 5 + i = <optimized out> + ret = <optimized out> + execfd = <optimized out> + +(I'll reproduce this with glibc debug symbols shortly) + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1718118 b/results/classifier/118/unknown/1718118 new file mode 100644 index 00000000..cb9ce8e5 --- /dev/null +++ b/results/classifier/118/unknown/1718118 @@ -0,0 +1,91 @@ +user-level: 0.868 +debug: 0.867 +files: 0.864 +device: 0.855 +register: 0.852 +graphic: 0.851 +permissions: 0.843 +TCG: 0.840 +boot: 0.838 +peripherals: 0.838 +kernel: 0.838 +mistranslation: 0.837 +PID: 0.836 +socket: 0.836 +performance: 0.835 +network: 0.835 +assembly: 0.834 +ppc: 0.834 +architecture: 0.834 +arm: 0.833 +KVM: 0.831 +virtual: 0.827 +hypervisor: 0.822 +vnc: 0.820 +risc-v: 0.817 +semantic: 0.807 +VMM: 0.803 +i386: 0.799 +x86: 0.780 + +qemu crashes with hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) + +Qemu crashes with error "hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev)" when memory hotplug and hotunplug was done continuously. + +Steps to re-produce: +1. git clone (today's i.e 19th Sept) +2. Bring up ppc64le guest with memory hotplug capabilities ( I used libvirt xml to do this). +3. And do continuous memory hotplug and unplug using the following memory xml (mem_hp_8g.xml) +<memory model='dimm'> +<target> +<size unit='KiB'>8388608</size> +<node>1</node> +</target> +</memory> +4. Run the following +for i in `seq 1 100`; do virsh attach-device nrs mem_hp_8g.xml --live; virsh detach-device nrs mem_hp_8g.xml --live; done +5. Guest will crash +6. Following is from qemu log + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-ppc64 -name guest=nrs,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-19-nrs/master-key.aes -machine pseries-2.10,accel=kvm,usb=off,dump-guest-core=off -m size=8388608k,slots=256,maxmem=419430400k -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -numa node,nodeid=0,cpus=0-1,mem=4096 -numa node,nodeid=1,cpus=2-3,mem=4096 -uuid d7987973-2467-43ff-b8d2-acefc6ac59e5 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-19-nrs/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/home/nasastry/pegas-1.0-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:89:8a:8b,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -s -msg timestamp=on +2017-09-19 06:59:07.878+0000: Domain id=19 is tainted: custom-argv +2017-09-19T06:59:07.918273Z qemu-system-ppc64: -chardev pty,id=charserial0: char device redirected to /dev/pts/5 (label charserial0) +** +ERROR:/home/nasastry/qemu/hw/ppc/spapr_drc.c:417:spapr_drc_detach: assertion failed: (drc->dev) +2017-09-19 06:59:51.428+0000: shutting down, reason=crashed + +(gdb) bt +#0 0x00003fffb24beff0 in raise () at /lib64/libc.so.6 +#1 0x00003fffb24c136c in abort () at /lib64/libc.so.6 +#2 0x00003fffb2bcaa04 in g_assertion_message () at /lib64/libglib-2.0.so.0 +#3 0x00003fffb2bcab0c in g_assertion_message_expr () at /lib64/libglib-2.0.so.0 +#4 0x00000000101b85a0 in spapr_drc_detach (drc=0x2fc31220) at /home/nasastry/qemu/hw/ppc/spapr_drc.c:417 +#5 0x00000000101972e0 in spapr_memory_unplug_request (hotplug_dev=0x2faa60b0, dev=0x2fb8fb10, errp=0x3fffe92bfa90) at /home/nasastry/qemu/hw/ppc/spapr.c:3084 +#6 0x000000001019856c in spapr_machine_device_unplug_request (hotplug_dev=0x2faa60b0, dev=0x2fb8fb10, errp=0x3fffe92bfa90) + at /home/nasastry/qemu/hw/ppc/spapr.c:3354 +#7 0x00000000104461a8 in hotplug_handler_unplug_request (plug_handler=0x2faa60b0, plugged_dev=0x2fb8fb10, errp=0x3fffe92bfa90) at hw/core/hotplug.c:45 +#8 0x000000001036e15c in qdev_unplug (dev=0x2fb8fb10, errp=0x3fffe92bfa90) at qdev-monitor.c:878 +#9 0x000000001036e1e4 in qmp_device_del (id=0x2fab2880 "dimm0", errp=0x3fffe92bfa90) at qdev-monitor.c:888 +#10 0x000000001038975c in qmp_marshal_device_del (args=0x30658db0, ret=0x3fffe92bfb50, errp=0x3fffe92bfb48) at qmp-marshal.c:1462 +#11 0x000000001081fd98 in do_qmp_dispatch (cmds=0x10c0e078 <qmp_commands>, request=0x3093ebf0, errp=0x3fffe92bfbc0) at qapi/qmp-dispatch.c:104 +#12 0x000000001081ff84 in qmp_dispatch (cmds=0x10c0e078 <qmp_commands>, request=0x3093ebf0) at qapi/qmp-dispatch.c:131 +#13 0x00000000100983dc in handle_qmp_command (parser=0x2fae1e80, tokens=0x2faa44e0) at /home/nasastry/qemu/monitor.c:3852 +#14 0x000000001082aef0 in json_message_process_token (lexer=0x2fae1e88, input=0x2faa2420, type=JSON_RCURLY, x=70, y=374) at qobject/json-streamer.c:105 +#15 0x000000001086d5d0 in json_lexer_feed_char (lexer=0x2fae1e88, ch=125 '}', flush=false) at qobject/json-lexer.c:323 +#16 0x000000001086d7c4 in json_lexer_feed (lexer=0x2fae1e88, buffer=0x3fffe92bff88 "}", size=1) at qobject/json-lexer.c:373 +#17 0x000000001082b004 in json_message_parser_feed (parser=0x2fae1e80, buffer=0x3fffe92bff88 "}", size=1) at qobject/json-streamer.c:124 +#18 0x000000001009863c in monitor_qmp_read (opaque=0x2fae1df0, buf=0x3fffe92bff88 "}", size=1) at /home/nasastry/qemu/monitor.c:3894 +#19 0x000000001078e3c8 in qemu_chr_be_write_impl (s=0x2fab36b0, buf=0x3fffe92bff88 "}", len=1) at chardev/char.c:167 +#20 0x000000001078e484 in qemu_chr_be_write (s=0x2fab36b0, buf=0x3fffe92bff88 "}", len=1) at chardev/char.c:179 +#21 0x000000001079a910 in tcp_chr_read (chan=0x2fbfbbc0, cond=G_IO_IN, opaque=0x2fab36b0) at chardev/char-socket.c:441 +#22 0x00000000107be3d4 in qio_channel_fd_source_dispatch (source=0x2fab4770, callback=0x1079a760 <tcp_chr_read>, user_data=0x2fab36b0) at io/channel-watch.c:84 +#23 0x00003fffb2b93ab0 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 +#24 0x0000000010837e9c in glib_pollfds_poll () at util/main-loop.c:213 +#25 0x0000000010838064 in os_host_main_loop_wait (timeout=-1) at util/main-loop.c:261 +#26 0x000000001083818c in main_loop_wait (nonblocking=0) at util/main-loop.c:515 +#27 0x00000000103771c4 in main_loop () at vl.c:1999 +#28 0x0000000010381828 in main (argc=54, argv=0x3fffe92c1988, envp=0x3fffe92c1b40) at vl.c:4877 + +Fix has been released with QEMU 2.11: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2a129767ebb13ffc29dad + diff --git a/results/classifier/118/unknown/1719282 b/results/classifier/118/unknown/1719282 new file mode 100644 index 00000000..813bb08c --- /dev/null +++ b/results/classifier/118/unknown/1719282 @@ -0,0 +1,161 @@ +graphic: 0.866 +peripherals: 0.855 +register: 0.847 +architecture: 0.834 +PID: 0.828 +performance: 0.823 +device: 0.818 +ppc: 0.815 +assembly: 0.813 +virtual: 0.809 +permissions: 0.798 +i386: 0.793 +arm: 0.782 +vnc: 0.781 +semantic: 0.773 +hypervisor: 0.764 +socket: 0.764 +debug: 0.763 +boot: 0.757 +risc-v: 0.751 +x86: 0.740 +network: 0.729 +user-level: 0.718 +mistranslation: 0.718 +TCG: 0.712 +KVM: 0.708 +VMM: 0.698 +files: 0.697 +kernel: 0.692 + +Unable to boot after drive-mirror + +Hi, +I am using "drive-mirror" qmp block-job command to transfer VM disk image to other path (different physical disk on host). +Unfortunately after shutting down and starting from new image, VM is unable to boot and qrub enters rescue mode displaying following error: +``` +error: file '/grub/i386-pc/normal.mod' not found. +Entering rescue mode... +grub rescue> +``` + +To investigate the problem, I compared both RAW images using linux "cmp -l" command and found out that they differ in 569028 bytes starting from address 185598977 to 252708864 which are located on /boot partition. + +So I mounted /boot partition of mirrored RAW image on host OS and it seems that file-system is broken and grub folder is not recognized. But /boot on original RAW image has no problem. + +Mirrored Image: +ls -l /mnt/vm-boot/ +ls: cannot access /mnt/vm-boot/grub: Structure needs cleaning +total 38168 +-rw-r--r-- 1 root root 157721 Oct 19 2016 config-3.16.0-4-amd64 +-rw-r--r-- 1 root root 129281 Sep 20 2015 config-3.2.0-4-amd64 +d????????? ? ? ? ? ? grub +-rw-r--r-- 1 root root 15739360 Nov 2 2016 initrd.img-3.16.0-4-amd64 +-rw-r--r-- 1 root root 12115412 Oct 10 2015 initrd.img-3.2.0-4-amd64 +drwxr-xr-x 2 root root 12288 Oct 7 2013 lost+found +-rw-r--r-- 1 root root 2679264 Oct 19 2016 System.map-3.16.0-4-amd64 +-rw-r--r-- 1 root root 2114662 Sep 20 2015 System.map-3.2.0-4-amd64 +-rw-r--r-- 1 root root 3126448 Oct 19 2016 vmlinuz-3.16.0-4-amd64 +-rw-r--r-- 1 root root 2842592 Sep 20 2015 vmlinuz-3.2.0-4-amd64 + +Original Image: +ls /mnt/vm-boot/ -l +total 38173 +-rw-r--r-- 1 root root 157721 Oct 19 2016 config-3.16.0-4-amd64 +-rw-r--r-- 1 root root 129281 Sep 20 2015 config-3.2.0-4-amd64 +drwxr-xr-x 5 root root 5120 Nov 2 2016 grub +-rw-r--r-- 1 root root 15739360 Nov 2 2016 initrd.img-3.16.0-4-amd64 +-rw-r--r-- 1 root root 12115412 Oct 10 2015 initrd.img-3.2.0-4-amd64 +drwxr-xr-x 2 root root 12288 Oct 7 2013 lost+found +-rw-r--r-- 1 root root 2679264 Oct 19 2016 System.map-3.16.0-4-amd64 +-rw-r--r-- 1 root root 2114662 Sep 20 2015 System.map-3.2.0-4-amd64 +-rw-r--r-- 1 root root 3126448 Oct 19 2016 vmlinuz-3.16.0-4-amd64 +-rw-r--r-- 1 root root 2842592 Sep 20 2015 vmlinuz-3.2.0-4-amd64 + +ls /mnt/vm-boot/grub/ -l +total 2376 +-rw-r--r-- 1 root root 48 Oct 7 2013 device.map +drwxr-xr-x 2 root root 1024 Oct 10 2015 fonts +-r--r--r-- 1 root root 9432 Nov 2 2016 grub.cfg +-rw-r--r-- 1 root root 1024 Oct 7 2013 grubenv +drwxr-xr-x 2 root root 6144 Aug 6 2016 i386-pc +drwxr-xr-x 2 root root 1024 Aug 6 2016 locale +-rw-r--r-- 1 root root 2400500 Aug 6 2016 unicode.pf2 + +qemu Version: 2.7.0-10 + +Host OS: Debian 8x64 +Guest OS: Debian 8x64 + +QMP Commands log: +socat UNIX-CONNECT:/var/run/qemu-server/48016.qmp STDIO +{"QMP": {"version": {"qemu": {"micro": 0, "minor": 7, "major": 2}, "package": "pve-qemu-kvm_2.7.0-10"}, "capabilities": []}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "drive-mirror", + "arguments": { + "device": "drive-ide0", + "target": "/diskc/48016/vm-48016-disk-2.raw", + "sync": "full", + "mode": "absolute-paths", + "speed": 0 + } +} +{"return": {}} +{"timestamp": {"seconds": 1506331591, "microseconds": 623095}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-ide0", "len": 269445758976, "offset": 269445758976, "speed": 0, "type": "mirror"}} +{"timestamp": {"seconds": 1506332641, "microseconds": 245272}, "event": "SHUTDOWN"} +{"timestamp": {"seconds": 1506332641, "microseconds": 377751}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-ide0", "len": 271707340800, "offset": 271707340800, "speed": 0, "type": "mirror"}} + +Do you have more information on the sequence of commands issued to QEMU? I see the drive-mirror invocation, but then I don't see what causes the shutdown or the BLOCK_JOB_COMPLETED event. Usually this is in response to a user command. I'm wondering if the exact sequence issued is safe. + +Do you have a reproducer that I could try on my system to examine the behavior? + +Also, 2.7 is a bit old at this point; do you have the ability to try a version currently supported by the upstream project? (2.9 or 2.10?) + + + +In last try, vm shutdown before completing blockjob. +So i tried again and these are the exact qmp commands which i used: + +Sequence of qmp commands: + +socat UNIX-CONNECT:/var/run/qemu-server/48016.qmp STDIO +{"QMP": {"version": {"qemu": {"micro": 0, "minor": 7, "major": 2}, "package": "pve-qemu-kvm_2.7.0-10"}, "capabilities": []}} +{ "execute": "qmp_capabilities" } +{"return": {}} +{ "execute": "drive-mirror", + "arguments": { + "device": "drive-ide0", + "target": "/diskb/48016/vm-48016-disk-1.raw", + "sync": "full", + "mode": "absolute-paths", + "speed": 0 + } +} +{"return": {}} +{"timestamp": {"seconds": 1506434603, "microseconds": 633439}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-ide0", "len": 268479496192, "offset": 268479496192, "speed": 0, "type": "mirror"}} +{ "execute": 'block-job-complete', 'arguments': { 'device': 'drive-ide0' } } +{"return": {}} +{"timestamp": {"seconds": 1506494590, "microseconds": 735601}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-ide0", "len": 278522167296, "offset": 278522167296, "speed": 0, "type": "mirror"}} + +Then i poweroff VM and start it again from new image, but grub starts in rescue mode. + +It *looks* to me at a glance like the sequence should be safe, but I don't have any hunches for what could be going wrong, or why. + +Can you please post: + +(1) The command-line used to launch QEMU on the source machine, and +(2) The command-line used to launch QEMU on the destination machine from the mirrored image? + +There is no source or destination machine. I used drive-mirror to transfer VM Image to different physical disk on same machine ("mode": "absolute-paths"). After block-job-complete and shutting down vm, I start vm again with same command with different drive path pointing to mirrored image. "-drive 'file=MIRRORED_IMAGE_PATH..". + +* Command line used to launch VM: +``` +/usr/bin/kvm -id 48016 -chardev 'socket,id=qmp,path=/var/run/qemu-server/48016.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -pidfile /var/run/qemu-server/48016.pid -daemonize -smbios 'type=1,uuid=7a4b5ebc-a230-4e57-8ebc-4979a7b5a378' -name srv34197 -smp '4,sockets=1,cores=4,maxcpus=4' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vga cirrus -vnc unix:/var/run/qemu-server/48016.vnc,x509,password -cpu kvm64,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 8192 -k en-us -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -chardev 'socket,path=/var/run/qemu-server/48016.qga,server,nowait,id=qga0' -device 'virtio-serial,id=qga0,bus=pci.0,addr=0x8' -device 'virtserialport,chardev=qga0,name=org.qemu.guest_agent.0' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:6f368eef312d' -drive 'file=/var/lib/vz/images/48016/vm-48016-disk-1.raw,if=none,id=drive-ide0,format=raw,cache=none,aio=native,detect-zeroes=on' -device 'ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100' -drive 'file=/var/lib/vz/template/iso/sysresccd-v03.iso,if=none,id=drive-ide2,media=cdrom,aio=threads' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200' -netdev 'type=tap,id=net0,ifname=tap48016i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown' -device 'rtl8139,mac=D6:89:56:3F:38:1F,netdev=net0,bus=pci.0,addr=0x12,id=net0' -netdev 'type=tap,id=net1,ifname=tap48016i1,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown' -device 'rtl8139,mac=66:92:13:4A:6B:7E,netdev=net1,bus=pci.0,addr=0x13,id=net1' +``` + + +OK, so we're only talking about migrating a disk and not a whole VM, I misunderstood. However... are you using qemu *2.7*? That's quite old! Before digging into this further I need to insist that you try on a supported release, either 4.0.1, 4.1.1, or 4.2.0. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1729501 b/results/classifier/118/unknown/1729501 new file mode 100644 index 00000000..d650483f --- /dev/null +++ b/results/classifier/118/unknown/1729501 @@ -0,0 +1,263 @@ +user-level: 0.922 +mistranslation: 0.915 +graphic: 0.882 +semantic: 0.873 +risc-v: 0.872 +permissions: 0.871 +register: 0.870 +debug: 0.869 +device: 0.866 +socket: 0.862 +assembly: 0.862 +peripherals: 0.861 +PID: 0.861 +performance: 0.858 +network: 0.854 +VMM: 0.854 +virtual: 0.853 +arm: 0.852 +hypervisor: 0.850 +boot: 0.848 +vnc: 0.847 +kernel: 0.842 +KVM: 0.836 +i386: 0.834 +architecture: 0.834 +TCG: 0.812 +ppc: 0.808 +x86: 0.808 +files: 0.800 + +qemu crashes with assertion error `off_cur_end >= off_cur' failed + +My host environment: Xen + QEMU + +git clones today's xen git and qemut git (2017-10-31) + +xen -- git://xenbits.xen.org/xen.git +commit 24fb44e971a62b345c7b6ca3c03b454a1e150abe + +qemu -- https://github.com/qemu/qemu +commit 47ba789c97c8d201d01058b00a14d8a9a85fcfe9 + +QEMU was compiled using: +./configure --prefix=/mnt/bin/ --enable-xen --target-list=i386-softmmu --extra-cflags="-I/mnt/xen/tools/include -I/mnt/xen/tools/libxc -I/mnt/xen/tools/xenstore" --extra-ldflags="-L/mnt/xen/tools/libxc -L/mnt/xen/tools/xenstore" --enable-debug --enable-debug-stack-usage + +Xen was configured with the above QEMU distribution: +./configure --with-system-qemu=/mnt/bin/bin/qemu-system-i386 + +QEMU command line: +/mnt/bin/bin/qemu-system-i386 -xen-domid 28 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-28,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-28,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name ubu_hvm -vnc 0.0.0.0:1,to=99 -display none -serial pty -device cirrus-vga,vgamem_mb=8 -boot order=c -smp 2,maxcpus=2 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:74:34:32 -netdev type=tap,id=net0,ifname=vif28.0-emu,script=no,downscript=no -device rtl8139,id=nic1,netdev=net1,mac=00:16:3e:5f:48:e4 -netdev type=tap,id=net1,ifname=vif28.1-emu,script=no,downscript=no -machine xenfv -m 1504 -drive file=/mnt/10G.hdd,if=ide,index=0,media=disk,format=raw,cache=writeback + +Produce: +I run a fuzzer program in guest vm, it may set incorrect values for graphics registers, sequencer registers and other registers. + +Seeing the following error from /var/log/xen/qemu-dm-<vm-name>.log: +qemu-system-i386: hw/display/cirrus_vga.c:712: cirrus_invalidate_region: Assertion `off_cur_end >= off_cur' failed. + +I can reproduce it at anytime, if you need to gather more diagnostic information or try test patches, I'm happy to help. + + +gdb bt: +#0 0x00007f81a64f8c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007f81a64fc028 in __GI_abort () at abort.c:89 +#2 0x00007f81a64f1bf6 in __assert_fail_base (fmt=0x7f81a6646018 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x55d70cf8cdf2 "off_cur_end >= off_cur", file=file@entry=0x55d70cf8cda9 "hw/display/cirrus_vga.c", line=line@entry=712, + function=function@entry=0x55d70cf8db60 <__PRETTY_FUNCTION__.40643> "cirrus_invalidate_region") at assert.c:92 +#3 0x00007f81a64f1ca2 in __GI___assert_fail (assertion=0x55d70cf8cdf2 "off_cur_end >= off_cur", file=0x55d70cf8cda9 "hw/display/cirrus_vga.c", line=712, + function=0x55d70cf8db60 <__PRETTY_FUNCTION__.40643> "cirrus_invalidate_region") at assert.c:101 +#4 0x000055d70cb66445 in cirrus_invalidate_region (s=0x55d70ee3a4b0, off_begin=4190568, off_pitch=1842, bytesperline=5056, lines=2922) at hw/display/cirrus_vga.c:712 +#5 0x000055d70cb6660c in cirrus_bitblt_common_patterncopy (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:752 +#6 0x000055d70cb6676d in cirrus_bitblt_videotovideo_patterncopy (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:786 +#7 0x000055d70cb670c5 in cirrus_bitblt_videotovideo (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:986 +#8 0x000055d70cb678bf in cirrus_bitblt_start (s=0x55d70ee3a4b0) at hw/display/cirrus_vga.c:1136 +#9 0x000055d70cb6880b in cirrus_vga_write_gr (s=0x55d70ee3a4b0, reg_index=42, reg_value=228) at hw/display/cirrus_vga.c:1652 +#10 0x000055d70cb6ab86 in cirrus_vga_ioport_write (opaque=0x55d70ee3a4b0, addr=975, val=228, size=1) at hw/display/cirrus_vga.c:2754 +#11 0x000055d70c91d9c0 in memory_region_write_accessor (mr=0x55d70ee4af70, addr=31, value=0x7fffdaaeaf38, size=1, shift=8, mask=255, attrs=...) + at /mnt/qemu/memory.c:560 +#12 0x000055d70c91dc3a in access_with_adjusted_size (addr=30, value=0x7fffdaaeaf38, size=2, access_size_min=1, access_size_max=1, + access_fn=0x55d70c91d8c9 <memory_region_write_accessor>, mr=0x55d70ee4af70, attrs=...) at /mnt/qemu/memory.c:627 +#13 0x000055d70c920f48 in memory_region_dispatch_write (mr=0x55d70ee4af70, addr=30, data=58410, size=2, attrs=...) at /mnt/qemu/memory.c:1503 +#14 0x000055d70c8c51e0 in flatview_write_continue (fv=0x55d70ecb66d0, addr=974, attrs=..., buf=0x7fffdaaeb0f0 "*\344W\026\377\177", len=4, addr1=30, l=2, + mr=0x55d70ee4af70) at /mnt/qemu/exec.c:2951 +#15 0x000055d70c8c5390 in flatview_write (fv=0x55d70ecb66d0, addr=974, attrs=..., buf=0x7fffdaaeb0f0 "*\344W\026\377\177", len=4) at /mnt/qemu/exec.c:3002 +#16 0x000055d70c8c5406 in address_space_write (as=0x55d70d70d5e0 <address_space_io>, addr=974, attrs=..., buf=0x7fffdaaeb0f0 "*\344W\026\377\177", len=4) + at /mnt/qemu/exec.c:3014 +#17 0x000055d70c914fb3 in cpu_outl (addr=974, val=374858794) at /mnt/qemu/ioport.c:81 +#18 0x000055d70ca0253f in do_outp (addr=974, size=4, val=374858794) at /mnt/qemu/hw/i386/xen/xen-hvm.c:782 +#19 0x000055d70ca02888 in cpu_ioreq_pio (req=0x7fffdaaeb210) at /mnt/qemu/hw/i386/xen/xen-hvm.c:852 +#20 0x000055d70ca02f2e in handle_ioreq (state=0x55d70e0cf3d0, req=0x7fffdaaeb210) at /mnt/qemu/hw/i386/xen/xen-hvm.c:961 +#21 0x000055d70ca0343e in cpu_handle_ioreq (opaque=0x55d70e0cf3d0) at /mnt/qemu/hw/i386/xen/xen-hvm.c:1089 +#22 0x000055d70ce75d69 in aio_dispatch_handlers (ctx=0x55d70e098550) at util/aio-posix.c:406 +#23 0x000055d70ce75f0b in aio_dispatch (ctx=0x55d70e098550) at util/aio-posix.c:437 +#24 0x000055d70ce70b46 in aio_ctx_dispatch (source=0x55d70e098550, callback=0x0, user_data=0x0) at util/async.c:261 +#25 0x00007f81a7215e04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#26 0x000055d70ce74455 in glib_pollfds_poll () at util/main-loop.c:214 +#27 0x000055d70ce7456a in os_host_main_loop_wait (timeout=16061710) at util/main-loop.c:261 +#28 0x000055d70ce7463f in main_loop_wait (nonblocking=0) at util/main-loop.c:515 +#29 0x000055d70ca8e6a6 in main_loop () at vl.c:1995 +#30 0x000055d70ca96815 in main (argc=42, argv=0x7fffdaaeb888, envp=0x7fffdaaeb9e0) at vl.c:4897 + + + + Hi, + +> > -device cirrus-vga,vgamem_mb=8 + +Don't do that. cirrus has 4 MB video memory, like physical hardware +has. And you can't change that (i.e. the guest wouldn't be able to use +it if you assign more). The switch exists for live migration +compatibility only, because older qemu versions erroneously assigned +more than 4 MB to cirrus. + +I expect you can't trigger the assert any more if you remove +"vgamem_mb=8". + +cheers, + Gerd + + + +Hi Gerd, + +Xen toolstack uses 8 MB by default, see: +https://github.com/xen-project/xen/blob/staging/tools/libxl/libxl_create.c#L292 + +Now I change it to 4MB, QEMU command line: +/mnt/bin/bin/qemu-system-i386 -xen-domid 38 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-38,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-38,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config -name ubu_hvm -vnc 0.0.0.0:1,to=99 -display none -serial pty -device cirrus-vga,vgamem_mb=4 -boot order=c -smp 2,maxcpus=2 -device rtl8139,id=nic0,netdev=net0,mac=00:16:3e:74:34:32 -netdev type=tap,id=net0,ifname=vif38.0-emu,script=no,downscript=no -device rtl8139,id=nic1,netdev=net1,mac=00:16:3e:5f:48:e4 -netdev type=tap,id=net1,ifname=vif38.1-emu,script=no,downscript=no -machine xenfv -m 1508 -drive file=/mnt/10G.hdd,if=ide,index=0,media=disk,format=raw,cache=writeback + +Run fuzzer program again and get two segfaults: + +(gdb) bt +#0 0x000055709265e647 in vga_draw_text (s=0x5570949744b0, full_update=1) at /mnt/qemu/hw/display/vga.c:1283 +#1 0x000055709265fd04 in vga_update_display (opaque=0x5570949744b0) at /mnt/qemu/hw/display/vga.c:1766 +#2 0x0000557092a13756 in graphic_hw_update (con=0x557094a7bb20) at ui/console.c:263 +#3 0x0000557092a27f8e in vnc_refresh (dcl=0x7fc1f688b070) at ui/vnc.c:2855 +#4 0x0000557092a1774e in dpy_refresh (s=0x557094a74c60) at ui/console.c:1594 +#5 0x0000557092a1344c in gui_update (opaque=0x557094a74c60) at ui/console.c:201 +#6 0x0000557092b7282a in timerlist_run_timers (timer_list=0x557093bd1800) at util/qemu-timer.c:536 +#7 0x0000557092b72895 in qemu_clock_run_timers (type=QEMU_CLOCK_REALTIME) at util/qemu-timer.c:547 +#8 0x0000557092b72d96 in qemu_clock_run_all_timers () at util/qemu-timer.c:662 +#9 0x0000557092b73666 in main_loop_wait (nonblocking=0) at util/main-loop.c:521 +#10 0x000055709278d6a6 in main_loop () at vl.c:1995 +#11 0x0000557092795815 in main (argc=42, argv=0x7fffd33f1eb8, envp=0x7fffd33f2010) at vl.c:4897 + +(gdb) bt +#0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36 +#1 0x000055bed7158e30 in vnc_refresh_server_surface (vd=0x7fb9acfc4010) at ui/vnc.c:2827 +#2 0x000055bed7158fc4 in vnc_refresh (dcl=0x7fb9acfc4070) at ui/vnc.c:2862 +#3 0x000055bed714874e in dpy_refresh (s=0x55bed95d5c60) at ui/console.c:1594 +#4 0x000055bed714444c in gui_update (opaque=0x55bed95d5c60) at ui/console.c:201 +#5 0x000055bed72a382a in timerlist_run_timers (timer_list=0x55bed8732800) at util/qemu-timer.c:536 +#6 0x000055bed72a3895 in qemu_clock_run_timers (type=QEMU_CLOCK_REALTIME) at util/qemu-timer.c:547 +#7 0x000055bed72a3d96 in qemu_clock_run_all_timers () at util/qemu-timer.c:662 +#8 0x000055bed72a4666 in main_loop_wait (nonblocking=0) at util/main-loop.c:521 +#9 0x000055bed6ebe6a6 in main_loop () at vl.c:1995 +#10 0x000055bed6ec6815 in main (argc=42, argv=0x7ffd8134a6c8, envp=0x7ffd8134a820) at vl.c:4897 + +Attached gdb full backtrace. + +Hi Gerd, + +Would you please take a look at this patch, testing shows it prevents these crashes. I'm not an expert, just to give you more information. + +I cannot public the fuzzer program, if you need to gather more diagnostic information or try test patches, I'm happy to help. + + +diff --git a/hw/display/vga.c b/hw/display/vga.c +index 1d19f6b..ab6cd47 100644 +--- a/hw/display/vga.c ++++ b/hw/display/vga.c +@@ -1240,6 +1240,24 @@ static void vga_draw_text(VGACommonState *s, int full_update) + palette = s->last_palette; + x_incr = cw * surface_bytes_per_pixel(surface); + ++ /* ++ * In theory, line_offset = width * 4, if line_offset is ++ * less than width * 4, then afterwards, memory operation ++ * on server surface might overflow ++ */ ++ if (s->line_offset < 4 * width) { ++ s->line_offset = 4 * width; ++ line_offset = s->line_offset; ++ } ++ ++ /* ++ * The above if statement might introduce overflow since it ++ * might increase s->line_offset ++ */ ++ if (s->start_addr * 4 + line_offset * height >= s->vram_size) { ++ height = (s->vram_size - 1 - s->start_addr * 4) / line_offset; ++ } ++ + if (full_update) { + s->full_update_text = 1; + } +@@ -1464,7 +1482,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + { + DisplaySurface *surface = qemu_console_surface(s->con); + int y1, y, update, linesize, y_start, double_scan, mask, depth; +- int width, height, shift_control, bwidth, bits; ++ int width, height, shift_control, bwidth, bits, bpp; + ram_addr_t page0, page1, region_start, region_end; + DirtyBitmapSnapshot *snap = NULL; + int disp_width, multi_scan, multi_run; +@@ -1522,6 +1540,13 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + } + + depth = s->get_bpp(s); ++ bpp = depth / 8; ++ if (s->line_offset < disp_width * bpp) { ++ s->line_offset = disp_width * bpp; ++ } ++ if (s->start_addr * 4 + s->line_offset * height >= s->vram_size) { ++ height = (s->vram_size - 1 - s->start_addr * 4) / s->line_offset; ++ } + + /* + * Check whether we can share the surface with the backend +@@ -1717,7 +1742,7 @@ static void vga_draw_graphic(VGACommonState *s, int full_update) + static void vga_draw_blank(VGACommonState *s, int full_update) + { + DisplaySurface *surface = qemu_console_surface(s->con); +- int i, w; ++ int i, h, w; + uint8_t *d; + + if (!full_update) +@@ -1727,12 +1752,16 @@ static void vga_draw_blank(VGACommonState *s, int full_update) + + w = s->last_scr_width * surface_bytes_per_pixel(surface); + d = surface_data(surface); ++ if (w > surface_stride(surface)) { ++ w = surface_stride(surface); ++ } ++ h = MIN(s->last_scr_height, surface_height(surface)); + for(i = 0; i < s->last_scr_height; i++) { + memset(d, 0, w); + d += surface_stride(surface); + } + dpy_gfx_update(s->con, 0, 0, +- s->last_scr_width, s->last_scr_height); ++ w, h); + } + + #define GMODE_TEXT 0 + + + + +Hi Gerd, + +Any chance to have a look? + +This issue still can be reproduced with the latest code. +(commit 281f327487c9c9b1599f93c589a408bbf4a651b8) + +Please check the attachment for full gdb backtrace. + +The issue has been fixed: http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg02174.html + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7cdc61becd095b64a78 + diff --git a/results/classifier/118/unknown/1765 b/results/classifier/118/unknown/1765 new file mode 100644 index 00000000..6a834e12 --- /dev/null +++ b/results/classifier/118/unknown/1765 @@ -0,0 +1,125 @@ +graphic: 0.849 +semantic: 0.819 +peripherals: 0.814 +register: 0.809 +user-level: 0.809 +debug: 0.807 +virtual: 0.799 +architecture: 0.799 +performance: 0.788 +arm: 0.787 +network: 0.784 +mistranslation: 0.780 +permissions: 0.778 +TCG: 0.777 +assembly: 0.774 +kernel: 0.773 +device: 0.772 +risc-v: 0.771 +vnc: 0.771 +socket: 0.766 +KVM: 0.765 +VMM: 0.764 +PID: 0.763 +x86: 0.763 +boot: 0.760 +hypervisor: 0.758 +ppc: 0.756 +files: 0.753 +i386: 0.714 + +Linux kernel fails to boot on powernv machines with nvme device on s390x hosts +Description of problem: +When running a powernv guest with nvme device on a s390x host, the guest linux kernel fails to boot with the following panic: + +``` +nvme nvme0: pci function 0002:01:00.0 +nvme 0002:01:00.0: enabling device (0100 -> 0102) +nvme nvme0: 1/0/0 default/read/poll queues +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +nvme nvme0: invalid id 0 completed on queue 0 +BUG: Kernel NULL pointer dereference on read at 0x00000008 +Faulting instruction address: 0xc0000000000c02ec +Oops: Kernel access of bad area, sig: 11 [#1] +LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV +Modules linked in: nvme powernv_flash(+) rtc_opal ibmpowernv mtd nvme_core +CPU: 0 PID: 100 Comm: pb-console Not tainted 5.10.50-openpower1 #2 +NIP: c0000000000c02ec LR: c00000000050d5dc CTR: c00000000024a2d0 +REGS: c00000003ffdfa00 TRAP: 0300 Not tainted (5.10.50-openpower1) +MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24000402 XER: 20000000 +CFAR: c00000000000f3c0 DAR: 0000000000000008 DSISR: 40000000 IRQMASK: 1 +GPR00: c0000000000ba058 c00000003ffdfc90 c00000000180db00 0000000000000008 +GPR04: 000000000000000a 0000000000000000 c000000002740210 c00000000274e218 +GPR08: c00000000183be00 0000000080000000 0000000000000000 c0080000003ba798 +GPR12: c00000000024a2d0 c000000001a30000 0000000000000000 0000000000000100 +GPR16: 0000000000000004 0000000000000020 0000000000000100 c00000000bbe8080 +GPR20: 0000000000000028 c000000001830100 0000000000000001 0000000000000000 +GPR24: c000000001831a00 c000000001410c00 00000000ffff9097 0000000000400040 +GPR28: 000000000000000a 000000000000000a 0000000000000008 0000000000000000 +NIP [c0000000000c02ec] __arch_spin_trylock+0x4/0x24 +LR [c00000000050d5dc] _raw_spin_lock_irqsave+0x2c/0x78 +Call Trace: +[c00000003ffdfc90] [c00000003ffdfcc0] 0xc00000003ffdfcc0 (unreliable) +[c00000003ffdfcd0] [c0000000000ba058] complete+0x24/0x64 +[c00000003ffdfd10] [c00000000024a2f8] blk_end_sync_rq+0x28/0x3c +[c00000003ffdfd30] [c00000000024f44c] __blk_mq_end_request+0x134/0x160 +[c00000003ffdfd70] [c0080000003b481c] nvme_complete_rq+0xcc/0x13c [nvme_core] +[c00000003ffdfda0] [c0080000000a1078] nvme_pci_complete_rq+0x78/0x108 [nvme] +[c00000003ffdfdd0] [c00000000024de38] blk_done_softirq+0xc0/0xd0 +[c00000003ffdfe30] [c00000000050da20] __do_softirq+0x238/0x28c +[c00000003ffdff20] [c0000000000875d4] __irq_exit_rcu+0x80/0xc8 +[c00000003ffdff50] [c000000000087844] irq_exit+0x18/0x30 +[c00000003ffdff70] [c000000000011c4c] __do_irq+0x80/0xa0 +[c00000003ffdff90] [c00000000001d7a4] call_do_irq+0x14/0x24 +[c00000000bff3960] [c000000000011d20] do_IRQ+0xb4/0xbc +[c00000000bff39f0] [c000000000008fac] hardware_interrupt_common_virt+0x1ac/0x1b0 +--- interrupt: 500 at arch_local_irq_restore+0xac/0xe8 + LR = __raw_spin_unlock_irq+0x34/0x40 +[c00000000bff3cf0] [0000000000000000] 0x0 (unreliable) +[c00000000bff3d20] [c0000000000a8344] __raw_spin_unlock_irq+0x34/0x40 +[c00000000bff3d50] [c0000000000a84b0] finish_task_switch+0x160/0x228 +[c00000000bff3df0] [c0000000000aa3d0] schedule_tail+0x20/0x8c +[c00000000bff3e20] [c00000000000cb50] ret_from_fork+0x4/0x54 +Instruction dump: +a14d0b7a 7da96b78 2f8a0000 419e0010 39400000 b14d0b7a 7c0004ac a1490b78 +394affff b1490b78 4e800020 812d0000 <7d401829> 2c0a0000 40c20010 7d20192d +---[ end trace 6b7a11c45e4fc465 ]--- + +Kernel panic - not syncing: Fatal exception +Rebooting in 30 seconds.. +``` + +The issue has been noticed while running the avocado tests on a s390x host: + +``` +make check-venv +./tests/venv/bin/avocado run tests/avocado/boot_linux_console.py:BootLinuxConsole.test_ppc_powernv8 +``` + +But they can also be reproduced manually: +Steps to reproduce: +1. wget https://github.com/open-power/op-build/releases/download/v2.7/zImage.epapr +2. ./qemu-system-ppc64 -nographic -M powernv8 -kernel zImage.epapr -append "console=tty0 console=hvc0" -device pcie-pci-bridge,id=bridge1,bus=pcie.1,addr=0x0 -device nvme,bus=pcie.2,addr=0x0,serial=1234 diff --git a/results/classifier/118/unknown/1766904 b/results/classifier/118/unknown/1766904 new file mode 100644 index 00000000..fd67407f --- /dev/null +++ b/results/classifier/118/unknown/1766904 @@ -0,0 +1,77 @@ +user-level: 0.845 +peripherals: 0.841 +TCG: 0.796 +vnc: 0.785 +KVM: 0.783 +hypervisor: 0.778 +VMM: 0.766 +permissions: 0.732 +performance: 0.719 +ppc: 0.711 +x86: 0.706 +arm: 0.705 +register: 0.705 +network: 0.703 +virtual: 0.699 +graphic: 0.695 +debug: 0.691 +semantic: 0.688 +architecture: 0.688 +boot: 0.683 +device: 0.683 +kernel: 0.683 +assembly: 0.682 +socket: 0.682 +PID: 0.681 +files: 0.673 +risc-v: 0.673 +i386: 0.667 +mistranslation: 0.661 + +Creating high hdd load (with constant fsyncs) on a SATA disk leads to freezes and errors in guest dmesg + +After upgrading from qemu 2.10.0+dfsg-2 to 2.12~rc3+dfsg-2 (on debian sid host), centos 7 guest started to show freezes and ata errors in dmesg during hdd workloads with writing many small files and repeated fsyncs. + +Host kernel 4.15.0-3-amd64. +Guest kernel 3.10.0-693.21.1.el7.x86_64 (slightly older guest kernel was tested too with same result). + +Script that reproduces the bug (first run usualy goes smooth, second and later runs result in dmesg errors and freezes): + +http://paste.debian.net/hidden/472fb220/ + +Sample of error messages in guest dmesg: + +http://paste.debian.net/hidden/8219e234/ + +A workaround that I am using right now: I have detached this SATA storage and reattached the same .qcow2 file as SCSI - this has fixed the issue for me. + +Copying command line into bug so we don't lose it: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm -name guest=myvm.local,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-myvm.local/master-key.aes -machine pc-i440fx-2.8,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu IvyBridge -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid b10ea3d4-410c-4dc3-b9b0-818d43314323 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-myvm.local/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device ahci,id=sata0,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/user/data/work/virt-images/myvm.local.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 -device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:39:66:3c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-3-myvm.local/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on + +and ccing in jsnow + +Relevant bits appear to be: + +-M pc-i1440fx-2.8 +-cpu IvyBridge +-m 2048 +-realtime mlock=off +-smp 2,sockets=2,cores=1,threads=1 +-device ahci,id=sata0,bus=pci.0,addr=0x7 +-drive file=/home/user/data/work/virt-images/myvm.local.qcow2,format=qcow2,if=none,id=drive-sata0-0-0 +-device ide-hd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 + +So this is a 2.8 PC machine that we've configured to use AHCI instead. I see some blips about CHS being zero, but that's expected in response to a (successful) flush (0xE7) command, so it looks like it's stalling out. I'll have to try to reproduce and see if I can trigger the hang. + + +I am getting the exact same issue. The freeze occurred when I tried to install Ubuntu 18.04 with qemu-2.12. However, it seems to be working just fine with qemu-2.11.1. So it seems that something in between 2.11.1 and 2.12 is the culprit. + +It's still possible to reproduce this issue with qemu-master (a3ac12fba028df90f7b3dbec924995c126c41022). + +Jake, can you try the fix I posted in https://bugs.launchpad.net/qemu/+bug/1769189 ? I'm not actually confident it's the same bug, but it might be worth a shot. It fixes a bug that was made more prominent inbetween 2.11 and 2.12, so it fits the timeline presented here. + +@John Snow Thanks! After applying that patch, I couldn't reproduce this anymore. At least for me it seems that these two issues refer to the same bug. + +Great, thank you so much for helping! + diff --git a/results/classifier/118/unknown/1767176 b/results/classifier/118/unknown/1767176 new file mode 100644 index 00000000..288f24ae --- /dev/null +++ b/results/classifier/118/unknown/1767176 @@ -0,0 +1,81 @@ +user-level: 0.899 +debug: 0.887 +x86: 0.871 +TCG: 0.864 +peripherals: 0.855 +performance: 0.855 +device: 0.849 +files: 0.847 +architecture: 0.845 +semantic: 0.843 +network: 0.838 +i386: 0.828 +risc-v: 0.826 +arm: 0.823 +ppc: 0.823 +graphic: 0.822 +boot: 0.816 +vnc: 0.812 +socket: 0.810 +VMM: 0.806 +PID: 0.787 +hypervisor: 0.784 +permissions: 0.775 +kernel: 0.771 +register: 0.756 +mistranslation: 0.749 +KVM: 0.749 +virtual: 0.726 +assembly: 0.724 + +GTK build fails with qemu 2.12.0 + +With the 2.12.0 release of QEMU passing `--enable-gtk` to configure causes the build to fail. I'm running macOS 10.13.5 with Xcode 9.3 FWIW. + +I'm building against GTK 2.24.32, which I appreciate is no longer the preferred version here, but I don't think the error is related to that aspect. I'll try and find the time later to attempt a GTK3 build to check that though. + +``` +ui/gtk.c:1147:16: error: use of undeclared identifier 'qemu_input_map_osx_to_qcode'; did you mean 'qemu_input_map_usb_to_qcode'? + return qemu_input_map_osx_to_qcode; + ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + qemu_input_map_usb_to_qcode +/private/tmp/qemu-20180426-60786-1av6pq8/qemu-2.12.0/include/ui/input.h:99:22: note: 'qemu_input_map_usb_to_qcode' declared here +extern const guint16 qemu_input_map_usb_to_qcode[]; + ^ +``` + +I tried poking around locally by applying the following diff, based off of a very brief glance over the code involved, but that simply causes the build to error out in a different way at a later point, so I assume I'm doing something stupid. + + +``` +diff --git a/Makefile b/Makefile +index d71dd5b..e857c3c 100644 +--- a/Makefile ++++ b/Makefile +@@ -313,6 +313,7 @@ KEYCODEMAP_FILES = \ + ui/input-keymap-qnum-to-qcode.c \ + ui/input-keymap-usb-to-qcode.c \ + ui/input-keymap-win32-to-qcode.c \ ++ ui/input-keymap-osx-to-qcode.c \ + ui/input-keymap-x11-to-qcode.c \ + ui/input-keymap-xorgevdev-to-qcode.c \ + ui/input-keymap-xorgkbd-to-qcode.c \ +diff --git a/include/ui/input.h b/include/ui/input.h +index 16395ab..8183840 100644 +--- a/include/ui/input.h ++++ b/include/ui/input.h +@@ -101,6 +101,9 @@ extern const guint16 qemu_input_map_usb_to_qcode[]; + extern const guint qemu_input_map_win32_to_qcode_len; + extern const guint16 qemu_input_map_win32_to_qcode[]; + ++extern const guint qemu_input_map_osx_to_qcode_len; ++extern const guint16 qemu_input_map_osx_to_qcode[]; ++ + extern const guint qemu_input_map_x11_to_qcode_len; + extern const guint16 qemu_input_map_x11_to_qcode[]; +``` + +Reproduces with GTK+3 rather than GTK+ as expected, FWIW. + +Resolved via https://git.qemu.org/?p=qemu.git;a=patch;h=656282d245b49b84d4a1a47d7b7ede482d541776, FYI. + diff --git a/results/classifier/118/unknown/1777315 b/results/classifier/118/unknown/1777315 new file mode 100644 index 00000000..e6b1a254 --- /dev/null +++ b/results/classifier/118/unknown/1777315 @@ -0,0 +1,170 @@ +graphic: 0.921 +TCG: 0.918 +peripherals: 0.915 +VMM: 0.911 +ppc: 0.906 +risc-v: 0.906 +KVM: 0.895 +vnc: 0.892 +mistranslation: 0.888 +virtual: 0.872 +permissions: 0.856 +semantic: 0.851 +arm: 0.849 +assembly: 0.844 +debug: 0.842 +register: 0.842 +performance: 0.842 +user-level: 0.838 +x86: 0.834 +hypervisor: 0.833 +socket: 0.830 +architecture: 0.827 +device: 0.826 +PID: 0.813 +kernel: 0.800 +files: 0.778 +network: 0.777 +i386: 0.768 +boot: 0.740 + +IDE short PRDT abort + +Hi, +QEMU 'hw/ide/core.c:871' Denial of Service Vulnerability in version qemu-2.12.0 + +run the program in qemu-2.12.0: +#define _GNU_SOURCE +#include <endian.h> +#include <sys/syscall.h> +#include <unistd.h> +#include <fcntl.h> +#include <stdio.h> +#include <string.h> +#include <sys/stat.h> +#include <stdint.h> +#include <string.h> + +static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2) +{ + if (a0 == 0xc || a0 == 0xb) { + char buf[128]; + sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block", (uint8_t)a1, (uint8_t)a2); + return open(buf, O_RDWR, 0); + } else { + char buf[1024]; + char* hash; +strncpy(buf, (char*)a0, sizeof(buf) - 1); + buf[sizeof(buf) - 1] = 0; + while ((hash = strchr(buf, '#'))) { + *hash = '0' + (char)(a1 % 10); + a1 /= 10; + } + return open(buf, a2, 0); + } +} + +uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff}; +void loop() +{ + long res = 0; +memcpy((void*)0x20000000, "/dev/sg#", 9); + res = syz_open_dev(0x20000000, 0, 2); + if (res != -1) + r[0] = res; + res = syscall(__NR_dup2, r[0], r[0]); + if (res != -1) + r[1] = res; +*(uint8_t*)0x20000ec0 = 0; +*(uint8_t*)0x20000ec1 = 0; +*(uint8_t*)0x20000ec2 = 0; +*(uint8_t*)0x20000ec3 = 0; +*(uint32_t*)0x20000ec8 = 0; +*(uint8_t*)0x20000ed8 = 0; +*(uint8_t*)0x20000ed9 = 0; +*(uint8_t*)0x20000eda = 0; +*(uint8_t*)0x20000edb = 0; +memcpy((void*)0x20000ee0, "\x9c\x4d\xe7\xd5\x0a\x62\x43\xa7\x77\x53\x67\xb3", 12); + syscall(__NR_write, r[1], 0x20000ec0, 0x323); +} + +int main() +{ + syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0); + loop(); + return 0; +} +this will crash qemu, output information: + qemu-system-x86_64: hw/ide/core.c:843: ide_dma_cb: Assertion `n * 512 == s->sg.size' failed. + + +Thanks +owl337 + +Are you going to provide a patch for this to the mailing list? (since you've assigned the bug to yourself) + +Oh no, this is a misunderstanding. + +More Details: +use this script https://raw.githubusercontent.com/google/syzkaller/master/tools/create-image.sh create + wheezy.img +than run: +qemu-system-x86_64 -m 2048 -smp 1 -net nic -net user,host=10.0.2.10,hostfwd=tcp::59199-:22 -display none -serial stdio -no-reboot -enable-kvm -hda /home/icy/linux-master/wheezy.img -snapshot -kernel /home/icy/linux-master/arch/x86/boot/bzImage -append "console=ttyS0 earlyprintk=serial oops=panic nmi_watchdog=panic panic_on_warn=1 panic=86400 ftrace_dump_on_oops=orig_cpu rodata=n vsyscall=native net.ifnames=0 biosdevname=0 kvm-intel.nested=1 kvm-intel.unrestricted_guest=1 kvm-intel.vmm_exclusive=1 kvm-intel.fasteoi=1 kvm-intel.ept=1 kvm-intel.flexpriority=1 kvm-intel.vpid=1 kvm-intel.emulate_invalid_guest_state=1 kvm-intel.eptad=1 kvm-intel.enable_shadow_vmcs=1 kvm-intel.pml=1 kvm-intel.enable_apicv=1 root=/dev/sda" + +bzImage is obtained by compiling v4.17 kernel(I am not sure if it works in other kernel version). + +than execute the program in the virtual machine: ./repro +qemu will crash, output innformation: + qemu-system-x86_64: hw/ide/core.c:843: ide_dma_cb: Assertion `n * 512 == s->sg.size' failed. + +this bug influences at least qemu-2.9.94 - qemu-2.12.0. + + +A repro for the bug is setup at https://github.com/asurati/1777315, although the rfc-patch that was sent yesterday is pending testing. Unless qemu-devel advises otherwise, I am available to test and present it as a bugfix, by tomorrow. + + +FYI: we've hit this as will with syzkaller testing; this is still reproducible as-is with latest qemu (commit a6ae238), and the latest Linux kernel (5.1-rc7). + +Here's a qtest reproducer: + +./i386-softmmu/qemu-system-i386 -M pc,accel=qtest \ +-qtest null -nographic -vga qxl -qtest stdio \ +-drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw \ +-drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw \ +-device ide-cd,drive=drive0 -device ide-hd,drive=drive1 -nodefaults \ +< attachment + +With -trace ide*: + +[R +0.020410] outw 0x171 0xffff +28186@1594494474.407743:ide_ioport_write IDE PIO wr @ 0x171 (Features); val 0xff; bus 0x55e383419100 IDEState 0x55e383419188 +28186@1594494474.407747:ide_ioport_write IDE PIO wr @ 0x172 (Sector Count); val 0xff; bus 0x55e383419100 IDEState 0x55e383419188 +OK +[S +0.020428] OK +[R +0.020433] outw 0x176 0x35fb +28186@1594494474.407756:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xfb; bus 0x55e383419100 IDEState 0x55e383419188 +28186@1594494474.407757:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x55e383419100 IDEState 0x55e383419558 +28186@1594494474.407759:ide_exec_cmd IDE exec cmd: bus 0x55e383419100; state 0x55e383419558; cmd 0x35 +.... +28186@1594494474.411019:ide_dma_cb IDEState 0x55e383419558; sector_num=1 n=511 cmd=DMA WRITE +OK +[S +0.023732] OK +[R +0.023736] outb 0x376 0x8f +28186@1594494474.411060:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x8f; bus 0x55e383419100 +OK +[S +0.023741] OK +[R +0.023742] outw 0x376 0x2779 +28186@1594494474.411064:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x79; bus 0x55e383419100 +OK +[S +0.023745] OK +qemu-system-i386: /home/alxndr/Development/qemu/hw/ide/core.c:880: void ide_dma_cb(void *, int): Assertion `n * 512 == s->sg.size' failed. + + + +This is an automated cleanup. This bug report has been moved +to QEMU's new bug tracker on gitlab.com and thus gets marked +as 'expired' now. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/57 + + diff --git a/results/classifier/118/unknown/1781463 b/results/classifier/118/unknown/1781463 new file mode 100644 index 00000000..58ed3a17 --- /dev/null +++ b/results/classifier/118/unknown/1781463 @@ -0,0 +1,134 @@ +graphic: 0.930 +semantic: 0.928 +virtual: 0.926 +files: 0.923 +debug: 0.920 +register: 0.919 +permissions: 0.919 +device: 0.909 +mistranslation: 0.907 +performance: 0.900 +assembly: 0.897 +architecture: 0.897 +PID: 0.884 +vnc: 0.884 +ppc: 0.878 +boot: 0.875 +arm: 0.874 +risc-v: 0.867 +VMM: 0.856 +TCG: 0.846 +user-level: 0.846 +hypervisor: 0.845 +peripherals: 0.835 +network: 0.818 +KVM: 0.813 +socket: 0.813 +kernel: 0.802 +x86: 0.783 +i386: 0.749 + +qemu don't start *.abs firmware files + +Hello Devs, + +I'm here to report this bug/issue because i'm using Win64 Qemu but i can't start a *.abs firmware at normally this firmware is based in Linux Kernel and this type of firmware is made for STB Receivers, + +So this is all information i provide to get support. + +Files extracted by ( binwalk -e ) + + +Terminal output: + +# binwalk -e AMIKO_HD8150_2.4.43_emu.abs + +DECIMAL HEXADECIMAL DESCRIPTION + +-------------------------------------------------------------------------------- +196736 0x30080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 11883876 bytes +3866752 0x3B0080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 3255512 bytes +5636224 0x560080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 87904 bytes + + +Files extracted with ALI TOOLS or Ali FirmwareDecriptor. + +Windows files output: + +Software used: Ali Main Code Decrypter 8.9 + +Files unpacked: + +bootloader +MemCfg +maincode(AV) +seecode +default_lang +cipluskey +countryband +logo_user +logo_menu +logo_radio +logo_boot +patch +defaultdb(PRC) +userdb(64+64) + + +Terminal OUTPUT: + +# hexdump -C + +part of file + + +00b51a30 00 00 00 00 4c 69 62 63 6f 72 65 20 76 65 72 73 |....Libcore vers| +00b51a40 69 6f 6e 20 31 33 2e 31 36 2e 30 40 53 44 4b 34 |ion 13.16.0@SDK4| +00b51a50 2e 30 66 61 2e 31 33 2e 31 36 5f 32 30 31 36 31 |.0fa.13.16_20161| +00b51a60 30 31 39 28 67 63 63 20 76 65 72 73 69 6f 6e 20 |019(gcc version | +00b51a70 33 2e 34 2e 34 20 6d 69 70 73 73 64 65 2d 36 2e |3.4.4 mipssde-6.| +00b51a80 30 36 2e 30 31 2d 32 30 30 37 30 34 32 30 29 28 |06.01-20070420)(| +00b51a90 41 64 6d 69 6e 69 73 74 72 61 74 6f 72 40 20 46 |Administrator@ F| +00b51aa0 72 69 2c 20 4a 75 6c 20 32 38 2c 20 32 30 31 37 |ri, Jul 28, 2017| +00b51ab0 20 31 32 3a 35 33 3a 32 38 20 41 4d 29 0a 00 00 | 12:53:28 AM)...| +00b51ac0 44 4d 58 5f 53 33 36 30 31 5f 30 00 00 a1 03 18 |DMX_S3601_0.....| + + +When I use readelf it says files isn't an ELF file, so i can't run it like a kernel (Bootloader,Maincode, and etc. ) + +so this is the cmd output when i use qemu Win64 (I don't whant to use linux to do the emulation about this *.abs extension firmware so please help me for win64 version from Qemu) + +CMD OUTPUT: + + C:\Program Files\qemu>qemu-system-mips.exe -machine mips -cpu mips32r6-generic -drive file=C:\30080.bin,index=0,media=disk,format=raw + +qemu-system-mips.exe: warning: could not load MIPS bios 'mips_bios.bin' + +I also tried a lot of diferents qemu-system... and a lot of diferent configs like -machine -cpu -kernel -driver root= -PFLASH and etc... and nothing hapenned + +How can i reproduce this issue ? +Reply:. + +Donwload *.abs firmware in amikoreceiver.com (only *.abs) and download AliDekompressor in http://www.satedu.cba.pl/ + +Direct tools: + +FirmwareDecrypter_v8.9.zip : + +http://www.satedu.cba.pl/index.php?action=downloadfile&filename=FirmwareDecrypter_v8.9.zip&directory=Test%20Folder& + +Ali__tools_Console_v4.0__CRC_FIXER.rar : + +http://www.satedu.cba.pl/index.php?action=downloadfile&filename=Ali__tools_Console_v4.0__CRC_FIXER.rar&directory=Test%20Folder& + + +so if Qemu can explain how can i fix this issue this can be highly helpfull. + +With my best regards, +David Martins +Screamfox + +As far as I understand the original description, this was about running an arbitrary firmware in QEMU that has been written for a board that we do not support in QEMU? This can not work. A machine consists of a CPU and various devices that are on board, so you can only run the software that has been written for the CPU and the corresponding devices. If I've got you right, you want to run some software for a board that we do not model in QEMU, so it just can't work since the required devices are not emulated. Thus I'm closing this as "Invalid" now ... unless I've misunderstood your description, then please complain and we can open the ticket again. + +Comment #1 from Thomas is correct, this MIPS machine is not modelled. + diff --git a/results/classifier/118/unknown/1782300 b/results/classifier/118/unknown/1782300 new file mode 100644 index 00000000..f7cde651 --- /dev/null +++ b/results/classifier/118/unknown/1782300 @@ -0,0 +1,135 @@ +permissions: 0.938 +graphic: 0.927 +debug: 0.924 +register: 0.923 +virtual: 0.918 +semantic: 0.918 +architecture: 0.911 +performance: 0.905 +device: 0.903 +assembly: 0.900 +user-level: 0.899 +arm: 0.898 +PID: 0.878 +kernel: 0.878 +network: 0.876 +socket: 0.873 +boot: 0.870 +mistranslation: 0.853 +risc-v: 0.847 +files: 0.843 +TCG: 0.840 +hypervisor: 0.837 +peripherals: 0.825 +vnc: 0.823 +VMM: 0.800 +KVM: 0.789 +x86: 0.786 +i386: 0.776 +ppc: 0.754 + +COLO unable to failover to secondary VM + +I test COLO feature on my host following docs/COLO-FT.txt in qemu folder, but fail to failover to secondary VM. +Is there any mistake in my execution steps? + +Execution environment: +QEMU v2.12.0-rc4 +OS: Ubuntu 16.04.3 LTS +Kernel: Linux 4.4.35 +Secondary VM IP: noted as "a.b.c.d" + +Execution steps: +# Primary +${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \ + -enable-kvm \ + -m 512M \ + -smp 2 \ + -qmp stdio \ + -vnc :7 \ + -name primary \ + -device piix3-usb-uhci \ + -device usb-tablet \ + -netdev tap,id=tap0,vhost=off \ + -device virtio-net-pci,id=net-pci0,netdev=tap0 \ + -drive if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\ + children.0.file.filename=${IMG_PATH},\ + children.0.driver=raw -S + +# Secondary +${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \ + -enable-kvm \ + -m 512M \ + -smp 2 \ + -qmp stdio \ + -vnc :8 \ + -name secondary \ + -device piix3-usb-uhci \ + -device usb-tablet \ + -netdev tap,id=tap1,vhost=off \ + -device virtio-net-pci,id=net-pci0,netdev=tap1 \ + -drive if=none,id=secondary-disk0,file.filename=${IMG_PATH},driver=raw,node-name=node0 \ + -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\ + file.driver=qcow2,top-id=active-disk0,\ + file.file.filename=$ACTIVE_DISK,\ + file.backing.driver=qcow2,\ + file.backing.file.filename=$HIDDEN_DISK,\ + file.backing.backing=secondary-disk0 \ + -incoming tcp:0:8888 + +# Enter into Secondary: +{'execute':'qmp_capabilities'} +{ 'execute': 'nbd-server-start', + 'arguments': {'addr': {'type': 'inet', 'data': {'host': 'a.b.c.d', 'port': '8889'} } } +} +{'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', 'writable': true } } + +# Enter into Primary: +{'execute':'qmp_capabilities'} +{'execute': 'human-monitor-command', + 'arguments': { + 'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=a.b.c.d,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0' + } +} +{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', 'node': 'nbd_client0' } } +{ 'execute': 'migrate-set-capabilities', + 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } } +{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:a.b.c.d:8888' } } + +# To test failover +Primary +{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'primary-disk0', 'child': 'children.1'}} +{ 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del nbd_client0'}} + +Secondary +{ 'execute': 'nbd-server-stop' } + +Stop Primary +Send ^C signal to terminate PVM. + +Secondary +{ "execute": "x-colo-lost-heartbeat" } + + +# Result: +Primary (Use ^C to terminate) +qemu-system-x86_64: Can't receive COLO message: Input/output error +qemu-system-x86_64: terminating on signal 2 +{"timestamp": {"seconds": 1531815575, "microseconds": 997696}, "event": "SHUTDOWN", "data": {"guest":false}} + +Secondary +{ 'execute': 'nbd-server-stop' } +{"return": {}} +{ "execute": "x-colo-lost-heartbeat" } +{"return": {}} +qemu-system-x86_64: Can't receive COLO message: Input/output error +Segmentation fault + +I also meet the same problem. +Does anybody have solutions for this problem? + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1790018 b/results/classifier/118/unknown/1790018 new file mode 100644 index 00000000..4a5eee0c --- /dev/null +++ b/results/classifier/118/unknown/1790018 @@ -0,0 +1,87 @@ +permissions: 0.860 +mistranslation: 0.839 +x86: 0.839 +peripherals: 0.831 +user-level: 0.829 +virtual: 0.827 +KVM: 0.803 +hypervisor: 0.802 +ppc: 0.801 +register: 0.786 +performance: 0.784 +device: 0.782 +risc-v: 0.773 +arm: 0.769 +TCG: 0.766 +debug: 0.764 +i386: 0.764 +architecture: 0.738 +semantic: 0.734 +vnc: 0.733 +VMM: 0.725 +socket: 0.714 +files: 0.712 +network: 0.707 +graphic: 0.707 +kernel: 0.705 +assembly: 0.702 +PID: 0.697 +boot: 0.695 + +Assertion failure (or segmentation fault) running 32-bit x86 Linux guest on 64-bit PowerPC host + +Qemu 2.12.1 (also tried 2.12.0) +Linux gwyn 4.14.48-mc8-easy #1 SMP Sat Jun 30 23:29:01 CDT 2018 ppc64 GNU/Linux +gcc (Adelie 6.4.0-r9) 6.4.0 +GNU assembler (GNU Binutils) 2.30 +musl libc (powerpc64) Version 1.1.19 + +64-bit, 64-thread (16-core) POWER9 server in Big endian mode: +processor : 0 +cpu : POWER9, altivec supported +clock : 3000.000000MHz +revision : 2.2 (pvr 004e 1202) + +Scenario: + +Attempting to install Adélie Linux 32-bit x86 guest on 64-bit PowerPC host using qemu-system-i386. + + +Command line: + +/usr/bin/qemu-system-i386 -cdrom adelie-live-pmmx-1.0-beta1-20180807.iso -hda /dev/gwyn/x86 -m 512 -cpu pentium3 + + +Environment reproduction: + +CD image can be obtained at https://distfiles.adelielinux.org/adelie/1.0-beta1/iso/adelie-live-pmmx-1.0-beta1-20180807.iso +/dev/gwyn/x86 is an LVM2 logical volume, 4 GB in size, on NVMe storage +Qemu was built from sources on this machine, with some distribution patches applied for musl support (does not affect tcg/ppc/* code); patches and build recipe (which was modified: https://bpaste.net/show/1bbb1d07d7f2 for recipe patch) can be found at: https://code.foxkit.us/adelie/packages/blob/master/user/qemu/APKBUILD + + +Without --enable-debug-tcg: + +Thread 5 "qemu-system-i38" received signal SIGSEGV, Segmentation fault. +[Switching to LWP 14090] +0x39fb04787f63db78 in ?? () +(gdb) +(gdb) bt +#0 0x39fb04787f63db78 in () +#1 0x00003ffff1cdb160 in code_gen_buffer () +#2 0x0000000100362048 in cpu_tb_exec (itb=<optimized out>, cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:169 +#3 0x0000000100362048 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:626 +#4 0x0000000100362048 in cpu_exec (cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:734 +#5 0x00000001003211b4 in tcg_cpu_exec (cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/cpus.c:1362 +#6 0x00000001003211b4 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/cpus.c:1461 +#7 0x00003ffff7fa275c in start (p=0x3fffedb6a810) at src/thread/pthread_create.c:147 +#8 0x00003ffff7fae4c8 in __clone () at src/thread/powerpc64/clone.s:43 + + + +With --enable-debug-tcg: + +Assertion failed: disp == (int16_t) disp (/usr/src/packages/user/qemu/src/qemu-2.12.1/tcg/ppc/tcg-target.inc.c: reloc_pc14_val: 204) +zsh: abort qemu-system-i386 + +This appears to be fixed by 9f754620651d3432114f4bb89c7f12cbea814b3e and present in 3.0.0. Closing. + diff --git a/results/classifier/118/unknown/1792523 b/results/classifier/118/unknown/1792523 new file mode 100644 index 00000000..976af09a --- /dev/null +++ b/results/classifier/118/unknown/1792523 @@ -0,0 +1,107 @@ +KVM: 0.903 +user-level: 0.900 +register: 0.878 +virtual: 0.869 +hypervisor: 0.866 +boot: 0.863 +permissions: 0.858 +x86: 0.856 +performance: 0.853 +VMM: 0.846 +TCG: 0.841 +arm: 0.838 +ppc: 0.831 +device: 0.831 +risc-v: 0.830 +peripherals: 0.830 +graphic: 0.828 +vnc: 0.826 +architecture: 0.824 +mistranslation: 0.819 +network: 0.817 +debug: 0.817 +assembly: 0.807 +files: 0.804 +i386: 0.793 +PID: 0.789 +kernel: 0.785 +semantic: 0.781 +socket: 0.772 + +usb passthrough not resetting on host after vm shutdown if started with -daemonize + +Below is the full Qemu command used to launch the VM. Have been using this same setup since Qemu 2.12, plus a couple of cherry picked patch commits fixing ide-hd and e1000e in Windows guests. Both sets of patches have now been merged to 3.0, so decided to update to 3.0. + +The VM launches and runs fine, but after shutting down, the usb devices that are passed through from the host (keyboard, mouse) do not work until unplugged and plugged in again. Have narrowed this down to the -daemonize -pidfile arguments.. if those lines are removed, usb devices work in the host again right away after VM shutdown. + +CPU: Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz +OS: Linux dev 4.18.6-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 5 11:54:09 UTC 2018 x86_64 GNU/Linux + +Thank you for looking into this! + + +#!/usr/bin/env bash + +echo vfio-pci > /sys/bus/pci/devices/0000:04:00.0/driver_override +echo 0000:04:00.0 > /sys/bus/pci/devices/0000:04:00.0/driver/unbind +echo 0000:04:00.0 > /sys/bus/pci/drivers/vfio-pci/bind +echo > /sys/bus/pci/devices/0000:04:00.0/driver_override + +/usr/bin/qemu-system-x86_64 \ +-name winnt \ +-daemonize \ +-pidfile /run/vms/qemu/winnt.pid \ +-boot menu=on \ +-drive if=pflash,format=raw,readonly,file=/opt/vms/qemu/machines/ovmf_code_patched.fd \ +-drive if=pflash,format=raw,file=/opt/vms/qemu/machines/winnt/ovmf_vars_patched.fd \ +-machine pc-q35-3.0,accel=kvm \ +-nodefaults \ +-cpu host,kvm=off,hv_vendor_id=RedHat,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff \ +-accel kvm \ +-smp 4,sockets=1,cores=4,threads=1 \ +-m 16G \ +-nic bridge,br=br0,mac=52:54:00:12:34:77,model=e1000e \ +-device vfio-pci,host=01:00.0,multifunction=on \ +-device vfio-pci,host=01:00.1 \ +-vga none \ +-display none \ +-monitor none \ +-blockdev raw,node-name=ide-hd.0,cache.direct=on,discard=unmap,file.driver=host_device,file.aio=native,file.filename=/dev/disk/by-id/ata-WDC_WDS500G2B0A-00SM50_181265803048 \ +-device ide-hd,drive=ide-hd.0,bus=ide.0,rotation_rate=1 \ +-blockdev raw,node-name=ide-hd.1,cache.direct=on,file.driver=host_device,file.aio=native,file.filename=/dev/disk/by-id/ata-TOSHIBA_HDWE160_X746K8ZTF56D-part1 \ +-device ide-hd,drive=ide-hd.1,bus=ide.1 \ +-device vfio-pci,host=04:00.0 \ +-device qemu-xhci \ +-device usb-host,vendorid=0x04d9,productid=0x0171 \ +-device usb-host,vendorid=0x1532,productid=0x005c \ +-device usb-host,vendorid=0x1b1c,productid=0x0c09 + +echo 0000:04:00.0 > /sys/bus/pci/devices/0000:04:00.0/driver/unbind +echo 0000:04:00.0 > /sys/bus/pci/drivers_probe + +To clarify, are the problematic USB passthrough devices these: + +-device usb-host,vendorid=0x04d9,productid=0x0171 \ +-device usb-host,vendorid=0x1532,productid=0x005c \ +-device usb-host,vendorid=0x1b1c,productid=0x0c09 + +or this: + +-device vfio-pci,host=04:00.0 \ + +Without knowing what the vfio-pci devices are (assuming 1:00.x is GPU+audio), I don't know if passthrough is being used as a colloquial for device assignment or if the issue is really with the usb-host devices. + +The usb-host devices have the problem. + +It does not seem to matter if 1 or all 3 are specified.. I had thought maybe only one of them was causing the issue.. but all of them are affected if '-daemonize' is specified at startup. + +Correct, the vfio-pci device 1:00.x is an Nvidia GPU+audio, and 4:00.0 is an Asmedia USB controller. + +But all of the vfio arguments and binding parts of this script can be removed, and replaced with '-vga std -display gtk' arguments, and the host has the same behavior of not regaining control of the usb-host devices until they are unplugged and plugged back in after the VM shuts down. + +No messages appear in dmesg or any stdout from Qemu related to errors or USB that stand out to me as a problem.. I am happy to try any suggestions to further narrow down the cause. + +Thanks for replying! + +I tested this again on the latest Qemu and Linux kernel and cannot reproduce it anymore, so this can be closed now.. + diff --git a/results/classifier/118/unknown/1794285 b/results/classifier/118/unknown/1794285 new file mode 100644 index 00000000..49779428 --- /dev/null +++ b/results/classifier/118/unknown/1794285 @@ -0,0 +1,136 @@ +permissions: 0.918 +boot: 0.909 +KVM: 0.906 +user-level: 0.906 +VMM: 0.905 +ppc: 0.896 +virtual: 0.886 +performance: 0.884 +mistranslation: 0.881 +register: 0.880 +vnc: 0.873 +TCG: 0.867 +device: 0.860 +architecture: 0.860 +risc-v: 0.857 +socket: 0.850 +debug: 0.846 +arm: 0.832 +i386: 0.829 +graphic: 0.827 +network: 0.826 +x86: 0.823 +PID: 0.820 +assembly: 0.816 +files: 0.812 +kernel: 0.807 +semantic: 0.804 +hypervisor: 0.783 +peripherals: 0.735 + +100% Host CPU usage while guest idling + +Hi, + +We have an appliance that runs a FreeBSD guest on a Yocto-based host via qemu-system-x86_64. +Everything functions fine however the host uses n00% of the CPU (where n = #smp) and RAM allocated to it whilst the 1 guest is sat nearing idle. + +Host: +PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +4406 root 20 0 16.7g 16g 26m S 500 53.0 17958:38 qemu-system-x86 + +Guest: +CPU 0: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle +CPU 1: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle +CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle +CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle +CPU 4: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% idle +Mem: 43M Active, 4783M Inact, 1530M Wired, 911M Buf, 9553M Free +Swap: 3072M Total, 3072M Free + +I have logged this with the appliance vendor and received the response: +"This is expected behaviour and you will see the same in any case where a Guest OS runs over a Host OS. +Host here has 5 CPUs and it has assigned all of them to Guest. +Since the Host is not being shared by any Guest OS; you will always see the 500% (or the 5 CPUs) given to qemu-system-x86. +I do see the same in lab and is very much expected" + +This feels fundamentally wrong to me. +I'm somewhat limited by what can be tested due to the nature of this being an appliance rather than a mainstream distro. + +I'm looking for feedback that I can use to push the vendor into investigating this issue. + +Versions below. + +Many thanks, +Gareth + + + +Host: +Linux 204a-node 3.10.100-ovp-rt110-WR6.0.0.31_preempt-rt #1 SMP Fri +Aug 3 01:59:01 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux + +Qemu: +QEMU emulator version 1.7.2, Copyright (c) 2003-2008 Fabrice Bellard + +Command: +(Vendor identifying information has been removed) + +/usr/bin/qemu-system-x86_64 \ +-name REMOVED \ +-S \ +-machine pc-i440fx-1.7,accel=kvm,usb=off \ +-m 16384 \ +-realtime mlock=on \ +-smp 5,sockets=5,cores=1,threads=1 \ +-uuid 76277b29-3bd4-4dd4-a705-ed34d6449d6d \ +-nographic \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/REMOVED.monitor,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x17 \ +-netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=REMOVED,bus=pci.0,addr=0x11 \ +-netdev tap,ifname=tap1,script=/etc/vehostd/XXX-em3-ifup,id=hostnet1,vhost=on,vhostfd=24 \ +-device virtio-net-pci,netdev=hostnet1,id=net1,mac=REMOVED,bus=pci.0,addr=0x12 \ +-netdev tap,ifname=tap2,script=/etc/vehostd/REMOVED-em4-ifup-SUMMIT,id=hostnet2,vhost=on,vhostfd=25 \ +-device virtio-net-pci,netdev=hostnet2,id=net2,mac=REMOVED,bus=pci.0,addr=0x1c \ +-netdev tap,ifname=tap3,script=/etc/vehostd/REMOVED-em4-re-re-ifup,id=hostnet3,vhost=on,vhostfd=26 \ +-device virtio-net-pci,netdev=hostnet3,id=net3,mac=REMOVED,bus=pci.0,addr=0x1d \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev tty,id=charserial1,path=/dev/ttyS1 \ +-device isa-serial,chardev=charserial1,id=serial1 \ +-chardev tty,id=charserial2,path=/dev/ttyS2 \ +-device isa-serial,chardev=charserial2,id=serial2 \ +-chardev tty,id=charserial3,path=/dev/ttyS3 \ +-device isa-serial,chardev=charserial3,id=serial3 \ +-device i6300esb,id=watchdog0,bus=pci.0,addr=0x10 \ +-watchdog-action reset \ +-object rng-random,id=rng0,filename=/dev/random \ +-device virtio-rng-pci,rng=rng0,max-bytes=1024,period=2000,bus=pci.0,addr=0x1e \ +-smbios type=0,vendor="INSYDE Corp.",version=REMOVED,date=11/03/2017,release=1.00 \ +-smbios type=1,manufacturer=REMOVED,product=REMOVED,version=REMOVED,serial=VF-NET \ +-device REMOVED-pci,host=0000:1c:00.0 \ +-device kvm-pci-assign,host=0000:00:14.0 \ +-device pci-hgcommdev,vmindex=0,bus=pci.0,addr=0x16 \ +-drive file=/REMOVED/REMOVED-current.img,if=none,id=drive-virtio-disk0,format=raw,cache=directsync,aio=native \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x13,drive=drive-virtio-disk0,id=virtio-disk0,config-wce=off,x-data-plane=on,bootindex=1 \ +-drive file=/REMOVED/REMOVED-var-config.img,if=none,id=drive-virtio-disk1,format=raw,cache=directsync,aio=native \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x15,drive=drive-virtio-disk1,id=virtio-disk1,config-wce=off,x-data-plane=on,bootindex=-1 \ +-drive file=/REMOVED/REMOVED-aux-disk.img,if=none,id=drive-ide0-0-1,format=raw,cache=directsync,discard=unmap \ +-device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=-1 \ +-drive file=/REMOVED/images/0/REMOVED-platform.img,if=none,id=drive-ide1-0-1,format=raw,cache=directsync,discard=unmap \ +-device ide-hd,bus=ide.1,unit=1,drive=drive-ide1-0-1,id=ide1-0-1,bootindex=-1 \ +-msg timestamp=on + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1796520 b/results/classifier/118/unknown/1796520 new file mode 100644 index 00000000..51a3cfc8 --- /dev/null +++ b/results/classifier/118/unknown/1796520 @@ -0,0 +1,135 @@ +risc-v: 0.918 +user-level: 0.890 +register: 0.879 +debug: 0.873 +TCG: 0.871 +x86: 0.867 +vnc: 0.862 +peripherals: 0.861 +ppc: 0.854 +mistranslation: 0.853 +semantic: 0.844 +graphic: 0.842 +i386: 0.841 +virtual: 0.840 +arm: 0.840 +assembly: 0.839 +architecture: 0.834 +socket: 0.833 +VMM: 0.831 +PID: 0.830 +device: 0.829 +KVM: 0.826 +boot: 0.823 +permissions: 0.822 +performance: 0.818 +kernel: 0.817 +hypervisor: 0.816 +network: 0.805 +files: 0.792 + +autogen crashes on qemu-sh4-user after 61dedf2af7 + +Running "autogen --help" crashes on qemu-sh4-user with: + +(sid-sh4-sbuild)root@nofan:/# autogen --help +Unhandled trap: 0x180 +pc=0xf64dd2de sr=0x00000000 pr=0xf63b9c74 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf61102a8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf64dd2a0 fpul=0x00000003 +r0=0xf6fc1320 r1=0x00000000 r2=0xffff5dc4 r3=0xf67bfb50 +r4=0xf6fc1230 r5=0xf6fc141c r6=0x000003ff r7=0x00000000 +r8=0x00000004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 +r12=0xf63e2258 r13=0xf63eae1c r14=0x00000804 r15=0xf6fc1220 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@nofan:/# + +Bi-secting found this commit to be the culprit: + +61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit +commit 61dedf2af79fb5866dc7a0f972093682f2185e17 +Author: Richard Henderson <email address hidden> +Date: Tue Jul 18 10:02:50 2017 -1000 + + target/sh4: Add missing FPSCR.PR == 0 checks + + Both frchg and fschg require PR == 0, otherwise undefined_operation. + + Reviewed-by: Aurelien Jarno <email address hidden> + Signed-off-by: Richard Henderson <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Aurelien Jarno <email address hidden> + +:040000 040000 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target + +Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. + +This is still reproducible on git master: + +(sid-sh4-sbuild)root@nofan:/# autogen +Unhandled trap: 0x180 +pc=0x7f4da99e sr=0x00000000 pr=0x7f3bfc74 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0x7f114320 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x7f4da960 fpul=0x00000003 +r0=0x7ffc130c r1=0x00000000 r2=0xffff5dc4 r3=0x7f7bfb54 +r4=0x7ffc121c r5=0x7ffc1408 r6=0x000003ff r7=0x00000000 +r8=0x00000004 r9=0x7f3e80bc r10=0x7ffc1408 r11=0x7f3e88f0 +r12=0x7f3e8258 r13=0x7f3f0e1c r14=0x00000804 r15=0x7ffc120c +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@nofan:/# + +Can we just revert 61dedf2af7 which fixes the problem? + +I can reproduce this bug, but I'm not sure what QEMU is doing wrong. Looking at the "SH4 Software Manual", it definitely says that if the FPSCR.PR bit is 0 then the 'frchg' and 'fschg' instructions should both trap. + +The 'frchg' that autogen is hitting is the one in glibc's "getcontext" implementation: +https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/sh/sh4/getcontext.S;hb=b6d2c4475d5abc05dd009575b90556bdd3c78ad0#l70 + +QEMU linux-user mode runs with FPSCR=0x000800000, which is "FPSCR.PR == 1", ie "double precision". This seems to match what the kernel has for its FPSCR_INIT value. + +Are you in a position to test what the actual hardware/real Linux kernel using for its FPSCR value when running sh4 userspace binaries ? + + +I can provide access to a machine connected to the internet so you can test it yourself. I'll send you an email. + +On that hardware, at least, the user-space visible FPSCR value is indeed 0x000800000. Execution of the 'frchg' insn either doesn't trap, or the trap is caught by the kernel and emulated. I think it is not being emulated because CONFIG_SH_FPU_EMU is not set. + +The comment at the top of arch/sh/kernel/cpu/sh4/fpu.c: +https://elixir.bootlin.com/linux/latest/source/arch/sh/kernel/cpu/sh4/fpu.c + +says that on "some SH4 implementations" executing frchg with the FPSCR.PR bit set causes a trap; the "SH-4 Software Manual" says it is "undefined_operation()" which I think means "implementation could do anything" (though the manual doesn't clearly define its terms here). The kernel code in fpu.c carefully sets the FPSCR value to clear the PR bit before performing the frchg instruction. + +My best guess is that this is a glibc bug, where its getcontext etc implementations should be doing the same set-fpscr-first work that the kernel code is doing, and so the glibc code happens to work OK on implementations like the SH7785 that seem to not trap here, but will fail on whatever the SH4 variants are that do trap (as well as on QEMU). But this needs an SH4 expert to clarify (for instance I might well have misread the kernel code and maybe it does trap-and-emulate here so that userspace can rely on the frchg behaviour with FPSCR.PR=1 ?). + +Is there somebody we can ask for clarification on what the defined behaviour of the architecture is here and what the impdef behaviour of the 7750/7751/7785 happen to be ? + + +(Edit to note that "that hardware" is an SH7785LCR with an SH7785 CPU.) + + +We can ask both glibc upstream and some SuperH experts. I'll ask. + +Did you ever ask the glibc or SuperH experts? Is this bug still pending in the latest version of QEMU? + +Bug is still pending on git master. Have not pinged the SuperH crew yet. Will try to do that tomorrow, I'll also ping glibc upstream. + +[Expired for QEMU because there has been no activity for 60 days.] + +Reported as https://sourceware.org/bugzilla/show_bug.cgi?id=27543 + +[Expired for QEMU because there has been no activity for 60 days.] + +We’re looking whether this can be fixed on the glibc side currently. + +The patch suggested by Thorsten Glaser glibc Bugzilla #27543 fixes the issue for me: + +> https://sourceware.org/bugzilla/show_bug.cgi?id=27543#c2 + +So could we close this QEMU ticket now, or is there still something to be done from the QEMU side? + +Yes, it can be closed. + +Thanks, closing now. + diff --git a/results/classifier/118/unknown/1810400 b/results/classifier/118/unknown/1810400 new file mode 100644 index 00000000..d841598b --- /dev/null +++ b/results/classifier/118/unknown/1810400 @@ -0,0 +1,70 @@ +user-level: 0.910 +permissions: 0.840 +risc-v: 0.826 +hypervisor: 0.825 +virtual: 0.817 +mistranslation: 0.816 +debug: 0.814 +KVM: 0.800 +TCG: 0.787 +graphic: 0.785 +vnc: 0.782 +files: 0.779 +VMM: 0.777 +arm: 0.775 +device: 0.771 +register: 0.769 +peripherals: 0.768 +assembly: 0.766 +boot: 0.765 +performance: 0.763 +architecture: 0.761 +socket: 0.756 +semantic: 0.753 +ppc: 0.748 +PID: 0.746 +network: 0.742 +kernel: 0.734 +i386: 0.732 +x86: 0.724 + + Failed to make dirty bitmaps writable: Can't update bitmap directory: Operation not permitted + +blockcommit does not work if there is dirty block. + +virsh version +Compiled against library: libvirt 4.10.0 +Using library: libvirt 4.10.0 +Using API: QEMU 4.10.0 +Running hypervisor: QEMU 2.12.0 + +Scenario: +1. Create an instance +2. Add dirty bitmap to vm disk. +3. create a snapshot(external or internal) +4. revert snapshot or blockcommit disk + +virsh blockcommit rota-test vda --active +Active Block Commit started + +virsh blockjob rota-test vda --info +No current block job for vda + + +rota-test.log: + starting up libvirt version: 4.10.0, package: 1.el7 (CBS <email address hidden>, 2018-12-05-12:27:12, c1bk.rdu2.centos.org), qemu version: 2.12.0qemu-kvm-ev-2.12.0-18.el7_6.1.1, kernel: 4.1.12-103.9.7.el7uek.x86_64, hostname: vm-kvm07 +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name guest=rota-test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-101-rota-test/master-key.aes -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge,hypervisor=on,xsaveopt=on -m 8192 -realtime mlock=off -smp 3,sockets=3,cores=1,threads=1 -uuid 50dec55c-a80a-4adc-a788-7ba23230064e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=59,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/rota-0003,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -netdev tap,fd=61,id=hostnet0,vhost=on,vhostfd=62 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e8:09:94,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5902,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on +2019-01-03T07:50:43.810142Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/3 (label charserial0) +main_channel_link: add main channel client +red_qxl_set_cursor_peer: +inputs_connect: inputs channel client create +inputs_channel_detach_tablet: +#block339: Failed to make dirty bitmaps writable: Can't update bitmap directory: Operation not permitted + +Acknowledged; target is 4.2. + +Vladimir Sementsov-Ogievskiy has some patches in-flight that seek to correct block commit behavior with bitmaps: https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg01160.html + + +Hi, this should be fixed in 4.2. It looks like you're still on 2.12.0 based on the report. Closing under the assumption this is fixed. If you discover otherwise, please feel free to re-open (or file a new bug.) + diff --git a/results/classifier/118/unknown/1811244 b/results/classifier/118/unknown/1811244 new file mode 100644 index 00000000..0411e650 --- /dev/null +++ b/results/classifier/118/unknown/1811244 @@ -0,0 +1,137 @@ +register: 0.843 +user-level: 0.819 +graphic: 0.799 +mistranslation: 0.796 +peripherals: 0.796 +performance: 0.793 +debug: 0.791 +network: 0.787 +KVM: 0.786 +hypervisor: 0.786 +device: 0.781 +virtual: 0.778 +boot: 0.778 +arm: 0.774 +socket: 0.773 +risc-v: 0.773 +TCG: 0.772 +assembly: 0.766 +permissions: 0.764 +architecture: 0.762 +semantic: 0.761 +x86: 0.759 +VMM: 0.756 +PID: 0.754 +kernel: 0.738 +ppc: 0.732 +files: 0.722 +vnc: 0.721 +i386: 0.688 + +qemu 3.1/i386 crashes/guest hangs when MTTCG is enabled + +When MTTCG is enabled, QEMU 3.1.0 sometimes crashes when running the following command line: + +qemu-system-i386 -kernel /home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/bootstrap -append bootstrap -initrd "/home/jermar/work/software/l4/fiasco/.build-i386/fiasco -serial_esc,/home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/l4f/sigma0 ,/home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/l4f/moe rom/ahci.cfg,/home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/l4f/ned ,test_env.lua ,/home/jermar/Kernkonzept/software/l4/pkg/ahci-driver/examples/md5sum/ahci.cfg ,/home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/l4f/l4re ,/home/jermar/Kernkonzept/software/l4/pkg/ahci-driver/examples/md5sum/ahci.io ,/home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/l4f/io ,/home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/l4f/ahci-drv ,/home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/l4f/ahci-md5-sync" -smp 4 -accel tcg,thread=multi -device ahci,id=ahci0 -drive if=none,file=/home/jermar/Kernkonzept/software/l4/.build-i386/pkg/ahci-driver/test/examples/test_ahci.img,format=raw,id=drive-sata0-0-0 -device ide-drive,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 -serial stdio -nographic -monitor none + +The host is x86_64. + +The stack at the time of the crash (core dump and debug binary linked below[1]): + +Core was generated by `qemu-system-i386 -kernel /home/jermar/Kernkonzept/software/l4/.build-i386/bin/x'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 io_writex (env=env@entry=0x565355ca0140, iotlbentry=iotlbentry@entry=0x565355ca9120, mmu_idx=2, val=val@entry=0, addr=addr@entry=3938451632, retaddr=retaddr@entry=140487132809203, recheck=false, size=4) + at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/accel/tcg/cputlb.c:791 +791 if (mr->global_locking && !qemu_mutex_iothread_locked()) { +[Current thread is 1 (Thread 0x7fc5af7fe700 (LWP 3625719))] +Missing separate debuginfos, use: dnf debuginfo-install SDL2-2.0.9-1.fc29.x86_64 at-spi2-atk-2.30.0-1.fc29.x86_64 at-spi2-core-2.30.0-2.fc29.x86_64 atk-2.30.0-1.fc29.x86_64 bzip2-libs-1.0.6-28.fc29.x86_64 cairo4 +(gdb) bt +#0 0x0000565354f5f365 in io_writex + (env=env@entry=0x565355ca0140, iotlbentry=iotlbentry@entry=0x565355ca9120, mmu_idx=2, val=val@entry=0, addr=addr@entry=3938451632, retaddr=retaddr@entry=140487132809203, recheck=false, size=4) + at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/accel/tcg/cputlb.c:791 +#1 0x0000565354f621b2 in io_writel (recheck=<optimized out>, retaddr=140487132809203, addr=3938451632, val=0, index=0, mmu_idx=2, env=0x565355ca0140) + at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/accel/tcg/softmmu_template.h:310 +#2 0x0000565354f621b2 in helper_le_stl_mmu (env=0x565355ca0140, addr=<optimized out>, val=0, oi=34, retaddr=140487132809203) + at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/accel/tcg/softmmu_template.h:310 +#3 0x00007fc5b5a587f3 in code_gen_buffer () +#4 0x0000565354f75fd0 in cpu_tb_exec (itb=<optimized out>, cpu=0x7fc5b5a5aa40 <code_gen_buffer+12266006>) at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/accel/tcg/cpu-exec.c:171 +#5 0x0000565354f75fd0 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7fc5b5a5aa40 <code_gen_buffer+12266006>) + at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/accel/tcg/cpu-exec.c:615 +#6 0x0000565354f75fd0 in cpu_exec (cpu=cpu@entry=0x565355c97e90) at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/accel/tcg/cpu-exec.c:725 +#7 0x0000565354f33b1f in tcg_cpu_exec (cpu=0x565355c97e90) at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/cpus.c:1429 +#8 0x0000565354f35e83 in qemu_tcg_cpu_thread_fn (arg=0x565355c97e90) at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/cpus.c:1733 +#9 0x0000565354f35e83 in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x565355c97e90) at /home/jermar/software/HelenOS/helenos.git/contrib/qemu/qemu-3.1.0/cpus.c:1707 +#10 0x00005653552ec5da in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:498 +#11 0x00007fc5b858a58e in start_thread () at /lib64/libpthread.so.0 +#12 0x00007fc5b84b96a3 in clone () at /lib64/libc.so.6 + +Another symptom that occurs more often than this crash is that the guest hangs while waiting for another CPU to complete a cross-CPU call. Disabling MTTCG makes both symptoms go away. + +[1] Core file + debug binary: http://jermar.eu/ref/qemu-mttcg-core.tar.xz + + + + + +As for the other outcome, when the guest hangs (instead of QEMU crashing), the guest CPUs that block forward progress are halted in an idle loop, have interrupts enabled and have a queued timer IRQ 248 and a pending software IPI IRQ 250. It appears another timer IRQ is currently being serviced (but the CPU is idling). + +(qemu) cpu 1 +(qemu) info registers +EAX=ff8b7000 EBX=ff8b7000 ECX=00000003 EDX=00000003 +ESI=00000001 EDI=ff8b5240 EBP=ff8b7000 ESP=ff8b7fac +EIP=f0029707 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=1 +ES =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA] +CS =0008 00000000 ffffffff 00cf9b00 DPL=0 CS32 [-RA] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA] +FS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA] +GS =0023 00000000 ffffffff 00cff300 DPL=3 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0068 efbfe280 00003d80 00008900 DPL=0 TSS32-avl +GDT= ffbd8400 00000077 +IDT= eacfe000 000007ff +CR0=8001003b CR2=00000000 CR3=03fde000 CR4=00000690 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +EFER=0000000000000000 +FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 +FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 +FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 +FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 +FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 +XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 +XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 +XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 +XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 +(qemu) info lapic +dumping local APIC state for CPU 1 + +LVT0 0x0001003f active-hi edge masked Fixed (vec 63) +LVT1 0x0001003f active-hi edge masked Fixed (vec 63) +LVTPC 0x000100ff active-hi edge masked Fixed (vec 255) +LVTERR 0x000000fb active-hi edge Fixed (vec 251) +LVTTHMR 0x000100ff active-hi edge masked Fixed (vec 255) +LVTT 0x000200f8 active-hi edge periodic Fixed (vec 248) +Timer DCR=0xb (divide by 1) initial_count = 997376 +SPIV 0x00000107 APIC enabled, focus=off, spurious vec 7 +ICR 0x00000000 physical edge de-assert no-shorthand +ICR2 0x00000000 cpu 0 (APIC ID) +ESR 0x00000000 +ISR 248 +IRR 248 250 + +APR 0x00 TPR 0x00 DFR 0x0f LDR 0x00 PPR 0xf0 + +(gdb) set $eip=f0029707 +(gdb) set $esp=ff8b7fac +(gdb) bt +#0 0xf0029707 in Proc::halt () at /home/jermar/Kernkonzept/software/l4/fiasco/src/drivers/ia32/processor-ia32.cpp:47 +#1 0xf00193b8 in Kernel_thread::idle_op (this=this@entry=0xffb66da4) at /home/jermar/Kernkonzept/software/l4/fiasco/src/kern/kernel_thread.cpp:134 +#2 0xf001bc11 in call_ap_bootstrap (this=0xffb66da4, resume=0xf001bc11) at /home/jermar/Kernkonzept/software/l4/fiasco/src/kern/app_cpu_thread.cpp:111 +#3 0x00000001 in ?? () + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1814381 b/results/classifier/118/unknown/1814381 new file mode 100644 index 00000000..9b70af08 --- /dev/null +++ b/results/classifier/118/unknown/1814381 @@ -0,0 +1,95 @@ +user-level: 0.905 +ppc: 0.886 +mistranslation: 0.884 +hypervisor: 0.872 +peripherals: 0.864 +assembly: 0.862 +debug: 0.859 +risc-v: 0.859 +permissions: 0.858 +register: 0.858 +semantic: 0.854 +socket: 0.851 +arm: 0.850 +network: 0.845 +TCG: 0.844 +device: 0.842 +graphic: 0.842 +KVM: 0.839 +performance: 0.837 +vnc: 0.837 +architecture: 0.835 +virtual: 0.833 +VMM: 0.818 +PID: 0.815 +boot: 0.806 +files: 0.796 +kernel: 0.795 +x86: 0.753 +i386: 0.750 + +qemu can't resolve ::1 when no network is available + +I'm not sure if this is a qemu thing or a getaddrinfo/glibc thing, or +even just something about my laptop. However we have a test failure +in nbdkit which only occurs when my laptop is not connected to wifi or +other networking. It boils down to: + + $ qemu-img info --image-opts "file.driver=nbd,file.host=::1,file.port=1234" + qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': addre +ss resolution failed for ::1:1234: Address family for hostname not supported + +In a successful case it should connect to a local NBD server on port +1234, but if you don't have that you will see: + + qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': Faile +d to connect socket: Connection refused + +I can ‘ping6 ::1’ fine. + +It also works if I replace ‘::1’ with ‘localhost6’. + +My /etc/hosts contains: + +127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 +::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 + +ping6 output when the network is not connected: + +$ ping6 ::1 +PING ::1(::1) 56 data bytes +64 bytes from ::1: icmp_seq=1 ttl=64 time=0.082 ms +64 bytes from ::1: icmp_seq=2 ttl=64 time=0.092 ms +64 bytes from ::1: icmp_seq=3 ttl=64 time=0.089 ms +^C +--- ::1 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 55ms +rtt min/avg/max/mdev = 0.082/0.087/0.092/0.011 ms + + +ip output when the network is not connected: + +$ ip a show scope host +1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever +2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 + link/ether e8:6a:64:5d:2c:66 brd ff:ff:ff:ff:ff:ff +3: wlp61s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 + link/ether 1e:2b:b1:0c:99:ef brd ff:ff:ff:ff:ff:ff +5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 + link/ether 52:54:00:72:04:db brd ff:ff:ff:ff:ff:ff + + +The logic in util/qemu-sockets.c is very complicated, containing workarounds +for all sorts of broken/obsolete GAI implementations, so it's hard to tell +what's going on there. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1815993 b/results/classifier/118/unknown/1815993 new file mode 100644 index 00000000..c07ed1e9 --- /dev/null +++ b/results/classifier/118/unknown/1815993 @@ -0,0 +1,86 @@ +user-level: 0.807 +hypervisor: 0.759 +KVM: 0.752 +i386: 0.751 +virtual: 0.740 +x86: 0.733 +TCG: 0.729 +vnc: 0.727 +permissions: 0.727 +peripherals: 0.727 +VMM: 0.721 +register: 0.720 +risc-v: 0.711 +boot: 0.710 +mistranslation: 0.705 +performance: 0.705 +ppc: 0.697 +arm: 0.695 +assembly: 0.691 +network: 0.684 +debug: 0.683 +device: 0.679 +architecture: 0.674 +graphic: 0.667 +socket: 0.663 +kernel: 0.662 +files: 0.657 +semantic: 0.656 +PID: 0.650 + +drive-backup with iscsi will cause vm disk no response + +virsh qemu-monitor-command ${DOMAIN} '{ "execute" : "drive-backup" , "arguments" : { "device" : "drive-virtio-disk0" , "sync" : "top" , "target" : "iscsi://192.168.1.100:3260/iqn.2019-01.com.iaas/0" } }' + +When the drive-backup is running, I manually crash the iscsi server（or interrupt network, eg. iptables -j DROP）. + +Then after less than 1 minute： +virsh qemu-monitor-command ${DOMAIN} --pretty '{ "execute": "query-block" }' will block and no any response, until timeout. This is still excusable. +But, the disk（drive-virtio-disk0）will occur the same situation：in vm os, the disk will block and no any response. + +In other words, when qemu and iscsi-server lose contact, It will cause the vm unable. + +--- +Host: centos 7.5 +qemu version: ovirt-4.2（qemu-2.12.0） +qemu command line: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + +iscsi： +yum -y install targetcli python-rtslib +systemctl start target +systemctl enable target + +targetcli /iscsi create iqn.2019-01.com.iaas + +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1 set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 + +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/portals create 192.168.1.100 3260 +targetcli /backstores/fileio create testfile1 /backup/file1 2G +targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/luns create /backstores/fileio/testfile1 + +On Fri, Feb 15, 2019 at 03:03:34AM -0000, Cheng Chen wrote: +> When the drive-backup is running, I manually crash the iscsi server（or +> interrupt network, eg. iptables -j DROP）. +> +> Then after less than 1 minute： +> virsh qemu-monitor-command ${DOMAIN} --pretty '{ "execute": "query-block" }' will block and no any response, until timeout. This is still excusable. +> But, the disk（drive-virtio-disk0）will occur the same situation：in vm os, the disk will block and no any response. +> +> In other words, when qemu and iscsi-server lose contact, It will cause +> the vm unable. + +I haven't tried to reproduce this but I guess QEMU reaches a +synchronization point where it waits for all outstanding requests to +complete. Since the iSCSI target is unresponsive QEMU gets stuck. + +These issues can sometimes be fixed by avoiding the synchronization +point (a backtrace should reveal where the main loop thread is stuck) +but other times it really is necessary to wait for all requests and the +solution isn't as obvious. + + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1832250 b/results/classifier/118/unknown/1832250 new file mode 100644 index 00000000..742e7ce0 --- /dev/null +++ b/results/classifier/118/unknown/1832250 @@ -0,0 +1,92 @@ +peripherals: 0.889 +permissions: 0.883 +virtual: 0.845 +arm: 0.844 +vnc: 0.844 +TCG: 0.842 +architecture: 0.837 +graphic: 0.828 +performance: 0.814 +risc-v: 0.812 +semantic: 0.808 +VMM: 0.808 +register: 0.807 +files: 0.801 +ppc: 0.801 +mistranslation: 0.797 +debug: 0.797 +assembly: 0.796 +user-level: 0.796 +hypervisor: 0.794 +PID: 0.793 +socket: 0.788 +device: 0.785 +x86: 0.775 +kernel: 0.760 +KVM: 0.760 +i386: 0.755 +network: 0.737 +boot: 0.699 + +arm32v6/golang:1.10-alpine is broken for qemu 2.8 on MacOS cross-compilation + +FROM arm32v6/golang:1.10-alpine + +docker build -t openhorizon/ibm.gps_arm:2.0.7 -f ./Dockerfile.arm . +Sending build context to Docker daemon 110.6kB +Step 1/12 : FROM arm32v6/golang:1.10-alpine +1.10-alpine: Pulling from arm32v6/golang +05276f4299f2: Pull complete +5657e63df536: Pull complete +febca98d0249: Pull complete +5053a7aa5dea: Pull complete +d048463a3701: Pull complete +b628c679d668: Pull complete +Digest: sha256:94c5fd97b17d0e9fe89e011446bedda4784cb0af7a60494989e2a21c0dcba92f +Status: Downloaded newer image for arm32v6/golang:1.10-alpine + ---> 3110964e8c9a +Step 2/12 : RUN apk --no-cache update && apk add git + ---> Running in 14ffb11506bb +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz +v3.9.4-24-g4e2ff29bbe [http://dl-cdn.alpinelinux.org/alpine/v3.9/main] +v3.9.4-25-g65097c9cdc [http://dl-cdn.alpinelinux.org/alpine/v3.9/community] +OK: 9547 distinct packages available +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/armhf/APKINDEX.tar.gz +fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/armhf/APKINDEX.tar.gz +(1/7) Installing nghttp2-libs (1.35.1-r0) +(2/7) Installing libssh2 (1.8.2-r0) +(3/7) Installing libcurl (7.64.0-r2) +(4/7) Installing libgcc (8.3.0-r0) +(5/7) Installing expat (2.2.6-r0) +(6/7) Installing pcre2 (10.32-r1) +(7/7) Installing git (2.20.1-r0) +Executing busybox-1.29.3-r10.trigger +OK: 18 MiB in 22 packages +Removing intermediate container 14ffb11506bb + ---> 6890ea7ed09b +Step 3/12 : RUN mkdir -p /build/bin + ---> Running in 44e52d78d7b4 +Removing intermediate container 44e52d78d7b4 + ---> 0763afda41d1 +Step 4/12 : COPY src /build/src + ---> 05bab9a72a34 +Step 5/12 : WORKDIR /build + ---> Running in 5a663caff249 +Removing intermediate container 5a663caff249 + ---> 5a6ca53c00de +Step 6/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go get github.com/kellydunn/golang-geo + ---> Running in 05b09ee0c206 +Removing intermediate container 05b09ee0c206 + ---> e68c6e222e51 +Step 7/12 : RUN env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go + ---> Running in ea6d2707e35f +qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-arm: /build/qemu-rwi8RH/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +The command '/bin/sh -c env GOPATH=/build GOOPTIONS_ARM='CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=6' go build -o /build/bin/armv6_gps /build/src/main.go' returned a non-zero code: 139 +make: *** [build] Error 139 + +Please can you try with a more recent version of QEMU? 2.8 is pretty old, and there are definitely some bugs involving Alpine Linux glibc and also go that we've fixed in later versions. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1837049 b/results/classifier/118/unknown/1837049 new file mode 100644 index 00000000..8a531ba2 --- /dev/null +++ b/results/classifier/118/unknown/1837049 @@ -0,0 +1,214 @@ +register: 0.868 +device: 0.865 +debug: 0.846 +risc-v: 0.844 +virtual: 0.843 +architecture: 0.840 +performance: 0.839 +graphic: 0.839 +user-level: 0.834 +assembly: 0.829 +permissions: 0.826 +socket: 0.822 +PID: 0.812 +semantic: 0.808 +arm: 0.802 +mistranslation: 0.796 +ppc: 0.796 +kernel: 0.795 +TCG: 0.794 +boot: 0.794 +hypervisor: 0.792 +files: 0.791 +peripherals: 0.783 +network: 0.781 +VMM: 0.777 +vnc: 0.773 +i386: 0.767 +KVM: 0.761 +x86: 0.746 + +qemu-system-ppc segfaults with -display sdl + +Hello. + +I was trying to debug this segfault: +https://lists.nongnu.org/archive/html/qemu-ppc/2019-07/msg00186.html + +I recompiled latest qemu from git (commit 0b18cfb8f1828c905139b54c8644b0d8f4aad879 ), using this configure line: +./configure --target-list=i386-softmmu,x86_64-softmmu,ppc-softmmu --audio-drv-list=alsa --disable-werror --extra-cflags="-Og" --enable-debug-tcg + +after this I tried original line under gdb, it was still segfaulting: + +--------------copy----------------- +gdb ./ppc-softmmu/qemu-system-ppc +GNU gdb (GDB) 7.11.1 +Copyright (C) 2016 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "i586-slackware-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: +<http://www.gnu.org/software/gdb/documentation/>. +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from ./ppc-softmmu/qemu-system-ppc...done. +warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". +To enable execution of this file add + add-auto-load-safe-path /dev/shm/qemu/.gdbinit +line to your configuration file "/home/guest/.gdbinit". +To completely disable this security protection add + set auto-load safe-path / +line to your configuration file "/home/guest/.gdbinit". +For more information about this security protection see the +"Auto-loading safe path" section in the GDB manual. E.g., run from the shell: + info "(gdb)Auto-loading safe path" +(gdb) run -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370 +Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 -device ES1370 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". +[New Thread 0xf560cb40 (LWP 8100)] +[New Thread 0xf4c1ab40 (LWP 8101)] +[New Thread 0xec1b7b40 (LWP 8102)] +[New Thread 0xc5821b40 (LWP 8104)] +[Thread 0xf4c1ab40 (LWP 8101) exited] +[New Thread 0xf4c1ab40 (LWP 8119)] + +Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0xec1b7b40 (LWP 8102)] +0xf26c2e44 in code_gen_buffer () +(gdb) bt full +#0 0xffffffff in code_gen_buffer () +#1 0x56710cf6 in cpu_exec (itb=<optimized out>, cpu=<optimized out>) at /dev/shm/qemu/accel/tcg/cpu-exec.c:173 + env = <optimized out> + ret = <optimized out> + last_tb = <optimized out> + tb_exit = <optimized out> + tb_ptr = 0xf26c2cc0 <code_gen_buffer+103976094> "‹]ш…Ы\017ЊБ\020" + ret = 0 + insns_left = <optimized out> + cflags = <optimized out> + tb = 0x5722fe58 + last_tb = <optimized out> + tb_exit = <optimized out> + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = <optimized out> +#2 0x56710cf6 in cpu_exec (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) at /dev/shm/qemu/accel/tcg/cpu-exec.c:621 + ret = 0 + insns_left = <optimized out> + cflags = <optimized out> + tb = 0x5722fe58 + last_tb = <optimized out> + tb_exit = <optimized out> + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = <optimized out> +#3 0x56710cf6 in cpu_exec (cpu=0x573db8f8) at /dev/shm/qemu/accel/tcg/cpu-exec.c:732 + cflags = <optimized out> + tb = 0x5722fe58 + last_tb = <optimized out> + tb_exit = <optimized out> + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = <optimized out> +#4 0x566cfade in tcg_cpu_exec (cpu=0x573db8f8) at /dev/shm/qemu/cpus.c:1435 + ret = <optimized out> +#5 0x566d1e6d in qemu_tcg_rr_cpu_thread_fn (arg=0x573db8f8) at /dev/shm/qemu/cpus.c:1537 + r = <optimized out> + cpu = 0x573db8f8 + __PRETTY_FUNCTION__ = "qemu_tcg_rr_cpu_thread_fn" +#6 0x56b56fe0 in qemu_thread_start (args=0x57400668) at util/qemu-thread-posix.c:502 + __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {1461911128, 1463813736, 1461911128, -333745816, 247778263, 1392237730}, __mask_was_saved = 0}}, __pad = {0xec1b70d0, 0x0, 0x0, 0x0}} + __cancel_routine = 0x56b57040 <qemu_thread_atexit_notify> + __not_first_call = <optimized out> + qemu_thread_args = 0x57400668 + start_routine = 0x566d1a30 <qemu_tcg_rr_cpu_thread_fn> + arg = 0x573db8f8 + r = <optimized out> +#7 0xffffffff in start_thread () at /lib/libpthread.so.0 +#8 0xffffffff in clone () at /lib/libc.so.6 +(gdb) quit +A debugging session is active. + + Inferior 1 [process 8096] will be killed. + +Quit anyway? (y or n) y +--------------copy end---------- + +But when I take away -display sdl, or replace it with -display gtk - same line was booting to desktop! + +Changing cpu to G3 also allowed boot: + +./ppc-softmmu/qemu-system-ppc -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512 -display sdl -vga std -d guest_errors,unimp -boot d -cpu G3 -g 1024x768x24 -device ES1370 + +This is 32-bit qemu complied with Slackware's gcc 5.5.0. +64-bit qemu works fine. + +Works for me with a 32-bit install of fedora 30. +That's using gcc 9.1.1. + +Is building with -Og required to reproduce this? +If so, I'm thinking compiler bug... + +Hello, Richard! +No, same bug was biting me without any specific options, i tried to add -Og for better debugging, but backtrace was anyway not complete ... I think I can live with -display gtk workaround for now. + +I think this one is fixed, I can boot Lubuntu to desktop like this: + +qemu-system-ppc -cdrom /dev/shm/lubuntu-16.04-desktop-powerpc.iso -boot d -display sdl,gl=on -g 1024x768x32 -M mac99,via=pmu -cpu G4 -device ES1370 -m 2047 -accel tcg,tb-size=384 -device usb-mouse + +without any crash, tried few times. + +Note, tb-size seems to be important on 32-bit host now, near qemu 5.0. + +qemu-system-ppc --version +QEMU emulator version 4.2.91 (v5.0.0-rc1-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +-dirty probably because I reinstalled SDL2 (2.0.9- > 2.0.12 during compilation of qemu). I also have different glibc this time (2.30 instead of 2.23) + + + +Andrew Randrianasulu <email address hidden> writes: + +> I think this one is fixed, I can boot Lubuntu to desktop like this: +> +> qemu-system-ppc -cdrom /dev/shm/lubuntu-16.04-desktop-powerpc.iso -boot +> d -display sdl,gl=on -g 1024x768x32 -M mac99,via=pmu -cpu G4 -device +> ES1370 -m 2047 -accel tcg,tb-size=384 -device usb-mouse +> +> without any crash, tried few times. +> +> Note, tb-size seems to be important on 32-bit host now, near qemu 5.0. + +There were changes this cycle to remove the TB size heuristic based on +guest RAM size. System emulation of 64 bit hosts gets a generous 1gb per +system by default where-as 32 bit hosts make do with a smaller code +buffer (which is statically allocated for user-mode). + +See the commits around 600e17b2615 (pull-tcg-20200228) + +> +> qemu-system-ppc --version +> QEMU emulator version 4.2.91 (v5.0.0-rc1-dirty) +> Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +> +> -dirty probably because I reinstalled SDL2 (2.0.9- > 2.0.12 during +> compilation of qemu). I also have different glibc this time (2.30 +> instead of 2.23) + + +-- +Alex Bennée + + +Closing according to comment #3 + diff --git a/results/classifier/118/unknown/1842530 b/results/classifier/118/unknown/1842530 new file mode 100644 index 00000000..64edcd6c --- /dev/null +++ b/results/classifier/118/unknown/1842530 @@ -0,0 +1,107 @@ +peripherals: 0.935 +permissions: 0.916 +register: 0.904 +VMM: 0.902 +hypervisor: 0.888 +network: 0.873 +architecture: 0.873 +graphic: 0.870 +arm: 0.862 +virtual: 0.854 +user-level: 0.852 +socket: 0.850 +performance: 0.846 +assembly: 0.842 +device: 0.841 +ppc: 0.834 +KVM: 0.819 +kernel: 0.819 +PID: 0.817 +vnc: 0.812 +files: 0.806 +x86: 0.802 +TCG: 0.795 +mistranslation: 0.790 +semantic: 0.788 +risc-v: 0.787 +debug: 0.787 +boot: 0.766 +i386: 0.748 + +ich6 and ich9 sound card has noisy（murmur） + +[root@localhost1 qemu]# lscpu +Architecture: x86_64 +CPU op-mode(s): 32-bit, 64-bit +Byte Order: Little Endian +CPU(s): 6 +On-line CPU(s) list: 0-5 +Thread(s) per core: 1 +Core(s) per socket: 6 +Socket(s): 1 +NUMA node(s): 1 +Vendor ID: GenuineIntel +CPU family: 6 +Model: 158 +Model name: Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz +Stepping: 10 +CPU MHz: 899.951 +CPU max MHz: 4000.0000 +CPU min MHz: 800.0000 +BogoMIPS: 5616.00 +Virtualization: VT-x +L1d cache: 32K +L1i cache: 32K +L2 cache: 256K +L3 cache: 9216K +NUMA node0 CPU(s): 0-5 +Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp spec_ctrl intel_stibp flush_l1d + + +[root@localhost1 qemu]# lsb_release -a +LSB Version: :core-4.1-amd64:core-4.1-noarch +Distributor ID: CentOS +Description: CentOS Linux release 7.6.1810 (Core) +Release: 7.6.1810 +Codename: Core + +Installed as Virtualization Server (qemuV1.5)； +create win7-32 or 64 GuestOS by virt-manager，and select default sound card ich6； + +<graphics type='spice' autoport='yes'> + <listen type='address'/> + <image compression='off'/> + </graphics> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + + +but obvious noise found when login guest os to play music. :( + +And the problem remains after I update qemu to 2.12.0-18 , 3.1.0 &etc. + + +[root@localhost1 qemu]# /usr/bin/qemu-system-x86_64 --version +QEMU emulator version 3.1.0 +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1847861 b/results/classifier/118/unknown/1847861 new file mode 100644 index 00000000..0d112e5d --- /dev/null +++ b/results/classifier/118/unknown/1847861 @@ -0,0 +1,86 @@ +user-level: 0.848 +mistranslation: 0.833 +hypervisor: 0.819 +arm: 0.817 +KVM: 0.809 +permissions: 0.806 +graphic: 0.802 +vnc: 0.800 +ppc: 0.795 +debug: 0.793 +VMM: 0.793 +TCG: 0.789 +virtual: 0.783 +files: 0.777 +register: 0.776 +risc-v: 0.770 +x86: 0.767 +peripherals: 0.758 +boot: 0.753 +semantic: 0.749 +i386: 0.744 +performance: 0.738 +assembly: 0.737 +architecture: 0.732 +device: 0.725 +socket: 0.722 +network: 0.719 +kernel: 0.715 +PID: 0.711 + +Guest stuttering under high disk IO (virtio) + +Performing io intensive tasks on virtualized Windows causes the system to visually stutter. I can often reproduce the problem by running fio on windows: + +fio --randrepeat=1 --ioengine=windowsaio --direct=1 --gtod_reduce=1 --name=test --filename=\\.\PhysicalDrive0 --bs=4k --iodepth=128 --size=4G --readwrite=randread + +While the fio command is running, moving the mouse pointer will be be laggy. The stuttering does not appear with iodepth <= 32 . The stuttering also manifests while playing games, the music and video pauses for a fraction of second in a playable but disturbing way. + +Here are my system specs: + +Host OS: archlinux +Guest OS: Windows 10 Enterprise +qemu version: qemu-git 8:v4.1.0.r1378.g98b2e3c9ab-1 (from AUR, compiled with -march=native) +CPU: AMD Ryzen Threadripper 1900X 8-Core Processor +Huge Pages: vm.nr_hugepages=4128 +Disk: nvme type=raw, io=threads bus=virtio +GPU (passthrough): Radeon RX 570 + +Here are some fio test results on my windows guest: + +[size=512M,iodepth=1 -> min=30k,avg=31k,stddev=508] +[size=2G,iodepth=8 -> min=203k,avg=207k,stddev=2.3k] +[size=2G,iodepth=16 -> min=320k,avg=330k,stddev=4.3k] +[size=4G,iodepth=32 -> min=300k,avg=310k,stddev=4.8k] +[size=4G,iodepth=64 -> min=278k,avg=366k,stddev=68.6k] -> STUTTER +[size=4G,iodepth=64 -> min=358k,avg=428k,stddev=52.6k] -> STUTTER +[size=4G,iodepth=128 -> min=92k,avg=217k,stddev=185k] -> STUTTER +[size=4G,iodepth=128 -> min=241k,avg=257k,stddev=14k] -> same config as above, but no stuttering + +The min and avg values are the bandwidth values reported in KB/s by fio. You can see that, when the stuttering occurs, the stardard deviation is high and the minimum bandwidth is way below the average. + +You can find my libvirt XML attached. Here is the full qemu command (taken from the ps output): + +/usr/bin/qemu-system-x86_64 -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-7-win10/master-key.aes -machine pc-q35-3.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,topoext=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff -drive file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/win10_VARS.fd,if=pflash,format=raw,unit=1 -m 8192 -overcommit mem-lock=off -smp 16,sockets=1,cores=8,threads=2 -object iothread,id=iothread1 -mem-prealloc -mem-path /dev/hugepages/libvirt/qemu/7-win10 -numa node,nodeid=0,cpus=0-7,mem=4096 -numa node,nodeid=1,cpus=8-15,mem=4096 -uuid d1c03f35-3846-4b76-a139-b798b497b95c -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=34,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 -device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 -device pcie-root-port,port=0x18,chassis=9,id=pci.9,bus=pcie.0,multifunction=on,addr=0x3 -device pcie-root-port,port=0x19,chassis=10,id=pci.10,bus=pcie.0,addr=0x3.0x1 -device pcie-pci-bridge,id=pci.11,bus=pci.3,addr=0x0 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device lsi,id=scsi0,bus=pci.11,addr=0x1 -drive file=/dev/nvme0n1p3,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.8,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive if=none,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 -netdev tap,fd=37,id=hostnet0,vhost=on,vhostfd=38 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:7c:10:fc,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device vfio-pci,host=41:00.0,id=hostdev0,bus=pci.4,addr=0x0 -device vfio-pci,host=41:00.1,id=hostdev1,bus=pci.5,addr=0x0 -device virtio-balloon-pci,id=balloon0,bus=pci.6,addr=0x0 -object input-linux,id=mouse1,evdev=/dev/input/by-path/pci-0000:42:00.3-usb-0:3:1.0-event-mouse -object input-linux,id=kbd1,evdev=/dev/input/by-path/pci-0000:42:00.3-usb-0:4:1.0-event-kbd,grab_all=on,repeat=on -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on + +Additional note: the performance of fio in the linux host is about 2x the one on the guest: + +fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/dev/nvme0n1 --bs=4k --iodepth=64 --size=512M --readwrite=randread + +read: IOPS=279k, BW=1092MiB/s (1145MB/s)(512MiB/469msec) + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1848901 b/results/classifier/118/unknown/1848901 new file mode 100644 index 00000000..a80f0f6b --- /dev/null +++ b/results/classifier/118/unknown/1848901 @@ -0,0 +1,166 @@ +risc-v: 0.900 +permissions: 0.895 +mistranslation: 0.887 +virtual: 0.877 +register: 0.873 +graphic: 0.873 +KVM: 0.872 +VMM: 0.864 +semantic: 0.863 +x86: 0.861 +vnc: 0.859 +peripherals: 0.859 +network: 0.853 +boot: 0.853 +performance: 0.852 +device: 0.850 +architecture: 0.848 +arm: 0.846 +files: 0.846 +assembly: 0.842 +TCG: 0.838 +hypervisor: 0.836 +debug: 0.832 +user-level: 0.831 +ppc: 0.829 +PID: 0.828 +i386: 0.805 +kernel: 0.803 +socket: 0.787 + +kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28) + +=> QEMU process has stopped, return code: -6 + +Start QEMU with /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive 'file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu/7725cdea-5e66-4777-b4dd-c3905f258394/hda_disk.qcow2,if=virtio,index=0,media=disk,id=drive0' -uuid 7725cdea-5e66-4777-b4dd-c3905f258394 -serial telnet:127.0.0.1:5000,server,nowait -monitor tcp:127.0.0.1:44629,server,nowait -net none -device e1000,mac=0c:7a:1d:83:94:00,netdev=gns3-0 -netdev socket,id=gns3-0,udp=127.0.0.1:10001,localaddr=127.0.0.1:10000 -device e1000,mac=0c:7a:1d:83:94:01,netdev=gns3-1 -netdev socket,id=gns3-1,udp=127.0.0.1:10003,localaddr=127.0.0.1:10002 -device e1000,mac=0c:7a:1d:83:94:02,netdev=gns3-2 -netdev socket,id=gns3-2,udp=127.0.0.1:10005,localaddr=127.0.0.1:10004 -device e1000,mac=0c:7a:1d:83:94:03,netdev=gns3-3 -netdev socket,id=gns3-3,udp=127.0.0.1:10007,localaddr=127.0.0.1:10006 -device e1000,mac=0c:7a:1d:83:94:04,netdev=gns3-4 -netdev socket,id=gns3-4,udp=127.0.0.1:10009,localaddr=127.0.0.1:10008 -device e1000,mac=0c:7a:1d:83:94:05,netdev=gns3-5 -netdev socket,id=gns3-5,udp=127.0.0.1:10011,localaddr=127.0.0.1:10010 -device e1000,mac=0c:7a:1d:83:94:06,netdev=gns3-6 -netdev socket,id=gns3-6,udp=127.0.0.1:10013,localaddr=127.0.0.1:10012 -device e1000,mac=0c:7a:1d:83:94:07,netdev=gns3-7 -netdev socket,id=gns3-7,udp=127.0.0.1:10015,localaddr=127.0.0.1:10014 -nographic + + +Execution log: +kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28) + +and then it just closes... + + + +[deemon@Zen ~]$ coredumpctl info 8638 + PID: 8638 (qemu-system-x86) + UID: 1000 (deemon) + GID: 1000 (deemon) + Signal: 6 (ABRT) + Timestamp: Sun 2019-10-20 04:27:29 EEST (5min ago) + Command Line: /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu> + Executable: /usr/bin/qemu-system-x86_64 + Control Group: /user.slice/user-1000.slice/session-2.scope + Unit: session-2.scope + Slice: user-1000.slice + Session: 2 + Owner UID: 1000 (deemon) + Boot ID: cd30f69a8d194359a31889dc7b6b026c + Machine ID: d0a2d74a5cd9430797d902f5237c448d + Hostname: Zen + Storage: /var/lib/systemd/coredump/core.qemu-system-x86.1000.cd30f69a8d194359a31889dc7b6b026c.8638.1571534849000000.lz4 (truncated) + Message: Process 8638 (qemu-system-x86) of user 1000 dumped core. + + Stack trace of thread 8642: + #0 0x00007f1a33609f25 n/a (n/a) + +Was trying to start Cisco ASAv 9.8.1 (with the correct hash from your own webpage) through GNS3 on Manjaro when this happened. + +correct hash from GNS3 webpage then* + +QEMU 4.1.0 btw. + + + +On 10/19/19 9:50 PM, P.O. wrote: +> Public bug reported: +> +> => QEMU process has stopped, return code: -6 +> +> Start QEMU with /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m +> 2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive +> 'file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu +> /7725cdea-5e66-4777-b4dd- +> c3905f258394/hda_disk.qcow2,if=virtio,index=0,media=disk,id=drive0' +> -uuid 7725cdea-5e66-4777-b4dd-c3905f258394 -serial +> telnet:127.0.0.1:5000,server,nowait -monitor +> tcp:127.0.0.1:44629,server,nowait -net none -device +> e1000,mac=0c:7a:1d:83:94:00,netdev=gns3-0 -netdev +> socket,id=gns3-0,udp=127.0.0.1:10001,localaddr=127.0.0.1:10000 -device +> e1000,mac=0c:7a:1d:83:94:01,netdev=gns3-1 -netdev +> socket,id=gns3-1,udp=127.0.0.1:10003,localaddr=127.0.0.1:10002 -device +> e1000,mac=0c:7a:1d:83:94:02,netdev=gns3-2 -netdev +> socket,id=gns3-2,udp=127.0.0.1:10005,localaddr=127.0.0.1:10004 -device +> e1000,mac=0c:7a:1d:83:94:03,netdev=gns3-3 -netdev +> socket,id=gns3-3,udp=127.0.0.1:10007,localaddr=127.0.0.1:10006 -device +> e1000,mac=0c:7a:1d:83:94:04,netdev=gns3-4 -netdev +> socket,id=gns3-4,udp=127.0.0.1:10009,localaddr=127.0.0.1:10008 -device +> e1000,mac=0c:7a:1d:83:94:05,netdev=gns3-5 -netdev +> socket,id=gns3-5,udp=127.0.0.1:10011,localaddr=127.0.0.1:10010 -device +> e1000,mac=0c:7a:1d:83:94:06,netdev=gns3-6 -netdev +> socket,id=gns3-6,udp=127.0.0.1:10013,localaddr=127.0.0.1:10012 -device +> e1000,mac=0c:7a:1d:83:94:07,netdev=gns3-7 -netdev +> socket,id=gns3-7,udp=127.0.0.1:10015,localaddr=127.0.0.1:10014 +> -nographic +> + +Reminds me of #1813940 https://bugs.launchpad.net/qemu/+bug/1813940 + +but that fix was in v4.1.0. + +> +> Execution log: +> kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device (28) +> +> and then it just closes... +> +> +> [deemon@Zen ~]$ coredumpctl info 8638 +> PID: 8638 (qemu-system-x86) +> UID: 1000 (deemon) +> GID: 1000 (deemon) +> Signal: 6 (ABRT) +> Timestamp: Sun 2019-10-20 04:27:29 EEST (5min ago) +> Command Line: /usr/bin/qemu-system-x86_64 -name CiscoASAv9.8.1-1 -m 2048M -smp cpus=1 -enable-kvm -machine smm=off -boot order=c -drive file=/home/deemon/GNS3/projects/ASAv my ass/project-files/qemu> +> Executable: /usr/bin/qemu-system-x86_64 +> Control Group: /user.slice/user-1000.slice/session-2.scope +> Unit: session-2.scope +> Slice: user-1000.slice +> Session: 2 +> Owner UID: 1000 (deemon) +> Boot ID: cd30f69a8d194359a31889dc7b6b026c +> Machine ID: d0a2d74a5cd9430797d902f5237c448d +> Hostname: Zen +> Storage: /var/lib/systemd/coredump/core.qemu-system-x86.1000.cd30f69a8d194359a31889dc7b6b026c.8638.1571534849000000.lz4 (truncated) +> Message: Process 8638 (qemu-system-x86) of user 1000 dumped core. +> +> Stack trace of thread 8642: +> #0 0x00007f1a33609f25 n/a (n/a) +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> + + + +apparently then the fix didn't work :P + +As a sidenote, while running the same ASAv in "GNS3 VM.ova" in oracle virtualbox in the same desktop computer, which apparently uses QEMU 3.1.0, it does work correctly. +However I would really like it to work without the VM inbetween directly in my OS QEMU 4 :-) + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1862874 b/results/classifier/118/unknown/1862874 new file mode 100644 index 00000000..91b0f560 --- /dev/null +++ b/results/classifier/118/unknown/1862874 @@ -0,0 +1,135 @@ +KVM: 0.877 +virtual: 0.849 +register: 0.839 +performance: 0.836 +user-level: 0.812 +permissions: 0.804 +debug: 0.803 +mistranslation: 0.802 +graphic: 0.801 +risc-v: 0.800 +x86: 0.797 +TCG: 0.795 +device: 0.785 +VMM: 0.778 +architecture: 0.777 +vnc: 0.774 +ppc: 0.771 +boot: 0.763 +hypervisor: 0.763 +assembly: 0.751 +semantic: 0.750 +peripherals: 0.747 +network: 0.744 +arm: 0.741 +socket: 0.730 +i386: 0.712 +kernel: 0.711 +files: 0.704 +PID: 0.680 + +java may stuck for a long time in system mode with "-cpu max" + +Bug Description: +Run "java -version" in guest VM, java may stuck for a long time (several hours) and then recover. + +Steps to reproduce: +1. Launch VM by attached simple script: launch.sh +2. Execute "java -version" and then print "date" in a loop + while : + do + /home/bot/jdk/bin/java -version + date + done +3. A long time gap will be observed: may > 24 hours. + +Technical details: +* host: x86_64 Linux 4.15.0-70-generic +* qemu v4.2.0 +* java: tried two versions: openjdk-11-jre-headless or compiled java-13 +* command-line: (See details in launch.sh) +/home/bot/qemu/qemu-build/qemu-4.2.0/binaries/bin/qemu-system-x86_64 \ + -drive "file=${img},format=qcow2" \ + -drive "file=${user_data},format=raw" \ + -cpu max \ + -m 24G \ + -serial mon:stdio \ + -smp 8 \ + -nographic \ +; + +* Observed by java core dump generated by "kill -SIGSEGV" when java stucked: +Different pthreads are blocked on their own condition variables: + + Id Target Id Frame + 1 Thread 0x7f48a041a080 (LWP 22470) __GI_raise (sig=sig@entry=6) + at ../sysdeps/unix/sysv/linux/raise.c:51 + 2 Thread 0x7f487197d700 (LWP 22473) 0x00007f489f5c49f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f48980197c0) + at ../sysdeps/unix/sysv/linux/futex-internal.h:88 + 3 Thread 0x7f4861b89700 (LWP 22483) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f4861b88960, expected=0, + futex_word=0x7f489801b084) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + 4 Thread 0x7f4861e8c700 (LWP 22480) 0x00007f489f5c76d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f48980107c0) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 + 5 Thread 0x7f4861c8a700 (LWP 22482) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f4861c89800, expected=0, + futex_word=0x7f489801ed44) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + 6 Thread 0x7f48a0418700 (LWP 22471) 0x00007f4880b13200 in ?? () + 7 Thread 0x7f48703ea700 (LWP 22478) 0x00007f489f5c49f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f489801dfc0) + at ../sysdeps/unix/sysv/linux/futex-internal.h:88 + 8 Thread 0x7f48702e9700 (LWP 22479) 0x00007f489f5c49f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f489838cd84) + at ../sysdeps/unix/sysv/linux/futex-internal.h:88 + 9 Thread 0x7f4870f71700 (LWP 22475) 0x00007f489f5c49f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f489801a300) + at ../sysdeps/unix/sysv/linux/futex-internal.h:88 + 10 Thread 0x7f487187b700 (LWP 22474) 0x00007f489f5c76d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f48980cf770) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 + 11 Thread 0x7f4871a7f700 (LWP 22472) 0x00007f489f5c76d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f489809ba30) + at ../sysdeps/unix/sysv/linux/futex-internal.h:205 + 12 Thread 0x7f4861d8b700 (LWP 22481) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f4861d8a680, expected=0, + futex_word=0x7f489801ed44) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + 13 Thread 0x7f48704ec700 (LWP 22477) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f48704eb910, expected=0, + futex_word=0x7f489801d120) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + 14 Thread 0x7f4870e6f700 (LWP 22476) 0x00007f489f5c4ed9 in futex_reltimed_wait_cancelable (private=<optimized out>, reltime=0x7f4870e6eb20, expected=0, + futex_word=0x7f489828abd0) + at ../sysdeps/unix/sysv/linux/futex-internal.h:142 + + + +Have you tried with KVM ("-M accel=kvm")? + +Please try "strace -o /var/tmp/java.log -f java -version" and upload the strace. If the strace is very large, it's probably safe to remove everything after around 10 seconds. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1862887 b/results/classifier/118/unknown/1862887 new file mode 100644 index 00000000..a2fdc62d --- /dev/null +++ b/results/classifier/118/unknown/1862887 @@ -0,0 +1,117 @@ +peripherals: 0.923 +register: 0.899 +device: 0.894 +KVM: 0.887 +hypervisor: 0.879 +VMM: 0.877 +vnc: 0.869 +permissions: 0.865 +ppc: 0.863 +debug: 0.855 +user-level: 0.852 +virtual: 0.849 +performance: 0.848 +semantic: 0.848 +mistranslation: 0.845 +assembly: 0.842 +network: 0.831 +files: 0.830 +x86: 0.830 +arm: 0.829 +architecture: 0.824 +socket: 0.821 +boot: 0.816 +kernel: 0.813 +PID: 0.802 +risc-v: 0.792 +TCG: 0.782 +graphic: 0.728 +i386: 0.723 + +qemu does not load pulseaudio modules properly + +Hello, + +This is on Arch-linux(latest) and the qemu 4.2.0 version made from git clone https://github.com/spheenik/qemu.git +with: + ./configure --prefix=/opt/qemu-test --python=/usr/bin/python2 --target-list=x86_64-softmmu +--audio-drv-list=pa --disable-werror +added to the build. + +I've been workin on a passthrough Windows 10 vm this month and have been steadily seeing some promising progress. My block/issue at the moment is integrating the audio now that the GPU has been succesfully passed through. +I've been going back and forth between the audio options for Pulseaudio and cannot change the following issue: +pulseaudio: pa_context_connect() failed +pulseaudio: Reason: Connection refused +pulseaudio: Failed to initialize PA contextlibusb: error [udev_hotplug_event] ignoring udev action bind +I leave my current operable build followed by some of the options that I have tried using to correct this despite the following errors not changing + +This is my current operable build: + +#!/bin/bash + +vmname="windows10vm" + +if ps -ef | grep /opt/qemu-test/bin/qemu-system-x86_64 | grep -q multifunction=on; then +echo "A passthrough VM is already running." & +exit 1 + +else + +/opt/qemu-test/bin/qemu-system-x86_64 \ +-m 12G \ +-drive id=disk0,if=virtio,cache=none,format=raw,file=.../win2.img \ +-drive file=.../Win10_1909_English_x64.iso,index=1,media=cdrom \ +-drive file=.../virtio-win-0.1.171.iso,index=2,media=cdrom \ +-boot order=dc \ +-bios /usr/share/ovmf/x64/OVMF_CODE.fd \ +-name $vmname,process=$vmname \ +-machine type=q35,accel=kvm,vmport=off \ +-cpu host,kvm=off \ +-smp 3,sockets=1,cores=3,threads=1 \ +-device virtio-balloon \ +-rtc clock=host,base=localtime \ +-vga none \ +-nographic \ +-serial none \ +-parallel none \ +-soundhw hda \ +-usb \ +-device usb-host,vendorid=...,productid=... \ +-device usb-host,vendorid=...,productid=... \ +-device usb-host,vendorid=...,productid=... \ +-device vfio-pci,host=...,multifunction=on \ +-device vfio-pci,host=... \ +-device e1000,netdev=net0 \ +-netdev user,id=net0,hostfwd=tcp::...-:22 \ + +Here's a list of setting combinations I had tried to resolve this: + +#export QEMU_AUDIO_DRV=pa +#QEMU_ALSA_DAC_BUFFER_SIZE=512 QEMU_ALSA_DAC_PERIOD_SIZE=170 +#export QEMU_PA_SAMPLES=8192 +#export QEMU_AUDIO_TIMER_PERIOD=99 +#export QEMU_PA_SERVER=/run/user/1000/pulse/native +#export QEMU_PA_SINK=alsa_output.usb-C-Media_Electronics_Inc._USB_Audio_Device-00.analog-stereo +#export QEMU_PA_SOURCE=input + +-audiodev pa,id=pa1,server=server=/run/user/1000/pulse/native + +At best I have removed an XDG_RUNTIME_DIR error but other than that this build has no audio compatability. + +EDIT: This is for Arch 2020.02.01 + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1874888 b/results/classifier/118/unknown/1874888 new file mode 100644 index 00000000..1adc7fb2 --- /dev/null +++ b/results/classifier/118/unknown/1874888 @@ -0,0 +1,130 @@ +user-level: 0.935 +TCG: 0.916 +risc-v: 0.909 +ppc: 0.906 +VMM: 0.896 +x86: 0.890 +KVM: 0.886 +peripherals: 0.885 +permissions: 0.879 +vnc: 0.863 +mistranslation: 0.862 +i386: 0.859 +hypervisor: 0.855 +architecture: 0.846 +assembly: 0.846 +files: 0.844 +register: 0.842 +device: 0.841 +arm: 0.839 +kernel: 0.835 +semantic: 0.831 +performance: 0.822 +boot: 0.814 +PID: 0.805 +graphic: 0.800 +debug: 0.797 +network: 0.777 +socket: 0.775 +virtual: 0.765 + +certain programs make QEMU crash with "tcg fatal error" + +The following code snippet crashes qemu with + +.../tcg/tcg.c:3279: tcg fatal error +qemu-x86_64: /usr/local/google/home/kostik/qemu-5.0.0-rc4/accel/tcg/cpu-exec.c:701: int cpu_exec(CPUState *): Assertion `!have_mmap_lock()' failed. + +================ +int main() { + /* +00000000 <.data>: + 0: 2e 45 71 ff cs rex.RB jno 0x3 + 4: e9 00 00 f0 00 jmp 0xf00009 + 9: c4 42 7d 31 3e vpmovzxbd ymm15,QWORD PTR [r14] + e: c4 a3 7d 08 64 82 44 vroundps ymm4,YMMWORD PTR [rdx+r8*4+0x44],0x0 + 15: 00 + 16: 0f 1e 0a nop DWORD PTR [rdx] + 19: 43 0f ec 20 rex.XB paddsb mm4,QWORD PTR [r8] + 1d: 66 47 0f 3a 0c 3d 00 rex.RXB blendps xmm15,XMMWORD PTR [rip+0x8000],0x0 # 0x8028 + 24: 80 00 00 00 + 28: c4 e3 f9 df 5f 86 0d vaeskeygenassist xmm3,XMMWORD PTR [rdi-0x7a],0xd + 2f: c4 e2 55 92 74 fc 0a vgatherdps ymm6,DWORD PTR [rsp+ymm7*8+0xa],ymm5 + 36: c4 e2 f9 17 9a 01 00 vptest xmm3,XMMWORD PTR [rdx+0x1] + 3d: 00 00 +*/ + char buf[] = { + 0x2E, 0x45, 0x71, 0xFF, 0xE9, 0x00, 0x00, 0xF0, 0x00, 0xC4, 0x42, 0x7D, 0x31, 0x3E, 0xC4, 0xA3, 0x7D, 0x08, 0x64, 0x82, 0x44, 0x00, 0x0F, 0x1E, 0x0A, 0x43, 0x0F, 0xEC, 0x20, 0x66, 0x47, 0x0F, 0x3A, 0x0C, 0x3D, 0x00, 0x80, 0x00, 0x00, 0x00, 0xC4, 0xE3, 0xF9, 0xDF, 0x5F, 0x86, 0x0D, 0xC4, 0xE2, 0x55, 0x92, 0x74, 0xFC, 0x0A, 0xC4, 0xE2, 0xF9, 0x17, 0x9A, 0x01, 0x00, 0x00, 0x00 + }; + void (*f)(void) = (void (*) (void))buf; + f(); + return 0; +} +================ +Steps to reproduce: +1) clang -static repro.c -o repro +2) qemu-x86_64-static repro + +Tested with 4.2.0 and 5.0.0-rc4. Both -user and -system variants are affected. + +A few more snippets that cause the same sort of behavior: +1) 0x64, 0x46, 0x7D, 0xFF, 0xDF, 0x27, 0x46, 0x0F, 0xD4, 0x83, 0x5E, 0x00, 0x00, 0x00, 0x3E, 0x0F, 0x6A, 0xEF, 0x0F, 0x05, 0xC4, 0x42, 0xFD, 0x1E, 0xCF, 0x46, 0x18, 0xE3, 0x47, 0xCD, 0x4E, 0x6E, 0x0F, 0x0F, 0x16, 0x8A + +2) 0x67, 0x45, 0xDB, 0xD0, 0xAA, 0xC4, 0xE2, 0xB1, 0x01, 0x57, 0x00, 0xF3, 0x6F, 0xF3, 0x42, 0x0F, 0x1E, 0xFD, 0x64, 0x2E, 0xF2, 0x45, 0xD9, 0xC4, 0x3E, 0xF3, 0x0F, 0xAE, 0xF4, 0x3E, 0x47, 0x0F, 0x1C, 0x22, 0x42, 0x73, 0xFF, 0xD9, 0xFD + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +Running with '-d in_asm' under gdb I get: + +---------------- +IN: +0x40007feef0: 2e 45 71 ff jno 0x40007feef3 + +---------------- +IN: +0x40007feef3: ff .byte 0xff +0x40007feef4: e9 .byte 0xe9 + + +Thread 1 "qemu-x86_64" received signal SIGILL, Illegal instruction. + +Thomas, could you migrate this to bug gitlab issues please? + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/683 + + diff --git a/results/classifier/118/unknown/1875139 b/results/classifier/118/unknown/1875139 new file mode 100644 index 00000000..218da077 --- /dev/null +++ b/results/classifier/118/unknown/1875139 @@ -0,0 +1,203 @@ +peripherals: 0.923 +virtual: 0.894 +hypervisor: 0.879 +ppc: 0.878 +KVM: 0.877 +register: 0.875 +architecture: 0.874 +x86: 0.873 +files: 0.870 +graphic: 0.864 +device: 0.860 +assembly: 0.859 +TCG: 0.859 +vnc: 0.858 +PID: 0.858 +arm: 0.858 +boot: 0.856 +kernel: 0.855 +performance: 0.854 +semantic: 0.848 +user-level: 0.847 +network: 0.841 +permissions: 0.841 +socket: 0.840 +debug: 0.838 +risc-v: 0.834 +i386: 0.833 +VMM: 0.818 +mistranslation: 0.804 + +Domain fails to start when 'readonly' device not writable + +This issue is introduced in QEMU 4.2.0 (4.1.0 is working fine) + +My root disk is a LVM2 volume thin snapshot that is marked as read-only +But when I try to start the domain (using virt-manager) I get the following error: + +Error starting domain: internal error: process exited while connecting to monitor: 2020-04-26T06:55:06.342700Z qemu-system-x86_64: -blockdev {"driver":"host_device","filename":"/dev/vg/vmroot-20200425","aio":"native","node-name":"libvirt-3-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} The device is not writable: Permission denied + +Changing the lvm snapshot to writeable allows me to start the domain. +(Making it changes possible during domain is running) + +I don't think QEMU should fail when it can't open a (block) device when the read-only option is set. +(why is write access needed?) + +Reproduce steps: +* Create LVM read-only volume (I don't think any data is needed) +* Create domain with read-only volume as block device +* Try to start the domain + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 66, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1279, in startup + self._backend.create() + File "/usr/lib/python3.7/site-packages/libvirt.py", line 1152, in create + if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2020-04-26T07:29:47.463835Z qemu-system-x86_64: -blockdev {"driver":"host_device","filename":"/var/lib/libvirt/vmportage/rootdisk","aio":"native","node-name":"libvirt-3-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}: The device is not writable: Permission denied + + +Can you provide the full guest XML for this - "/etc/libvirt/qemu/$GUESTNAME.xml", and also the full QEMU command line - "/var/log/libvirt/qemu/$GUESTNAME.xml". We need to see whether the disk is considered read-only from libvirt's POV. + +> This issue is introduced in QEMU 4.2.0 (4.1.0 is working fine) + +That's not neccessarily the case - with QEMU 4.2.0, libvirt switched over to using the new -blockdev command line syntax. When you were testing with 4.1.0, it would have been using the legacy -drive syntax. So the change in behaviour is more likely related to the usage of -blockdev, than any bug introduced in QEMU. + +The domain.xml: +<domain type='kvm'> + <name>rotest</name> + <uuid>b4aa0288-8886-42df-abfd-4c8f729e1330</uuid> + <memory unit='KiB'>2048000</memory> + <currentMemory unit='KiB'>2048000</currentMemory> + <vcpu placement='static'>2</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-2.7'>hvm</type> + <kernel>/var/lib/libvirt/pink/kernel</kernel> + <cmdline>root=/dev/sda ro panic=300 systemd.show_status=1 systemd.unit=graphical.target quiet</cmdline> + <boot dev='hd'/> + </os> + <features> + <acpi/> + </features> + <cpu mode='custom' match='exact' check='none'> + <model fallback='forbid'>qemu64</model> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw'/> + <source dev='/dev/nvmvg/rotest'/> + <target dev='sda' bus='scsi'/> + <readonly/> + <shareable/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source dev='/dev/nvmvg/rotest-var'/> + <target dev='sdb' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='pci' index='0' model='pci-root'/> + <controller type='scsi' index='0' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <controller type='usb' index='0' model='piix3-uhci'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice' autoport='yes'> + <listen type='address'/> + <gl enable='no' rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/> + </graphics> + <video> + <model type='virtio' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </memballoon> + </devices> +</domain> + +-------------------------------------------------------------------------------- + +The qemu command: +2020-04-27 11:57:11.720+0000: starting up libvirt version: 6.0.0, qemu version: 4.2.0, kernel: 5.4.28-gentoo, hostname: gentoo +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ +HOME=/var/lib/libvirt/qemu/domain-10-rotest \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-10-rotest/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-10-rotest/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-10-rotest/.config \ +QEMU_AUDIO_DRV=spice \ +/usr/bin/qemu-system-x86_64 \ +-name guest=rotest,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-10-rotest/master-key.aes \ +-machine pc-i440fx-2.7,accel=kvm,usb=off,dump-guest-core=off \ +-cpu qemu64 \ +-m 2000 \ +-overcommit mem-lock=off \ +-smp 2,sockets=2,cores=1,threads=1 \ +-uuid b4aa0288-8886-42df-abfd-4c8f729e1330 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=32,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-boot strict=on \ +-kernel /var/lib/libvirt/pink/kernel \ +-append 'root=/dev/sda ro panic=300 systemd.show_status=1 systemd.unit=graphical.target quiet' \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 \ +-blockdev '{"driver":"host_device","filename":"/dev/nvmvg/rotest","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":true,"driver":"raw","file":"libvirt-2-storage"}' \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,share-rw=on,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1 \ +-blockdev '{"driver":"host_device","filename":"/dev/nvmvg/rotest-var","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"}' \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=libvirt-1-format,id=scsi0-0-0-1,write-cache=on \ +-spice port=5900,addr=192.168.1.9,disable-ticketing,seamless-migration=on \ +-device virtio-vga,id=video0,max_outputs=1,bus=pci.0,addr=0x2 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2020-04-27T11:57:11.804028Z qemu-system-x86_64: -blockdev {"driver":"host_device","filename":"/dev/nvmvg/rotest","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}: The device is not writable: Permission denied +2020-04-27 11:57:11.805+0000: shutting down, reason=failed + +This was indeed caused by libvirt starting to use -blockdev. The issue is that qemu's 'auto-read-only' property which is used by libvirt for the backing files doesn't properly work if the 'host_device' backend encounters a read-only LV. + +The above situation also happens if you have an read-only LV in the backing chain. + +In the current upstream situation of qemu's APIs there currently isn't anything that libvirt can do in this case, because any solution would either not fix the problem completely or would require sacrificing other features, the auto-read-only property needs to be fixed in qemu. + +I've also filed https://bugzilla.redhat.com/show_bug.cgi?id=1828252 to track this issue. + +I saw that that the related issue was implemented in 5.1.0. + +So after I updated my QEMU to version 5.1.0. My VM(s) with a LVM read-only volume started again. + +Thanks for getting this issue solved. + + + + +If I've got that right, this issue got solved, so I'm closing it now. Please file a new ticket in our new tracker at gitlab.com if there is still a problem. + diff --git a/results/classifier/118/unknown/1878034 b/results/classifier/118/unknown/1878034 new file mode 100644 index 00000000..17c1610b --- /dev/null +++ b/results/classifier/118/unknown/1878034 @@ -0,0 +1,199 @@ +register: 0.821 +graphic: 0.810 +performance: 0.802 +files: 0.799 +arm: 0.799 +device: 0.797 +network: 0.788 +user-level: 0.777 +virtual: 0.777 +architecture: 0.774 +permissions: 0.773 +risc-v: 0.772 +KVM: 0.770 +peripherals: 0.770 +semantic: 0.768 +ppc: 0.762 +i386: 0.754 +mistranslation: 0.751 +debug: 0.745 +TCG: 0.743 +socket: 0.741 +x86: 0.736 +VMM: 0.732 +assembly: 0.730 +boot: 0.717 +vnc: 0.717 +PID: 0.712 +hypervisor: 0.710 +kernel: 0.708 + +memcpy param-overlap through e1000e_write_to_rx_buffers + +Hello, +While fuzzing, I found an input that triggers an overlapping memcpy (caught by AddressSanitizer). +Overlapping memcpys are undefined behavior according to the POSIX and C standards, and can lead to bugs. + +==22287==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges +#0 0x563c9f4823d4 in __asan_memcpy (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x97a3d4) +#1 0x563c9f4cb2b1 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3142:13 +#2 0x563c9f4c3b97 in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 +#3 0x563c9f4c3b97 in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 +#4 0x563c9fbc457b in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:87:18 +#5 0x563c9fbc457b in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:110:12 +#6 0x563c9fbc457b in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:787:5 +#7 0x563c9fbc457b in pci_dma_write /home/alxndr/Development/qemu/include/hw/pci/pci.h:800:12 +#8 0x563c9fbc457b in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1412:9 +#9 0x563c9fbb9c98 in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1582:21 +#10 0x563c9fbb9c98 in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709:9 +#11 0x563c9fba8080 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544:9 +#12 0x563c9fba8080 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620:9 +#13 0x563c9fba8827 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633:11 +#14 0x563c9fbd2052 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16 +#15 0x563c9fbd2052 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17 +#16 0x563c9fbd2052 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9 +#17 0x563c9fbcecf0 in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9 +#18 0x563c9fbbf20c in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261:9 +#19 0x563c9f5b68d6 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 +#20 0x563c9f5b627f in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 +#21 0x563c9f5b627f in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 + +I can reproduce it in qemu 5.0 built with --enable-sanitizers using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe102003a 0x3ff 0xd1055e2d3b0002e10000000001ffd3055e2d3b0002e10000000001ffd5055e2d3b0002e10000000001ffd7055e2d3b0002e10000000001ffd9055e2d3b0002e10000000001ffdb055e2d3b0002e10000000001ffdd055e2d3b0002e10000000001ffdf055e2d3b0002e10000000001ffe1055e2d3b0002e10000000001ffe3055e2d3b0002e10000000001ffe5055e2d3b0002e10000000001ffe7055e2d3b0002e10000000001ffe9055e2d3b0002e10000000001ffeb055e2d3b0002e10000000001ffed055e2d3b0002e10000000001ffef055e2d3b0002e10000000001fff1055e2d3b0002e10000000001fff3055e2d3b0002e10000000001fff5055e2d3b0002e10000000001fff7055e2d3b0002e10000000001fff9055e2d3b0002e10000000001fffb055e2d3b0002e10000000001fffd055e2d3b0002e10000000001ffff055e2d3b0002e10000000001ff01055e2d3b0002e10000000001ff03055e2d3b0002e10000000001ff05055e2d3b0002e10000000001ff07055e2d3b0002e10000000001ff09055e2d3b0002e10000000001ff0b055e2d3b0002e10000000001ff0d055e2d3b0002e10000000001ff0f055e2d3b0002e10000000001ff11055e2d3b0002e10000000001ff13055e2d3b0002e10000000001ff15055e2d3b0002e10000000001ff17055e2d3b0002e10000000001ff19055e2d3b0002e10000000001ff1b055e2d3b0002e10000000001ff1d055e2d3b0002e10000000001ff1f055e2d3b0002e10000000001ff21055e2d3b0002e10000000001ff23055e2d3b0002e10000000001ff25055e2d3b0002e10000000001ff27055e2d3b0002e10000000001ff29055e2d3b0002e10000000001ff2b055e2d3b0002e10000000001ff2d055e2d3b0002e10000000001ff2f055e2d3b0002e10000000001ff31055e2d3b0002e10000000001ff33055e2d3b0002e10000000001ff35055e2d3b0002e10000000001ff37055e2d3b0002e10000000001ff39055e2d3b0002e10000000001ff3b055e2d3b0002e10000000001ff3d055e2d3b0002e10000000001ff3f055e2d3b0002e10000000001ff41055e2d3b0002e10000000001ff43055e2d3b0002e10000000001ff45055e2d3b0002e10000000001ff47055e2d3b0002e10000000001ff49055e2d3b0002e10000000001ff4b055e2d3b0002e10000000001ff4d055e2d3b0002e10000000001ff4f055e2d3b0002e10000000001ff51055e2d3b0002e10000000001ff53055e2d3b0002e10000000001ff55055e2d3b0002e10000000001ff57055e2d3b0002e10000000001ff59055e2d3b0002e10000000001ff5b055e2d3b0002e10000000001ff5d055e2d3b0002e10000000001ff5f055e2d3b0002e10000000001ff61055e2d3b0002e10000000001ff63 +EOF + +I also attached the trace to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex + + + +Can you still reproduce the crash with the current version of QEMU? At least I cannot reproduce the crash anymore, so it seems like this got fixed at one point in time? + +Seems to still be a problem. Here's the reproducer found by OSS-Fuzz: +https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29586 + +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +512M -M q35 -nodefaults -device e1000e,netdev=net0 -netdev user,id=net0 \ +-qtest /dev/null -qtest stdio +outl 0xcf8 0x80000811 +outl 0xcfc 0x5ac600 +outl 0xcf8 0x80000801 +outl 0xcfc 0x06000000 +write 0x5ac60100 0x4 0x56000302 +write 0x5ac6011a 0x2 0x0106 +write 0x5ac60120 0x1 0x25 +write 0x5ac6042a 0x2 0x0248 +write 0x5ac60431 0x1 0x04 +write 0x4240 0x1 0xff +write 0x4241 0x1 0x01 +write 0x4249 0x1 0xf5 +write 0x1ff 0x1 0x01 +write 0x5ac60403 0x1 0x02 +write 0x5ac6043a 0x2 0x2800 +write 0x5ac60112 0x2 0xf090 +write 0x5ac60430 0x1 0x00 +write 0x239 0x1 0xff +write 0x23b 0x1 0x01 +write 0x9531 0x1 0xff +write 0x9532 0x1 0xff +write 0x9533 0x1 0xff +write 0x9534 0x1 0xff +write 0x9535 0x1 0xff +write 0x9536 0x1 0xff +write 0x9537 0x1 0xff +write 0x5ac60403 0x1 0x02 +EOF + + +On 210525 0820, Thomas Huth wrote: +> Can you still reproduce the crash with the current version of QEMU? At +> least I cannot reproduce the crash anymore, so it seems like this got +> fixed at one point in time? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1878034 +> +> Title: +> memcpy param-overlap through e1000e_write_to_rx_buffers +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Hello, +> While fuzzing, I found an input that triggers an overlapping memcpy (caught by AddressSanitizer). +> Overlapping memcpys are undefined behavior according to the POSIX and C standards, and can lead to bugs. +> +> ==22287==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges +> #0 0x563c9f4823d4 in __asan_memcpy (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x97a3d4) +> #1 0x563c9f4cb2b1 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3142:13 +> #2 0x563c9f4c3b97 in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 +> #3 0x563c9f4c3b97 in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 +> #4 0x563c9fbc457b in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:87:18 +> #5 0x563c9fbc457b in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:110:12 +> #6 0x563c9fbc457b in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:787:5 +> #7 0x563c9fbc457b in pci_dma_write /home/alxndr/Development/qemu/include/hw/pci/pci.h:800:12 +> #8 0x563c9fbc457b in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1412:9 +> #9 0x563c9fbb9c98 in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1582:21 +> #10 0x563c9fbb9c98 in e1000e_receive_iov /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709:9 +> #11 0x563c9fba8080 in net_tx_pkt_sendv /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544:9 +> #12 0x563c9fba8080 in net_tx_pkt_send /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620:9 +> #13 0x563c9fba8827 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633:11 +> #14 0x563c9fbd2052 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664:16 +> #15 0x563c9fbd2052 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17 +> #16 0x563c9fbd2052 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9 +> #17 0x563c9fbcecf0 in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9 +> #18 0x563c9fbbf20c in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261:9 +> #19 0x563c9f5b68d6 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 +> #20 0x563c9f5b627f in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 +> #21 0x563c9f5b627f in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 +> +> I can reproduce it in qemu 5.0 built with --enable-sanitizers using: +> cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none +> outl 0xcf8 0x80001010 +> outl 0xcfc 0xe1020000 +> outl 0xcf8 0x80001014 +> outl 0xcf8 0x80001004 +> outw 0xcfc 0x7 +> outl 0xcf8 0x800010a2 +> write 0xe102003a 0x3ff 0xd1055e2d3b0002e10000000001ffd3055e2d3b0002e10000000001ffd5055e2d3b0002e10000000001ffd7055e2d3b0002e10000000001ffd9055e2d3b0002e10000000001ffdb055e2d3b0002e10000000001ffdd055e2d3b0002e10000000001ffdf055e2d3b0002e10000000001ffe1055e2d3b0002e10000000001ffe3055e2d3b0002e10000000001ffe5055e2d3b0002e10000000001ffe7055e2d3b0002e10000000001ffe9055e2d3b0002e10000000001ffeb055e2d3b0002e10000000001ffed055e2d3b0002e10000000001ffef055e2d3b0002e10000000001fff1055e2d3b0002e10000000001fff3055e2d3b0002e10000000001fff5055e2d3b0002e10000000001fff7055e2d3b0002e10000000001fff9055e2d3b0002e10000000001fffb055e2d3b0002e10000000001fffd055e2d3b0002e10000000001ffff055e2d3b0002e10000000001ff01055e2d3b0002e10000000001ff03055e2d3b0002e10000000001ff05055e2d3b0002e10000000001ff07055e2d3b0002e10000000001ff09055e2d3b0002e10000000001ff0b055e2d3b0002e10000000001ff0d055e2d3b0002e10000000001ff0f055e2d3b0002e10000000001ff11055e2d3b0002e10000000001ff13055e2d3b0002e10000000001ff15055e2d3b0002e10000000001ff17055e2d3b0002e10000000001ff19055e2d3b0002e10000000001ff1b055e2d3b0002e10000000001ff1d055e2d3b0002e10000000001ff1f055e2d3b0002e10000000001ff21055e2d3b0002e10000000001ff23055e2d3b0002e10000000001ff25055e2d3b0002e10000000001ff27055e2d3b0002e10000000001ff29055e2d3b0002e10000000001ff2b055e2d3b0002e10000000001ff2d055e2d3b0002e10000000001ff2f055e2d3b0002e10000000001ff31055e2d3b0002e10000000001ff33055e2d3b0002e10000000001ff35055e2d3b0002e10000000001ff37055e2d3b0002e10000000001ff39055e2d3b0002e10000000001ff3b055e2d3b0002e10000000001ff3d055e2d3b0002e10000000001ff3f055e2d3b0002e10000000001ff41055e2d3b0002e10000000001ff43055e2d3b0002e10000000001ff45055e2d3b0002e10000000001ff47055e2d3b0002e10000000001ff49055e2d3b0002e10000000001ff4b055e2d3b0002e10000000001ff4d055e2d3b0002e10000000001ff4f055e2d3b0002e10000000001ff51055e2d3b0002e10000000001ff53055e2d3b0002e10000000001ff55055e2d3b0002e10000000001ff57055e2d3b0002e10000000001ff59055e2d3b0002e10000000001ff5b055e2d3b0002e10000000001ff5d055e2d3b0002e10000000001ff5f055e2d3b0002e10000000001ff61055e2d3b0002e10000000001ff63 +> EOF +> +> I also attached the trace to this launchpad report, in case the +> formatting is broken: +> +> qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic +> -monitor none -serial none < attachment +> +> Please let me know if I can provide any further info. +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1878034/+subscriptions + + +Ok, confirmed, with that new reproducer it also detects the error here when I compile QEMU with Clang and ASAN enabled. + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/534 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + diff --git a/results/classifier/118/unknown/1878067 b/results/classifier/118/unknown/1878067 new file mode 100644 index 00000000..683ffbd0 --- /dev/null +++ b/results/classifier/118/unknown/1878067 @@ -0,0 +1,218 @@ +permissions: 0.907 +graphic: 0.905 +user-level: 0.904 +files: 0.902 +performance: 0.892 +semantic: 0.881 +architecture: 0.881 +virtual: 0.874 +arm: 0.871 +device: 0.869 +assembly: 0.867 +register: 0.865 +KVM: 0.865 +debug: 0.862 +risc-v: 0.857 +PID: 0.854 +mistranslation: 0.847 +ppc: 0.833 +kernel: 0.833 +VMM: 0.833 +x86: 0.827 +network: 0.820 +vnc: 0.817 +TCG: 0.804 +boot: 0.797 +socket: 0.795 +hypervisor: 0.770 +i386: 0.766 +peripherals: 0.752 + +Assertion failure in eth_get_gso_type through the e1000e + +Hello, +While fuzzing, I found an input that triggers an assertion failure in +eth_get_gso_type through the e1000e: + +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x00007ffff7c75dc3 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#3 0x00007ffff7cd0b0a in g_assertion_message_expr () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#4 0x0000555556875f33 in eth_get_gso_type (l3_proto=<optimized out>, l3_hdr=<optimized out>, l4proto=<optimized out>) at /home/alxndr/Development/qemu/net/eth.c:76 +#5 0x00005555565e09ac in net_tx_pkt_get_gso_type (pkt=0x631000014800, tso_enable=0x1) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:300 +#6 0x00005555565e09ac in net_tx_pkt_build_vheader (pkt=0x631000014800, tso_enable=<optimized out>, csum_enable=<optimized out>, gso_size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:316 +#7 0x000055555660bdb1 in e1000e_setup_tx_offloads (core=0x7fffeeb754e0, tx=0x7fffeeb95748) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:637 +#8 0x000055555660bdb1 in e1000e_tx_pkt_send (core=0x7fffeeb754e0, tx=0x7fffeeb95748, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:658 +#9 0x000055555660bdb1 in e1000e_process_tx_desc (core=0x7fffeeb754e0, tx=0x7fffeeb95748, dp=<optimized out>, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#10 0x000055555660bdb1 in e1000e_start_xmit (core=core@entry=0x7fffeeb754e0, txr=<optimized out>, txr@entry=0x7fffffffbe60) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#11 0x0000555556607e2e in e1000e_set_tctl (core=0x7fffeeb754e0, index=<optimized out>, val=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2431 +#12 0x00005555565f90fd in e1000e_core_write (core=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#13 0x0000555555ff4337 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#14 0x0000555555ff3ce0 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x7fffeeb75110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#15 0x0000555555ff3ce0 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x2b, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 + +I can reproduce it in qemu 5.0 built with using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 -display none -nodefaults -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000814 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +outl 0xcf8 0x800008a2 +write 0xe0000420 0x1fc 0x3ff9ffdf00000000002467ff272d2f3ff9ffdf0000000000246fff272d2f3ff9ffdf00000000002477ff272d2f3ff9ffdf0000000000247fff272d2f3ff9ffdf00000000002487ff272d2f3ff9ffdf0000000000248fff272d2f3ff9ffdf00000000002497ff272d2f3ff9ffdf0000000000249fff272d2f3ff9ffdf000000000024a7ff272d2f3ff9ffdf000000000024afff272d2f3ff9ffdf000000000024b7ff272d2f3ff9ffdf000000000024bfff272d2f3ff9ffdf000000000024c7ff272d2f3ff9ffdf000000000024cfff272d2f3ff9ffdf000000000024d7ff272d2f3ff9ffdf000000000024dfff272d2f3ff9ffdf000000000024e7ff272d2f3ff9ffdf000000000024efff272d2f3ff9ffdf000000000024f7ff272d2f3ff9ffdf000000000024ffff272d2f3ff9ffdf00000000002407ff272d2f3ff9ffdf0000000000240fff272d2f3ff9ffdf00000000002417ff272d2f3ff9ffdf0000000000241fff272d2f3ff9ffdf00000000002427ff272d2f3ff9ffdf0000000000242fff272d2f3ff9ffdf00000000002437ff272d2f3ff9ffdf0000000000243fff272d2f3ff9ffdf00000000002447ff272d2f3ff9ffdf0000000000244fff272d2f3ff9ffdf00000000002457ff272d2f3ff9ffdf0000000000245fff272d2f3ff9ffdf00000000002467ff272d2f3ff9ffdf0000000000246fff27 +write 0xe00000b8 0x349 0xa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52b +EOF + +I also attached the trace to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 -display none -nodefaults -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex + + + +Here is a shorter reporoducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 -qtest stdio -monitor none -serial none -M pc-q35-5.0 -nographic +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe1020420 0x4 0xffffffff +write 0xe1020424 0x4 0xffffffff +write 0xe1025008 0x4 0x05d88600 +write 0xe1020103 0x26 0xffffff00ffffffffffffef56ffffffffffffffffffffffffffffffffffffff00ffffffffffff +write 0xe1020403 0x1 0xff +write 0xe102042a 0xf 0xffffffffffffffff00ffffffffffffe +EOF + +Cc'ing Dmitry + +On 5/11/20 8:04 PM, Alexander Bulekov wrote: +> Public bug reported: +> +> Hello, +> While fuzzing, I found an input that triggers an assertion failure in +> eth_get_gso_type through the e1000e: +> +> #1 0x00007ffff685755b in __GI_abort () at abort.c:79 +> #2 0x00007ffff7c75dc3 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #3 0x00007ffff7cd0b0a in g_assertion_message_expr () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #4 0x0000555556875f33 in eth_get_gso_type (l3_proto=<optimized out>, l3_hdr=<optimized out>, l4proto=<optimized out>) at /home/alxndr/Development/qemu/net/eth.c:76 +> #5 0x00005555565e09ac in net_tx_pkt_get_gso_type (pkt=0x631000014800, tso_enable=0x1) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:300 +> #6 0x00005555565e09ac in net_tx_pkt_build_vheader (pkt=0x631000014800, tso_enable=<optimized out>, csum_enable=<optimized out>, gso_size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:316 +> #7 0x000055555660bdb1 in e1000e_setup_tx_offloads (core=0x7fffeeb754e0, tx=0x7fffeeb95748) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:637 +> #8 0x000055555660bdb1 in e1000e_tx_pkt_send (core=0x7fffeeb754e0, tx=0x7fffeeb95748, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:658 +> #9 0x000055555660bdb1 in e1000e_process_tx_desc (core=0x7fffeeb754e0, tx=0x7fffeeb95748, dp=<optimized out>, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +> #10 0x000055555660bdb1 in e1000e_start_xmit (core=core@entry=0x7fffeeb754e0, txr=<optimized out>, txr@entry=0x7fffffffbe60) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +> #11 0x0000555556607e2e in e1000e_set_tctl (core=0x7fffeeb754e0, index=<optimized out>, val=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2431 +> #12 0x00005555565f90fd in e1000e_core_write (core=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +> #13 0x0000555555ff4337 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +> #14 0x0000555555ff3ce0 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x7fffeeb75110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +> #15 0x0000555555ff3ce0 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x2b, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +> +> I can reproduce it in qemu 5.0 built with using: +> cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 -display none -nodefaults -nographic -qtest stdio -monitor none -serial none +> outl 0xcf8 0x80000810 +> outl 0xcfc 0xe0000000 +> outl 0xcf8 0x80000814 +> outl 0xcf8 0x80000804 +> outw 0xcfc 0x7 +> outl 0xcf8 0x800008a2 +> write 0xe0000420 0x1fc 0x3ff9ffdf00000000002467ff272d2f3ff9ffdf0000000000246fff272d2f3ff9ffdf00000000002477ff272d2f3ff9ffdf0000000000247fff272d2f3ff9ffdf00000000002487ff272d2f3ff9ffdf0000000000248fff272d2f3ff9ffdf00000000002497ff272d2f3ff9ffdf0000000000249fff272d2f3ff9ffdf000000000024a7ff272d2f3ff9ffdf000000000024afff272d2f3ff9ffdf000000000024b7ff272d2f3ff9ffdf000000000024bfff272d2f3ff9ffdf000000000024c7ff272d2f3ff9ffdf000000000024cfff272d2f3ff9ffdf000000000024d7ff272d2f3ff9ffdf000000000024dfff272d2f3ff9ffdf000000000024e7ff272d2f3ff9ffdf000000000024efff272d2f3ff9ffdf000000000024f7ff272d2f3ff9ffdf000000000024ffff272d2f3ff9ffdf00000000002407ff272d2f3ff9ffdf0000000000240fff272d2f3ff9ffdf00000000002417ff272d2f3ff9ffdf0000000000241fff272d2f3ff9ffdf00000000002427ff272d2f3ff9ffdf0000000000242fff272d2f3ff9ffdf00000000002437ff272d2f3ff9ffdf0000000000243fff272d2f3ff9ffdf00000000002447ff272d2f3ff9ffdf0000000000244fff272d2f3ff9ffdf00000000002457ff272d2f3ff9ffdf0000000000245fff272d2f3ff9ffdf00000000002467ff272d2f3ff9ffdf0000000000246fff27 +> write 0xe00000b8 0x349 0xa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52b +> EOF +> +> I also attached the trace to this launchpad report, in case the +> formatting is broken: +> +> qemu-system-i386 -M pc-q35-5.0 -netdev user,id=qtest-bn0 -device +> e1000e,netdev=qtest-bn0 -display none -nodefaults -nographic -qtest +> stdio -monitor none -serial none < attachment +> +> Please let me know if I can provide any further info. +> -Alex +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> ** Attachment added: "attachment" +> https://bugs.launchpad.net/bugs/1878067/+attachment/5369990/+files/attachment +> + + + +I can reproduce this with QEMU v5.0, but with the current master branch, the problem seems to be gone for me. Can you confirm that it is fixed? + +Yes - looks like it was fixed in +7564bf7701 ("net: remove an assert call in eth_get_gso_type") + +On 210525 0953, Thomas Huth wrote: +> I can reproduce this with QEMU v5.0, but with the current master branch, +> the problem seems to be gone for me. Can you confirm that it is fixed? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1878067 +> +> Title: +> Assertion failure in eth_get_gso_type through the e1000e +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Hello, +> While fuzzing, I found an input that triggers an assertion failure in +> eth_get_gso_type through the e1000e: +> +> #1 0x00007ffff685755b in __GI_abort () at abort.c:79 +> #2 0x00007ffff7c75dc3 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #3 0x00007ffff7cd0b0a in g_assertion_message_expr () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +> #4 0x0000555556875f33 in eth_get_gso_type (l3_proto=<optimized out>, l3_hdr=<optimized out>, l4proto=<optimized out>) at /home/alxndr/Development/qemu/net/eth.c:76 +> #5 0x00005555565e09ac in net_tx_pkt_get_gso_type (pkt=0x631000014800, tso_enable=0x1) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:300 +> #6 0x00005555565e09ac in net_tx_pkt_build_vheader (pkt=0x631000014800, tso_enable=<optimized out>, csum_enable=<optimized out>, gso_size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:316 +> #7 0x000055555660bdb1 in e1000e_setup_tx_offloads (core=0x7fffeeb754e0, tx=0x7fffeeb95748) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:637 +> #8 0x000055555660bdb1 in e1000e_tx_pkt_send (core=0x7fffeeb754e0, tx=0x7fffeeb95748, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:658 +> #9 0x000055555660bdb1 in e1000e_process_tx_desc (core=0x7fffeeb754e0, tx=0x7fffeeb95748, dp=<optimized out>, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +> #10 0x000055555660bdb1 in e1000e_start_xmit (core=core@entry=0x7fffeeb754e0, txr=<optimized out>, txr@entry=0x7fffffffbe60) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +> #11 0x0000555556607e2e in e1000e_set_tctl (core=0x7fffeeb754e0, index=<optimized out>, val=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2431 +> #12 0x00005555565f90fd in e1000e_core_write (core=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +> #13 0x0000555555ff4337 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +> #14 0x0000555555ff3ce0 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x7fffeeb75110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +> #15 0x0000555555ff3ce0 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=0x2b, op=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +> +> I can reproduce it in qemu 5.0 built with using: +> cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 -display none -nodefaults -nographic -qtest stdio -monitor none -serial none +> outl 0xcf8 0x80000810 +> outl 0xcfc 0xe0000000 +> outl 0xcf8 0x80000814 +> outl 0xcf8 0x80000804 +> outw 0xcfc 0x7 +> outl 0xcf8 0x800008a2 +> write 0xe0000420 0x1fc 0x3ff9ffdf00000000002467ff272d2f3ff9ffdf0000000000246fff272d2f3ff9ffdf00000000002477ff272d2f3ff9ffdf0000000000247fff272d2f3ff9ffdf00000000002487ff272d2f3ff9ffdf0000000000248fff272d2f3ff9ffdf00000000002497ff272d2f3ff9ffdf0000000000249fff272d2f3ff9ffdf000000000024a7ff272d2f3ff9ffdf000000000024afff272d2f3ff9ffdf000000000024b7ff272d2f3ff9ffdf000000000024bfff272d2f3ff9ffdf000000000024c7ff272d2f3ff9ffdf000000000024cfff272d2f3ff9ffdf000000000024d7ff272d2f3ff9ffdf000000000024dfff272d2f3ff9ffdf000000000024e7ff272d2f3ff9ffdf000000000024efff272d2f3ff9ffdf000000000024f7ff272d2f3ff9ffdf000000000024ffff272d2f3ff9ffdf00000000002407ff272d2f3ff9ffdf0000000000240fff272d2f3ff9ffdf00000000002417ff272d2f3ff9ffdf0000000000241fff272d2f3ff9ffdf00000000002427ff272d2f3ff9ffdf0000000000242fff272d2f3ff9ffdf00000000002437ff272d2f3ff9ffdf0000000000243fff272d2f3ff9ffdf00000000002447ff272d2f3ff9ffdf0000000000244fff272d2f3ff9ffdf00000000002457ff272d2f3ff9ffdf0000000000245fff272d2f3ff9ffdf00000000002467ff272d2f3ff9ffdf0000000000246fff27 +> write 0xe00000b8 0x349 0xa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52bff003100ffa300f52b +> EOF +> +> I also attached the trace to this launchpad report, in case the +> formatting is broken: +> +> qemu-system-i386 -M pc-q35-5.0 -netdev user,id=qtest-bn0 -device +> e1000e,netdev=qtest-bn0 -display none -nodefaults -nographic -qtest +> stdio -monitor none -serial none < attachment +> +> Please let me know if I can provide any further info. +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1878067/+subscriptions + + +Ok, thanks for checking! So let's close this ticket now. + diff --git a/results/classifier/118/unknown/1878642 b/results/classifier/118/unknown/1878642 new file mode 100644 index 00000000..4404c184 --- /dev/null +++ b/results/classifier/118/unknown/1878642 @@ -0,0 +1,87 @@ +peripherals: 0.866 +x86: 0.852 +KVM: 0.847 +hypervisor: 0.838 +i386: 0.832 +risc-v: 0.828 +VMM: 0.826 +user-level: 0.817 +vnc: 0.817 +virtual: 0.808 +TCG: 0.808 +mistranslation: 0.805 +graphic: 0.802 +ppc: 0.800 +performance: 0.786 +device: 0.783 +semantic: 0.779 +register: 0.778 +network: 0.776 +arm: 0.775 +architecture: 0.774 +debug: 0.772 +socket: 0.772 +permissions: 0.771 +files: 0.766 +assembly: 0.759 +kernel: 0.743 +PID: 0.736 +boot: 0.722 + +Assertion failure in pci_bus_get_irq_level + +Hello, +I found an input which triggers an assertion failure in pci_bus_get_irq_level: + +qemu-system-i386: /home/alxndr/Development/qemu/hw/pci/pci.c:268: int pci_bus_get_irq_level(PCIBus *, int): Assertion `irq_num < bus->nirq' failed. +Aborted +#0 0x00007ffff686d761 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x00007ffff685755b in __GI_abort () at abort.c:79 +#2 0x00007ffff685742f in __assert_fail_base (fmt=0x7ffff69bdb48 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x555557f9bca0 <str> "irq_num < bus->nirq", file=0x555557f9bbe0 <str> "/home/alxndr/Development/qemu/hw/pci/pci.c", line=0x10c, function=<optimized out>) at assert.c:92 +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555557f9bca0 <str> "irq_num < bus->nirq", file=0x555557f9bbe0 <str> "/home/alxndr/Development/qemu/hw/pci/pci.c", line=0x10c, function=0x555557f9bc40 <__PRETTY_FUNCTION__.pci_bus_get_irq_level> "int pci_bus_get_irq_level(PCIBus *, int)") at assert.c:101 +#4 0x0000555557060c34 in pci_bus_get_irq_level (bus=0x61d000096080, irq_num=0xef) at /home/alxndr/Development/qemu/hw/pci/pci.c:268 +#5 0x0000555556657391 in ich9_lpc_update_apic (lpc=0x62a000006200, gsi=0xff) at /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:249 +#6 0x0000555556658ea7 in ich9_set_sci (opaque=0x62a000006200, irq_num=0x0, level=0x1) at /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:354 +#7 0x0000555556ccefc6 in qemu_set_irq (irq=0x60600002af80, level=0x1) at /home/alxndr/Development/qemu/hw/core/irq.c:44 +#8 0x0000555556bc06fd in acpi_update_sci (regs=0x62a000006c80, irq=0x60600002af80) at /home/alxndr/Development/qemu/hw/acpi/core.c:723 +#9 0x0000555556bccb08 in ich9_pm_update_sci_fn (regs=0x62a000006c80) at /home/alxndr/Development/qemu/hw/acpi/ich9.c:56 +#10 0x0000555556bc10ee in acpi_pm_evt_write (opaque=0x62a000006c80, addr=0x2, val=0x2049, width=0x2) at /home/alxndr/Development/qemu/hw/acpi/core.c:456 +#11 0x00005555564938b5 in memory_region_write_accessor (mr=0x62a000006db0, addr=0x2, value=0x7fffffff9c70, size=0x2, shift=0x0, mask=0xffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#12 0x000055555649328a in access_with_adjusted_size (addr=0x2, value=0x7fffffff9c70, size=0x2, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x62a000006db0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#13 0x0000555556491df6 in memory_region_dispatch_write (mr=0x62a000006db0, addr=0x2, data=0x2049, op=MO_16, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#14 0x00005555562cbbf4 in flatview_write_continue (fv=0x606000033fe0, addr=0x5d02, attrs=..., ptr=0x7fffffffa4e0, len=0x4, addr1=0x2, l=0x2, mr=0x62a000006db0) at /home/alxndr/Development/qemu/exec.c:3137 +#15 0x00005555562bbad9 in flatview_write (fv=0x606000033fe0, addr=0x5d02, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3177 +#16 0x00005555562bb609 in address_space_write (as=0x55555968f940 <address_space_io>, addr=0x5d02, attrs=..., buf=0x7fffffffa4e0, len=0x4) at /home/alxndr/Development/qemu/exec.c:3268 +#17 0x0000555556478c0a in cpu_outl (addr=0x5d02, val=0xedf82049) at /home/alxndr/Development/qemu/ioport.c:80 +#18 0x000055555648166f in qtest_process_command (chr=0x555559691d00 <qtest_chr>, words=0x60300009ef20) at /home/alxndr/Development/qemu/qtest.c:396 +#19 0x000055555647f187 in qtest_process_inbuf (chr=0x555559691d00 <qtest_chr>, inbuf=0x61900000f680) at /home/alxndr/Development/qemu/qtest.c:710 +#20 0x000055555647e8b4 in qtest_read (opaque=0x555559691d00 <qtest_chr>, buf=0x7fffffffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", size=0xe9) at /home/alxndr/Development/qemu/qtest.c:722 +#21 0x00005555579c260c in qemu_chr_be_write_impl (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", len=0xe9) at /home/alxndr/Development/qemu/chardev/char.c:183 +#22 0x00005555579c275b in qemu_chr_be_write (s=0x60f000001f30, buf=0x7fffffffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", len=0xe9) at /home/alxndr/Development/qemu/chardev/char.c:195 +#23 0x00005555579cb97a in fd_chr_read (chan=0x6080000026a0, cond=G_IO_IN, opaque=0x60f000001f30) at /home/alxndr/Development/qemu/chardev/char-fd.c:68 +#24 0x0000555557a530ea in qio_channel_fd_source_dispatch (source=0x60c00002ef00, callback=0x5555579cb540 <fd_chr_read>, user_data=0x60f000001f30) at /home/alxndr/Development/qemu/io/channel-watch.c:84 +#25 0x00007ffff7ca8898 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#26 0x0000555557c10b85 in glib_pollfds_poll () at /home/alxndr/Development/qemu/util/main-loop.c:219 +#27 0x0000555557c0f57e in os_host_main_loop_wait (timeout=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:242 +#28 0x0000555557c0f177 in main_loop_wait (nonblocking=0x0) at /home/alxndr/Development/qemu/util/main-loop.c:518 +#29 0x000055555689fd1e in qemu_main_loop () at /home/alxndr/Development/qemu/softmmu/vl.c:1664 +#30 0x0000555557a6a29d in main (argc=0x17, argv=0x7fffffffe148, envp=0x7fffffffe208) at /home/alxndr/Development/qemu/softmmu/main.c:49 + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x8400f841 +outl 0xcfc 0xebed205d +outl 0x5d02 0xedf82049 +EOF + +Please let me know if I can provide any further info. +-Alex + +Proposed fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05564.html + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/unknown/1879223 b/results/classifier/118/unknown/1879223 new file mode 100644 index 00000000..5ca37d57 --- /dev/null +++ b/results/classifier/118/unknown/1879223 @@ -0,0 +1,97 @@ +peripherals: 0.860 +user-level: 0.840 +VMM: 0.837 +KVM: 0.836 +x86: 0.827 +mistranslation: 0.827 +hypervisor: 0.815 +vnc: 0.813 +risc-v: 0.811 +i386: 0.800 +TCG: 0.789 +virtual: 0.786 +ppc: 0.784 +graphic: 0.779 +files: 0.776 +permissions: 0.760 +device: 0.752 +performance: 0.752 +semantic: 0.751 +architecture: 0.749 +assembly: 0.748 +register: 0.746 +socket: 0.739 +PID: 0.730 +arm: 0.728 +debug: 0.725 +network: 0.720 +kernel: 0.715 +boot: 0.694 + +Assertion failure in e1000e_write_rx_descr + +Hello, +While fuzzing, I found an input which triggers an assertion failure in +e1000e_write_rx_descr: + +qemu-system-i386: /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1359: void e1000e_write_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, size_t, uint16_t (*)[4]): Assertion `ps_hdr_len == 0' failed. +Aborted +#3 0x00007ffff684d092 in __GI___assert_fail (assertion=0x5555583703e0 <str> "ps_hdr_len == 0", file=0x555558361080 <str> "/home/alxndr/Development/qemu/hw/net/e1000e_core.c", line=0x54f, function=0x555558370420 <__PRETTY_FUNCTION__.e1000e_write_rx_descr> "void e1000e_write_rx_descr(E1000ECore *, uint8_t *, struct NetRxPkt *, const E1000E_RSSInfo *, size_t, uint16_t (*)[4])") at assert.c:101 +#4 0x0000555557206a58 in e1000e_write_rx_descr (core=0x7fffee0dd4e0, desc=0x7fffffff8720 "", pkt=0x0, rss_info=0x7fffffff8c50, ps_hdr_len=0x2a, written=0x7fffffff87c0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1359 +#5 0x00005555571f8507 in e1000e_write_packet_to_guest (core=0x7fffee0dd4e0, pkt=0x61100004b900, rxr=0x7fffffff8c30, rss_info=0x7fffffff8c50) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1607 +#6 0x00005555571f5670 in e1000e_receive_iov (core=0x7fffee0dd4e0, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:1709 +#7 0x00005555571f1afc in e1000e_nc_receive_iov (nc=0x614000007460, iov=0x61900004e780, iovcnt=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:213 +#8 0x00005555571d5977 in net_tx_pkt_sendv (pkt=0x631000028800, nc=0x614000007460, iov=0x61900004e780, iov_cnt=0x4) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:544 +#9 0x00005555571d50e4 in net_tx_pkt_send (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620 +#10 0x00005555571d638f in net_tx_pkt_send_loopback (pkt=0x631000028800, nc=0x614000007460) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:633 +#11 0x000055555722b600 in e1000e_tx_pkt_send (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:664 +#12 0x0000555557229ca6 in e1000e_process_tx_desc (core=0x7fffee0dd4e0, tx=0x7fffee0fd748, dp=0x7fffffff9440, queue_index=0x0) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#13 0x0000555557228ea5 in e1000e_start_xmit (core=0x7fffee0dd4e0, txr=0x7fffffff9640) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#14 0x000055555721c70f in e1000e_set_tdt (core=0x7fffee0dd4e0, index=0xe06, val=0xcb) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#15 0x00005555571fa436 in e1000e_core_write (core=0x7fffee0dd4e0, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#16 0x00005555571ed11c in e1000e_mmio_write (opaque=0x7fffee0da800, addr=0x438, val=0xcb, size=0x4) at /home/alxndr/Development/qemu/hw/net/e1000e.c:109 +#17 0x00005555565e78b2 in memory_region_write_accessor (mr=0x7fffee0dd110, addr=0x438, value=0x7fffffff9cb0, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 +#18 0x00005555565e7212 in access_with_adjusted_size (addr=0x438, value=0x7fffffff9cb0, size=0x1, access_size_min=0x4, access_size_max=0x4, access_fn=0x5555565e72e0 <memory_region_write_accessor>, mr=0x7fffee0dd110, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#19 0x00005555565e5c31 in memory_region_dispatch_write (mr=0x7fffee0dd110, addr=0x438, data=0xcb, op=MO_8, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476 +#20 0x00005555563f04b9 in flatview_write_continue (fv=0x606000037880, addr=0xe1020438, attrs=..., ptr=0x61900009ba80, len=0x1, addr1=0x438, l=0x1, mr=0x7fffee0dd110) at /home/alxndr/Development/qemu/exec.c:3137 +#21 0x00005555563df2dd in flatview_write (fv=0x606000037880, addr=0xe1020077, attrs=..., buf=0x61900009ba80, len=0x3c2) at /home/alxndr/Development/qemu/exec.c:3177 +#22 0x00005555563deded in address_space_write (as=0x6080000027a0, addr=0xe1020077, attrs=..., buf=0x61900009ba80, len=0x3c2) at /home/alxndr/Development/qemu/exec.c:3268 + + + +I can reproduce this in qemu 5.0 using these qtest commands: + +cat << EOF | ./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe1025008 0x4 0xfbffa3fa +write 0xed040c 0x3 0x080047 +write 0xe1020077 0x3c2 0xce0004ed0000000000cb008405120002e100000000ff000801ffff02ce0004ed0000000000cb008405120002e100000000ff000a01ffff02ce0004ed0000000000cb008405120002e100000000ff000c01ffff02ce0004ed0000000000cb008405120002e100000000ff000e01ffff02ce0004ed0000000000cb008405120002e100000000ff001001ffff02ce0004ed0000000000cb008405120002e100000000ff001201ffff02ce0004ed0000000000cb008405120002e100000000ff001401ffff02ce0004ed0000000000cb008405120002e100000000ff001601ffff02ce0004ed0000000000cb008405120002e100000000ff001801ffff02ce0004ed0000000000cb008405120002e100000000ff001a01ffff02ce0004ed0000000000cb008405120002e100000000ff001c01ffff02ce0004ed0000000000cb008405120002e100000000ff001e01ffff02ce0004ed0000000000cb008405120002e100000000ff002001ffff02ce0004ed0000000000cb008405120002e100000000ff002201ffff02ce0004ed0000000000cb008405120002e100000000ff002401ffff02ce0004ed0000000000cb008405120002e100000000ff002601ffff02ce0004ed0000000000cb008405120002e100000000ff002801ffff02ce0004ed0000000000cb008405120002e100000000ff002a01ffff02ce0004ed0000000000cb008405120002e100000000ff002c01ffff02ce0004ed0000000000cb008405120002e100000000ff002e01ffff02ce0004ed0000000000cb008405120002e100000000ff003001ffff02ce0004ed0000000000cb008405120002e100000000ff003201ffff02ce0004ed0000000000cb008405120002e100000000ff003401ffff02ce0004ed0000000000cb008405120002e100000000ff003601ffff02ce0004ed0000000000cb008405120002e100000000ff003801ffff02ce0004ed0000000000cb008405120002e100000000ff003a01ffff02ce0004ed0000000000cb008405120002e100000000ff003c01ffff02ce0004ed0000000000cb008405120002e100000000ff003e01ffff02ce0004ed0000000000cb008405120002e100000000ff004001ffff02ce0004ed0000000000cb008405120002e100000000ff004201ffff02ce0004ed0000000000cb008405120002e100000000ff004401ffff02ce0004ed0000000000cb008405120002e100000000ff004601ffff02ce0004ed0000000000cb008405120002e100000000ff004801ffff02ce0004ed0000000000cb008405120002e100000000ff004a01ffff02ce0004ed0000000000cb +EOF + +Also attaching them to this report, in case they are formatted incorrectly: +./qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 < attachment + +Please let me know if I can provide any further info. +-Alex + + + +I can reproduce this problem with QEMU v5.0, but with the current version, it does not run into this assertion anymore. Seems like this problem got fixed in the course of time? Could you please check whether you could still reproduce this? + +OSS-Fuzz never saw it. It was probably fixed + +According to some automatic bisecting, it seems like this was fixed by this commit here: + + commit c2cb511634012344e3d0fe49a037a33b12d8a98a (refs/bisect/bad) + hw/net/e1000e: advance desc_offset in case of null descriptor + + diff --git a/results/classifier/118/unknown/1879672 b/results/classifier/118/unknown/1879672 new file mode 100644 index 00000000..8fde3fc9 --- /dev/null +++ b/results/classifier/118/unknown/1879672 @@ -0,0 +1,681 @@ +user-level: 0.925 +register: 0.914 +semantic: 0.902 +hypervisor: 0.901 +assembly: 0.899 +risc-v: 0.894 +virtual: 0.892 +arm: 0.890 +peripherals: 0.889 +graphic: 0.888 +TCG: 0.884 +permissions: 0.878 +PID: 0.873 +device: 0.871 +KVM: 0.865 +vnc: 0.863 +architecture: 0.859 +mistranslation: 0.853 +VMM: 0.853 +performance: 0.848 +network: 0.846 +ppc: 0.845 +debug: 0.812 +x86: 0.810 +boot: 0.808 +files: 0.801 +socket: 0.796 +kernel: 0.791 +i386: 0.764 + +QEMU installer with WHPX support + +People often ask the community to add WHPX support to the QEMU installer for Windows, +but it is impossible due to the license limitations of the WHPX SDK. + +The WinHvEmulation.h and WinHvPlatform.h header files needed are "All +rights reserved". + +However these headers only contain struct definitions and integer constants, +no functional code in macros or inline functions. See: +https://<email address hidden>/msg645815.html +It is questionable whether the headers alone can be considered copyrightable material. + +Has anyone raised an RFE with the mingw64 project to provide these headers / APIs ? That's what provides the interfaces we usually rely on for Windows builds, and they're likely familiar with what they can & can't do from a legal POV. I don't see this as something QEMU needs to solve itself. + ++launchpad ticket + +On 9/19/19 1:26 PM, Philippe Mathieu-Daudé wrote: +> On 9/19/19 1:18 PM, Stefan Weil wrote: +>> Am 19.09.2019 um 12:59 schrieb Philippe Mathieu-Daudé: +>>> Add a job to cross-build QEMU with WHPX enabled. +>>> +>>> Use the Win10SDK headers from the Android Project, as commented +>>> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html +>>> +>>> Based-on: <email address hidden> +>>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html +>>> +>>> Philippe Mathieu-Daudé (2): +>>> tests/docker: Add fedora-win10sdk-cross image +>>> .shippable.yml: Build WHPX enabled binaries +>>> +>>> .shippable.yml | 2 ++ +>>> tests/docker/Makefile.include | 1 + +>>> .../dockerfiles/fedora-win10sdk-cross.docker | 21 +++++++++++++++++++ +>>> 3 files changed, 24 insertions(+) +>>> create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker +>>> +>> +>> Please note that the required header files are part of the Win10SDK +>> which is not published under a free license, so I am afraid that they +>> cannot be used with QEMU code to produce free binaries. +> +> Yes :S +> +>> I have addressed that some time ago, and Justin Terry is still looking +>> for a solution on the Microsoft side. +> +> Oh this is a good news, thanks for caring about this issue, +> and thanks Justin for looking for a solution! +> +> Trying to understand how WHPX is used, I noticed there are much many +> Windows QEMU users than I thought, and it would be nice if we can have +> some upstream CI testing to not break the various projects using it. +> +> Regards, +> +> Phil. +> + + + ++launchpad ticket + +On 9/20/19 6:53 PM, Justin Terry (VM) wrote: +> Hey Phil, +> +> I have contacted our legal department for guidance on this specific use case and will update you when I hear back. Thank you for your patience. +> +> Justin Terry +> +>> -----Original Message----- +>> From: Philippe Mathieu-Daudé <email address hidden> +>> Sent: Friday, September 20, 2019 8:18 AM +>> To: <email address hidden>; Justin Terry (VM) <email address hidden> +>> Cc: Daniel P . Berrangé <email address hidden>; Fam Zheng +>> <email address hidden>; Thomas Huth <email address hidden>; Paolo Bonzini +>> <email address hidden>; Alex Bennée <email address hidden>; Richard +>> Henderson <email address hidden>; Eduardo Habkost <email address hidden>; +>> Stefan Weil <email address hidden> +>> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries +>> +>> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote: +>>> Add a job to cross-build QEMU with WHPX enabled. +>>> +>>> Since the WHPX is currently broken, include the patch required to have +>>> successful Shippable build. +>>> +>>> I previously included the WHPX headers shared by the Android project, +>>> and Daniel asked me to check the EULA. While trying to manually +>>> install the Windows SDK, I noticed the installer fetches archives +>>> directly, kindly asking where they are stored via the /fwlink API. +>>> Do the same, fetch the required archives and extract them. No need to +>>> accept EULA... +>>> +>>> Docker build the image first, then build QEMU in a instance of this +>>> image. The image is internal to Shippable, the instances are not +>>> reachable and are thrown once the build is finished. What we collect +>>> from Shippable is the console output of QEMU build process, and if the +>>> build process succeed or failed. So far we do not redistribute the +>>> image or built binaries. +>>> +>>> Philippe Mathieu-Daudé (3): +>>> target/i386: Fix broken build with WHPX enabled +>>> tests/docker: Add fedora-win10sdk-cross image +>>> .shippable.yml: Build WHPX enabled binaries +>> +>> FWIW here is the result of this series: +>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp. +>> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon +>> sole&data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427 +>> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 +>> 37045894733463150&sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv +>> nfCSdv%2FNaWDAw%3D&reserved=0 +>> Duration 17 minutes (1076 seconds) +>> +>> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s +>> building WHPX QEMU. + + + ++launchpad ticket + +On 11/7/19 11:52 PM, Sunil Muthuswamy wrote: +>>> You will need the Windows 10 SDK for RS5 (build 17763) or above to +>>> to be able to compile this patch because of the definition of the +>>> XCR0 register. +>>> +>>> Changes since v1: +>>> - Added a sign-off line in the patch. +>> +>> +>> I am not very happy with the current situation which suggests using non +>> free header files from the Microsoft Windows SDK, thus making it +>> impossible to produce QEMU executables for Windows with WHPX support +>> without having legal complications. +>> +>> Could you please add the required headers with a suitable license to the +>> QEMU source code? That would clarify the license issue and make builds +>> with WHPX much easier because those files would not have to be extracted +>> from a very large SDK installation. +>> +>> It would also be acceptable if Microsoft could update the license +>> comments in those files and use a QEMU compatible license. +>> +> I agree in principle that there should be an easier way to consume the Windows +> SDK headers without having to play around with the licenses. I also agree that +> that will make life lot easier for many developers. I am reaching out +> internally here to see what can be done about this, but, that might take some +> time. Meanwhile, is it possible to make some progress on this patch? +> +>> Kind regards +>> Stefan Weil +>> +>> +> + + + ++Mike Battista & lanchpad ticket + +On 2/24/20 8:43 PM, Sunil Muthuswamy wrote: +>> -----Original Message----- +>> From: Stefan Weil <email address hidden> +>> Sent: Thursday, February 20, 2020 11:54 PM +>> To: Justin Terry (SF) <email address hidden>; Philippe Mathieu-Daudé <email address hidden>; Sunil Muthuswamy +>> <email address hidden>; Eduardo Habkost <email address hidden>; Paolo Bonzini <email address hidden>; Richard Henderson +>> <email address hidden> +>> Cc: <email address hidden> +>> Subject: Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform +>> +>> Am 19.02.20 um 16:50 schrieb Justin Terry (SF): +>> +>> +>> Hello Justin, hello Sunil, +>> +>> just a reminder: we still have the problem with the proprietary license +>> for the required Microsoft header files. +>> +>> Can you estimate when this will be solved? +>> +> +> Thanks for the reminder, Stefan. Yes, agreed this problem still exists. We followed up with +> the SDK team and the legal team end of last year. I will nudge them again for an update +> here. +> +>> Regards, +>> Stefan +>> +> + + + +Hi Sunil, + +On 5/19/20 11:59 PM, Sunil Muthuswamy wrote: +>> -----Original Message----- +>> From: Stefan Weil <email address hidden> +>> Sent: Thursday, February 20, 2020 11:54 PM +>> To: Justin Terry (SF) <email address hidden>; Philippe Mathieu-Daudé <email address hidden>; Sunil Muthuswamy +>> <email address hidden>; Eduardo Habkost <email address hidden>; Paolo Bonzini <email address hidden>; Richard +>> Henderson <email address hidden> +>> Cc: <email address hidden> +>> Subject: Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform +>> +>> Am 19.02.20 um 16:50 schrieb Justin Terry (SF): +>> +>> Hello Justin, hello Sunil, +>> +>> just a reminder: we still have the problem with the proprietary license +>> for the required Microsoft header files. +>> +>> Can you estimate when this will be solved? +>> +>> Regards, +>> Stefan +>> +> +> Adding Mike Battista, who is on the SDK team and can help provide some clarity around the questions about SDK licensing. +> + +To ease communication and track the changes over time regarding this +problem, I opened a ticket on Launchpad: +https://bugs.launchpad.net/qemu/+bug/1879672 + +Last time (Sept 2019) Justin Terry contacted Microsoft legal department +for guidance but no update since. +This is unfortunate as we can not let the community use this feature, +neither can we keep testing WHPX to avoid code bitrot. + +Can you meanwhile provide Azure CI builds using WHPX enabled? + +Regards, + +Phil. + + + +> Has anyone raised an RFE with the mingw64 project to provide these headers / APIs? + +I had asked a long time ago on IRC (#mingw-w64 IRC channel on irc.oftc.net), but got no answer. + +Regards, +Stefan + +Hi Justin, Sunil, + +On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote: +> +launchpad ticket +> +> On 9/20/19 6:53 PM, Justin Terry (VM) wrote: +>> Hey Phil, +>> +>> I have contacted our legal department for guidance on this specific +>> use case and will update you when I hear back. Thank you for your +>> patience. + +I recently understood legal changes can be very complex, thus it is +implicit it can take years before getting updates. + +Since the project is still actively developed, maybe you could provide +a Azure CI job to build a WHPX binary. We don't need to have access to +the binary, just to the exit status (success/fail) and build logs. + +Do you think it is doable? + +Thanks, + +Phil. + +>> +>> Justin Terry +>> +>>> -----Original Message----- +>>> From: Philippe Mathieu-Daudé <email address hidden> +>>> Sent: Friday, September 20, 2019 8:18 AM +>>> To: <email address hidden>; Justin Terry (VM) <email address hidden> +>>> Cc: Daniel P . Berrangé <email address hidden>; Fam Zheng +>>> <email address hidden>; Thomas Huth <email address hidden>; Paolo Bonzini +>>> <email address hidden>; Alex Bennée <email address hidden>; Richard +>>> Henderson <email address hidden>; Eduardo Habkost <email address hidden>; +>>> Stefan Weil <email address hidden> +>>> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries +>>> +>>> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote: +>>>> Add a job to cross-build QEMU with WHPX enabled. +>>>> +>>>> Since the WHPX is currently broken, include the patch required to have +>>>> successful Shippable build. +>>>> +>>>> I previously included the WHPX headers shared by the Android project, +>>>> and Daniel asked me to check the EULA. While trying to manually +>>>> install the Windows SDK, I noticed the installer fetches archives +>>>> directly, kindly asking where they are stored via the /fwlink API. +>>>> Do the same, fetch the required archives and extract them. No need to +>>>> accept EULA... +>>>> +>>>> Docker build the image first, then build QEMU in a instance of this +>>>> image. The image is internal to Shippable, the instances are not +>>>> reachable and are thrown once the build is finished. What we collect +>>>> from Shippable is the console output of QEMU build process, and if the +>>>> build process succeed or failed. So far we do not redistribute the +>>>> image or built binaries. +>>>> +>>>> Philippe Mathieu-Daudé (3): +>>>> target/i386: Fix broken build with WHPX enabled +>>>> tests/docker: Add fedora-win10sdk-cross image +>>>> .shippable.yml: Build WHPX enabled binaries +>>> +>>> FWIW here is the result of this series: +>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp. +>>> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon +>>> sole&data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427 +>>> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 +>>> 37045894733463150&sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv +>>> nfCSdv%2FNaWDAw%3D&reserved=0 +>>> Duration 17 minutes (1076 seconds) +>>> +>>> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s +>>> building WHPX QEMU. +> + + + +Hi Sunil, + +On 8/1/20 1:31 AM, Sunil Muthuswamy wrote: +>> Hi Justin, Sunil, +> +> Justin has moved to a different team is no longer working with WHPX. Moving him +> to bcc. + +OK. Does that mean you are the new responsible of updating the ticket +regarding the WHPX headers and their license? + +> +>> +>> On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote: +>>> +launchpad ticket +>>> +>>> On 9/20/19 6:53 PM, Justin Terry (VM) wrote: +>>>> Hey Phil, +>>>> +>>>> I have contacted our legal department for guidance on this specific +>>>> use case and will update you when I hear back. Thank you for your +>>>> patience. +>> +>> I recently understood legal changes can be very complex, thus it is +>> implicit it can take years before getting updates. +>> +>> Since the project is still actively developed, maybe you could provide +>> a Azure CI job to build a WHPX binary. We don't need to have access to +>> the binary, just to the exit status (success/fail) and build logs. +>> +>> Do you think it is doable? +>> +>> Thanks, +>> +>> Phil. +>> +> The ask generally sounds reasonable. But, can you help me understand the full +> scope of the ask. Few questions: +> 1. Stefan has a CI pipeline to build WHPX. + +Great! I didn't know Stefan already did it :) +Can you share the URL please, so we can integrate it with mainstream CI? + +> What's the benefit of having another CI +> job, that doesn't export the binary, but, just the status? + +As usual, we do not want to circumvent the license. IANAL but IIUC we +can not force a CI job to accept the EULA when installing it, even to +test it. So the best we can do is check if the build succeeded (exit +status). + +> 2. Which branch is the CI pipeline expected to build? + +'master', to be sure no regressions are introduced. + +> 3. Is the expectation also that it will build WHPX patches that are submitted to the +> WHPX branch? + +You describe a "downstream CI" testing, which is out of scope of the +community public CI. + +Regards, + +Phil. + + + +On 8/4/20 8:55 AM, Stefan Weil wrote: +> Am 04.08.20 um 08:43 schrieb Thomas Huth: +> +>> On 03/08/2020 22.25, Stefan Weil wrote: +>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub +>>> action. +>> Sorry for being ignorant, but how does that solve the legal questions +>> just because it is running on GitHub instead of a different CI? +>> +>> Thomas +>> +> +> Sorry, I though that would be clear by looking at the included shell script. +> +> The build does not use the Microsoft SDK. It gets the required header +> files from Mingw-w64. They added them in git master. + +Oh, so we can do that with GitLab too now, we don't need to rely on the +GitHub 'Actions' CI in particular, right? + +> +> See +> https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50 +> for code details. +> +> It's still shameful that MS is forcing developers to waste time +> rewriting API headers, just because the MS legal departments are not +> able to understand the needs of Open Source development. + +There has be a big switch from Microsoft toward Open Source, I attended +some of there talk at the Open Source Summit in 2018. Maybe we simply +haven't contacted the right persons to make the changes...? + +> +> Stefan +> +> +> + + + +On 8/4/20 9:42 AM, Stefan Weil wrote: +> Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé: +> +>> On 8/4/20 8:55 AM, Stefan Weil wrote: +>>> Am 04.08.20 um 08:43 schrieb Thomas Huth: +>>> +>>>> On 03/08/2020 22.25, Stefan Weil wrote: +>>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub +>>>>> action. +>>>> Sorry for being ignorant, but how does that solve the legal questions +>>>> just because it is running on GitHub instead of a different CI? +>>>> +>>>> Thomas +>>>> +>>> Sorry, I though that would be clear by looking at the included shell script. +>>> +>>> The build does not use the Microsoft SDK. It gets the required header +>>> files from Mingw-w64. They added them in git master. +>> Oh, so we can do that with GitLab too now, we don't need to rely on the +>> GitHub 'Actions' CI in particular, right? +> +> +> That's right. The build script was written for Ubuntu, so depending on +> the distribution used for GitLab CI it will need some modifications. If +> GitLab already has a recent Mingw-w64, it might be sufficient to fix the +> case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU +> expects WinHvPlatform.h and so on. I used symbolic links to add the +> camel case filenames. +> +> +>>> See +>>> https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50 +>>> for code details. +>>> +>>> It's still shameful that MS is forcing developers to waste time +>>> rewriting API headers, just because the MS legal departments are not +>>> able to understand the needs of Open Source development. +>> There has be a big switch from Microsoft toward Open Source, I attended +>> some of there talk at the Open Source Summit in 2018. Maybe we simply +>> haven't contacted the right persons to make the changes...? +> +> +> Maybe, but it is difficult to find the right person in a large company +> like MS, and legal departments are often somehow special. + +Sunil seems quite active with the WHPX development, and the section is +listed as "Supported [my Microsoft]" in MAINTAINERS. I'm confident we +have someone else able to help use finding the right contacts in the +company :) + +> +> And yes, they learned that Open Source can help them for their business, +> too. +> +> Stefan +> +> +> + + + +On Tue, Aug 04, 2020 at 10:10:31AM +0200, Thomas Huth wrote: +> On 04/08/2020 09.42, Stefan Weil wrote: +> > Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé: +> > +> >> On 8/4/20 8:55 AM, Stefan Weil wrote: +> >>> Am 04.08.20 um 08:43 schrieb Thomas Huth: +> >>> +> >>>> On 03/08/2020 22.25, Stefan Weil wrote: +> >>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub +> >>>>> action. +> >>>> Sorry for being ignorant, but how does that solve the legal questions +> >>>> just because it is running on GitHub instead of a different CI? +> >>>> +> >>>> Thomas +> >>>> +> >>> Sorry, I though that would be clear by looking at the included shell script. +> >>> +> >>> The build does not use the Microsoft SDK. It gets the required header +> >>> files from Mingw-w64. They added them in git master. +> +> Great, thanks for the clarification! +> +> >> Oh, so we can do that with GitLab too now, we don't need to rely on the +> >> GitHub 'Actions' CI in particular, right? +> > +> > That's right. The build script was written for Ubuntu, so depending on +> > the distribution used for GitLab CI it will need some modifications. If +> > GitLab already has a recent Mingw-w64, it might be sufficient to fix the +> > case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU +> > expects WinHvPlatform.h and so on. I used symbolic links to add the +> > camel case filenames. +> +> I'm currently working on a patch series for our gitlab-CI that uses our +> containers to all possible kinds of cross-compiler builds (basically the +> ones that we are doing on shippable.com so far), including the 32-bit +> and 64-bit MinGW cross-compilation jobs. I can have a look whether I can +> integrate these headers there! + +Fedora rawhide carries mingw64 v7.0.0, which was released in Nov 2019 + +The WHPX headers were added to mingw64 git a week later, so they're +not available in any distro yet. + +The mingw64 release schedule looks "sporadic" so maybe we can just +request a new release to make WPHX stuff available. It'll thus be +available for our CI in rawhide/sid shortly thereafter, which will +be the best solution to let us do this in GitLab. + +We certainly don't want to add yet another separate CI system just +for WHPX. + +Regards, +Daniel +-- +|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| +|: https://libvirt.org -o- https://fstop138.berrange.com :| +|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| + + + +On 8/18/20 11:20 PM, Sunil Muthuswamy wrote: +>>>> It's still shameful that MS is forcing developers to waste time +>>>> rewriting API headers, just because the MS legal departments are not +>>>> able to understand the needs of Open Source development. +>>> There has be a big switch from Microsoft toward Open Source, I attended +>>> some of there talk at the Open Source Summit in 2018. Maybe we simply +>>> haven't contacted the right persons to make the changes...? +>> +>> +>> Maybe, but it is difficult to find the right person in a large company +>> like MS, and legal departments are often somehow special. +>> +>> And yes, they learned that Open Source can help them for their business, +>> too. +>> +>> Stefan +> +> Mike Battista is the program manager owner of the SDK license and should be +> able to take/respond to any feedback about the SDK licensing for open source +> projects (I have added him here). He has also been added to previous threads +> about the licensing and is also included in this conversation: +> https://bugs.launchpad.net/qemu/+bug/1879672 + +Hi Mike, thanks for helping us with this issue! + +And thanks a lot Sunil to bring Mike here :) + +> +> - Sunil +> +> + + + +Removing 'Opinion' and moving back to 'New'; as 'Opinion' is essentially the same as "WONTFIX" but allows discussion to continue. I believe you want a Feature Request tag instead. + +If there is still work for us to do, let's move this to Confirmed/Triaged and add the feature request tag. + +Thanks! + +Hi John, + +On 11/4/20 9:01 PM, John Snow wrote: +> Removing 'Opinion' and moving back to 'New'; as 'Opinion' is essentially +> the same as "WONTFIX" but allows discussion to continue. I believe you +> want a Feature Request tag instead. +> +> If there is still work for us to do, let's move this to +> Confirmed/Triaged and add the feature request tag. + +It seems Launchpad didn't Cc'ed the interested parties. + +Our contact is Mike Battista (see [*]) but so far he never +made any comment regarding this issue. + +Cc'ing Sunil who is the active developer (of WHPX in QEMU) +at Microsoft, and Stefan, who does the Open Source packaging. + +Regards, + +Phil. + +[*] https://<email address hidden>/msg731227.html + + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/233 + + +Meanwhile QEMU builds for CI and also my inofficial QEMU installers for Windows use free WHPX headers instead of the copyrighted MS ones, so this issue is fixed. + +But looking at the latest pipeline: +https://gitlab.com/qemu-project/qemu/-/pipelines/310113928 +in particular the cross-win64-system job: +https://gitlab.com/qemu-project/qemu/-/jobs/1296341064 + +WHPX isn't built anymore: + + Targets and accelerators + KVM support: NO + HAX support: YES + HVF support: NO + WHPX support: NO + NVMM support: NO + Xen support: NO + TCG support: YES + TCG backend: native (x86_64) + +We likely lost the coverage with commit 93cc0506f6c +("tests/docker: Use Fedora containers for MinGW cross-builds in the gitlab-CI") + +Should we open a new issue? + diff --git a/results/classifier/118/unknown/1880518 b/results/classifier/118/unknown/1880518 new file mode 100644 index 00000000..587bd032 --- /dev/null +++ b/results/classifier/118/unknown/1880518 @@ -0,0 +1,113 @@ +peripherals: 0.889 +permissions: 0.864 +TCG: 0.845 +register: 0.833 +user-level: 0.826 +VMM: 0.819 +assembly: 0.819 +virtual: 0.816 +arm: 0.816 +x86: 0.814 +vnc: 0.813 +graphic: 0.812 +ppc: 0.808 +risc-v: 0.801 +i386: 0.796 +files: 0.795 +architecture: 0.794 +semantic: 0.792 +debug: 0.777 +performance: 0.774 +PID: 0.774 +KVM: 0.772 +device: 0.772 +mistranslation: 0.766 +socket: 0.764 +boot: 0.741 +hypervisor: 0.727 +network: 0.721 +kernel: 0.708 + +issue while installing docker inside s390x container + +This is in reference to https://github.com/multiarch/qemu-user-static/issues/108. +I am facing issue while installing docker inside s390x container under qemu on Ubuntu 18.04 host running on amd64. +Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel host after running +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +enabled +interpreter /usr/bin/qemu-s390x-static +flags: F +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff +I could get docker service up with the following trick. +printf '{"iptables": false,"ip-masq": false,"bridge": "none" }' > /etc/docker/daemon.json +But even though docker service comes up, images are not getting pulled, docker pull fails with the following error. +failed to register layer: Error processing tar file(exit status 1): + +Without a more detailled error message we can'know what happens. + +What I see is you don't have the 'OC' flags that should help to execute binaries with (s) bit. + +You should also report the version of qemu. + +The error message that I posted above is all that I see when I go to pull and image. +Following is the log from docker daemon + +time="2020-05-26T07:34:31.385796553Z" level=info msg="API listen on /var/run/docker.sock" +time="2020-05-26T07:34:34.607431981Z" level=debug msg="Calling GET /_ping" +time="2020-05-26T07:34:34.635096021Z" level=debug msg="Calling GET /v1.38/containers/json" +time="2020-05-26T07:34:43.919894850Z" level=debug msg="Calling GET /_ping" +time="2020-05-26T07:34:43.963634642Z" level=debug msg="Calling GET /v1.38/info" +time="2020-05-26T07:34:44.702451808Z" level=debug msg="Calling POST /v1.38/images/create?fromImage=hello-world&tag=latest" +time="2020-05-26T07:34:44.715857621Z" level=debug msg="Trying to pull hello-world from https://registry-1.docker.io v2" +time="2020-05-26T07:34:46.805807639Z" level=debug msg="Pulling ref from V2 registry: hello-world:latest" +time="2020-05-26T07:34:46.806872106Z" level=debug msg="docker.io/library/hello-world:latest resolved to a manifestList object with 9 entries; looking for a unknown/s390x match" +time="2020-05-26T07:34:46.808815074Z" level=debug msg="found match for linux/s390x with media type application/vnd.docker.distribution.manifest.v2+json, digest sha256:e49abad529e5d9bd6787f3abeab94e09ba274fe34731349556a850b9aebbf7bf" +time="2020-05-26T07:34:47.233545931Z" level=debug msg="pulling blob \"sha256:3c80930bfdd5b53b7ca2a6b8116ed9a273af43a6b2dd13e81e82aae7521be469\"" +time="2020-05-26T07:34:47.864739182Z" level=debug msg="Downloaded 3c80930bfdd5 to tempfile /var/lib/docker/tmp/GetImageBlob114078888" +time="2020-05-26T07:34:48.038875327Z" level=debug msg="Cleaning up layer b3da5d545c61d65059a2190feb19ae13797338ee999542b615e93e9708b88507: Error processing tar file(exit status 1): " +time="2020-05-26T07:34:48.049928529Z" level=info msg="Attempting next endpoint for pull after error: failed to register layer: Error processing tar file(exit status 1): " + +Since I am using multiarch/qemu-user-static with the latest tag, qemu version is 4.2.0-6. + +docker in docker works flawlessly on native s390x host. I am facing this issue only with qemu. Are there any other steps to follow to make docker in docker work under qemu? + +Any pointers about this issue? Any other steps needs to be followed to resolve the issue? + +Also same issue observed with docker version 19.03. docker pull command failing with an error "failed to register layer: Error processing tar file(exit status 1):" + + + +QEMU 4.2 is quite old already, can you also reproduce the issue with the latest version of QEMU (v5.2 ... or maybe even with the 6.0-rc1 that should get released next week)? + +Yes we have observed the issue with multiarch/qemu-user-static image v5.2.0-1 and 5.2.0-2 + + +docker not starting inside s390x container. Log shows: + +Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': iptables who? (do you need to insmod?) +Perhaps iptables or your kernel needs to be upgraded. + (exit status 3) + + +As we are facing issue with service docker start ( for docker in docker s390x container under qemu) + +time="2021-03-23T07:29:07.645278866Z" level=warning msg="Running modprobe nf_nat failed with message: ``, error: exec: \"modprobe\": executable file not found in $PATH" +time="2021-03-23T07:29:07.645535879Z" level=warning msg="Running modprobe xt_conntrack failed with message: ``, error: exec: \"modprobe\": executable file not found in $PATH" +Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.6.1: can't initialize iptables table `nat': iptables who? (do you need to insmod?) +Perhaps iptables or your kernel needs to be upgraded. + (exit status 3) + +Does it mean that qemu doesn't support/have enabled related modules? modprobe? + + +Could you please let me know if my understanding is correct? Qemu doesn't support/have enabled related modules? modprobe? + +insmod/modprobe inside the container cannot load the modules because they are the one for the target architecture while the kernel is the one of the host. If you need functionalities in the container provided by some modules you need to load these modules using modprobe/insmod on the host. + +Looks like for docker in docker in cross architectures is not yet supported. if we use -v /var/run/docker.sock:/var/run/docker.sock , docker will always run as client in s390x container and server from amd64. + +Looks like docker in docker for cross architectures is not yet supported in qemu. +can be closed + diff --git a/results/classifier/118/unknown/1883733 b/results/classifier/118/unknown/1883733 new file mode 100644 index 00000000..5b44c0ad --- /dev/null +++ b/results/classifier/118/unknown/1883733 @@ -0,0 +1,387 @@ +mistranslation: 0.945 +VMM: 0.944 +register: 0.937 +TCG: 0.932 +KVM: 0.928 +hypervisor: 0.921 +ppc: 0.917 +user-level: 0.914 +risc-v: 0.909 +vnc: 0.901 +performance: 0.896 +i386: 0.894 +permissions: 0.892 +x86: 0.888 +peripherals: 0.868 +assembly: 0.866 +architecture: 0.849 +arm: 0.849 +semantic: 0.832 +device: 0.814 +graphic: 0.811 +debug: 0.810 +files: 0.808 +virtual: 0.808 +kernel: 0.792 +PID: 0.786 +boot: 0.785 +network: 0.779 +socket: 0.756 + +FIXME xhci_alloc_device_streams:972 guest streams config not identical for all eps + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + + + +OSS-Fuzz reported this: + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none \ +-machine accel=qtest, -m 512M -machine q35 -nodefaults \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-device usb-tablet -device usb-wacom-tablet -device usb-audio \ +-qtest stdio +outl 0xcf8 0x80000803 +outl 0xcfc 0x18ffffff +outl 0xcf8 0x80000813 +outb 0xcfc 0x5e +write 0x5e000074 0x4 0x5a636c6f +writel 0x5e000040 0x5adeb005 +write 0xd 0x1 0x24 +write 0x1d 0x1 0x2e +write 0x2d 0x1 0xff +write 0x3d 0x1 0x24 +write 0x4d 0x1 0x2e +write 0x5d 0x1 0xff +write 0x6d 0x1 0x24 +write 0x7d 0x1 0x2e +write 0x8d 0x1 0xff +write 0x9d 0x1 0x24 +write 0xad 0x1 0x2e +write 0xbd 0x1 0xff +write 0xcd 0x1 0x24 +write 0xdd 0x1 0x2e +write 0x6d04 0x1 0x03 +write 0x6d26 0x1 0x04 +write 0xed 0x1 0xff +write 0xfd 0x1 0x24 +write 0x10d 0x1 0x2e +write 0x11d 0x1 0xff +write 0x12d 0x1 0x24 +write 0x13d 0x1 0x2e +write 0x14d 0x1 0xff +write 0x15d 0x1 0x24 +write 0x16d 0x1 0x2e +write 0x17d 0x1 0xff +write 0x18d 0x1 0x24 +write 0x19d 0x1 0x2e +write 0x1ad 0x1 0xff +write 0x1bd 0x1 0x24 +write 0x1cd 0x1 0x2e +write 0x1dd 0x1 0xff +write 0x1ed 0x1 0x24 +write 0x1fd 0x1 0x2e +write 0x20d 0x1 0xff +write 0x21d 0x1 0x24 +write 0x22d 0x1 0x2e +write 0x23d 0x1 0xff +write 0x24d 0x1 0x24 +write 0x25d 0x1 0x2e +write 0x26d 0x1 0xff +write 0x27d 0x1 0x24 +write 0x28d 0x1 0x2e +write 0x29d 0x1 0xff +write 0x2ad 0x1 0x24 +write 0x2bd 0x1 0x2e +write 0x2cd 0x1 0xff +write 0x2dd 0x1 0x24 +write 0x2ed 0x1 0x2e +write 0x2fd 0x1 0xff +write 0x30d 0x1 0x24 +write 0x31d 0x1 0x2e +write 0x32d 0x1 0xff +write 0x33d 0x1 0x24 +write 0x34d 0x1 0x2e +write 0x35d 0x1 0xff +write 0x36d 0x1 0x24 +write 0x37d 0x1 0x2e +write 0x38d 0x1 0xff +write 0x39d 0x1 0x24 +write 0x3ad 0x1 0x2e +write 0x3bd 0x1 0xff +write 0x3cd 0x1 0x24 +write 0x3dd 0x1 0x2e +write 0x3ed 0x1 0xff +write 0x3fd 0x1 0x24 +write 0x40d 0x1 0x2e +write 0x41d 0x1 0xff +write 0x42d 0x1 0x24 +write 0x43d 0x1 0x2e +write 0x44d 0x1 0xff +write 0x45d 0x1 0x24 +write 0x46d 0x1 0x2e +write 0x47d 0x1 0xff +write 0x48d 0x1 0x24 +write 0x49d 0x1 0x2e +write 0x4ad 0x1 0xff +write 0x4bd 0x1 0x24 +write 0x4cd 0x1 0x2e +write 0x4dd 0x1 0xff +write 0x4ed 0x1 0x24 +write 0x4fd 0x1 0x2e +write 0x50d 0x1 0xff +write 0x51d 0x1 0x24 +write 0x52d 0x1 0x2e +write 0x53d 0x1 0xff +write 0x54d 0x1 0x24 +write 0x55d 0x1 0x2e +write 0x56d 0x1 0xff +write 0x57d 0x1 0x24 +write 0x58d 0x1 0x2e +write 0x59d 0x1 0xff +write 0x5ad 0x1 0x24 +write 0x5bd 0x1 0x2e +write 0x5cd 0x1 0xff +write 0x5dd 0x1 0x24 +write 0x5ed 0x1 0x2e +write 0x5fd 0x1 0xff +write 0x60d 0x1 0x24 +write 0x61d 0x1 0x2e +write 0x62d 0x1 0xff +write 0x63d 0x1 0x24 +write 0x64d 0x1 0x2e +write 0x65d 0x1 0xff +write 0x66d 0x1 0x24 +write 0x67d 0x1 0x2e +write 0x68d 0x1 0xff +write 0x69d 0x1 0x24 +write 0x6ad 0x1 0x2e +write 0x6bd 0x1 0xff +write 0x6cd 0x1 0x24 +write 0x6dd 0x1 0x2e +write 0x6ed 0x1 0xff +write 0x6fd 0x1 0x24 +write 0x70d 0x1 0x2e +write 0x71d 0x1 0xff +write 0x72d 0x1 0x24 +write 0x73d 0x1 0x2e +write 0x74d 0x1 0xff +write 0x75d 0x1 0x24 +write 0x76d 0x1 0x2e +write 0x77d 0x1 0xff +write 0x78d 0x1 0x24 +write 0x79d 0x1 0x2e +write 0x7ad 0x1 0xff +write 0x7bd 0x1 0x24 +write 0x7cd 0x1 0x2e +write 0x7dd 0x1 0xff +write 0x7ed 0x1 0x24 +write 0x7fd 0x1 0x2e +write 0x80d 0x1 0xff +write 0x81d 0x1 0x24 +write 0x82d 0x1 0x2e +write 0x83d 0x1 0xff +write 0x84d 0x1 0x24 +write 0x85d 0x1 0x2e +write 0x86d 0x1 0xff +write 0x87d 0x1 0x24 +write 0x88d 0x1 0x2e +write 0x89d 0x1 0xff +write 0x8ad 0x1 0x24 +write 0x8bd 0x1 0x2e +write 0x8cd 0x1 0xff +write 0x8dd 0x1 0x24 +write 0x8ed 0x1 0x2e +write 0x8fd 0x1 0xff +write 0x90d 0x1 0x24 +write 0x91d 0x1 0x2e +write 0x92d 0x1 0xff +write 0x93d 0x1 0x24 +write 0x94d 0x1 0x2e +write 0x95d 0x1 0xff +write 0x96d 0x1 0x24 +write 0x97d 0x1 0x2e +write 0x98d 0x1 0xff +write 0x99d 0x1 0x24 +write 0x9ad 0x1 0x2e +write 0x9bd 0x1 0xff +write 0x9cd 0x1 0x24 +write 0x9dd 0x1 0x2e +write 0x9ed 0x1 0xff +write 0x9fd 0x1 0x24 +write 0xa0d 0x1 0x2e +write 0xa1d 0x1 0xff +write 0xa2d 0x1 0x24 +write 0xa3d 0x1 0x2e +write 0xa4d 0x1 0xff +write 0xa5d 0x1 0x24 +write 0xa6d 0x1 0x2e +write 0xa7d 0x1 0xff +write 0xa8d 0x1 0x24 +write 0xa9d 0x1 0x2e +write 0xaad 0x1 0xff +write 0xabd 0x1 0x24 +write 0xacd 0x1 0x2e +write 0xadd 0x1 0xff +write 0xaed 0x1 0x24 +write 0xafd 0x1 0x2e +write 0xb0d 0x1 0xff +write 0xb1d 0x1 0x24 +write 0xb2d 0x1 0x2e +write 0xb3d 0x1 0xff +write 0xb4d 0x1 0x24 +write 0xb5d 0x1 0x2e +write 0xb6d 0x1 0xff +write 0xb7d 0x1 0x24 +write 0xb8d 0x1 0x2e +write 0xb9d 0x1 0xff +write 0xbad 0x1 0x24 +write 0xbbd 0x1 0x2e +write 0xbcd 0x1 0xff +write 0xbdd 0x1 0x24 +write 0xbed 0x1 0x2e +write 0xbfd 0x1 0xff +write 0xc0d 0x1 0x24 +write 0xc1d 0x1 0x2e +write 0xc2d 0x1 0xff +write 0xc3d 0x1 0x24 +write 0xc4d 0x1 0x2e +write 0xc5d 0x1 0xff +write 0xc6d 0x1 0x24 +write 0xc7d 0x1 0x2e +write 0xc8d 0x1 0xff +write 0xc9d 0x1 0x24 +write 0xcad 0x1 0x2e +write 0xcbd 0x1 0xff +write 0xccd 0x1 0x24 +write 0xcdd 0x1 0x2e +write 0xced 0x1 0xff +write 0xcfd 0x1 0x24 +write 0xd0d 0x1 0x2e +write 0xd1d 0x1 0xff +write 0xd2d 0x1 0x24 +write 0xd3d 0x1 0x2e +write 0xd4d 0x1 0xff +write 0xd5d 0x1 0x24 +write 0xd6d 0x1 0x2e +write 0xd7d 0x1 0xff +write 0xd8d 0x1 0x24 +write 0xd9d 0x1 0x2e +write 0xdad 0x1 0xff +write 0xdbd 0x1 0x24 +write 0xdcd 0x1 0x2e +write 0xddd 0x1 0xff +write 0xded 0x1 0x24 +write 0xdfd 0x1 0x2e +write 0xe0d 0x1 0xff +write 0xe1d 0x1 0x24 +write 0xe2d 0x1 0x2e +write 0xe3d 0x1 0xff +write 0xe4d 0x1 0x24 +write 0xe5d 0x1 0x2e +write 0xe6d 0x1 0xff +write 0xe7d 0x1 0x24 +write 0xe8d 0x1 0x2e +write 0xe9d 0x1 0xff +write 0xead 0x1 0x24 +write 0xebd 0x1 0x2e +write 0xecd 0x1 0xff +write 0xedd 0x1 0x24 +write 0xeed 0x1 0x2e +write 0xefd 0x1 0xff +write 0xf0d 0x1 0x24 +write 0xf1d 0x1 0x2e +write 0xf2d 0x1 0xff +write 0xf3d 0x1 0x24 +write 0xf4d 0x1 0x2e +write 0xf5d 0x1 0xff +write 0xf6d 0x1 0x24 +write 0xf7d 0x1 0x2e +write 0xf8d 0x1 0xff +write 0xf9d 0x1 0x24 +write 0xfad 0x1 0x2e +write 0xfbd 0x1 0xff +write 0xfcd 0x1 0x24 +write 0xfdd 0x1 0x2e +write 0xfed 0x1 0xff +write 0xffd 0x1 0x24 +write 0x1001 0x1 0x6d +write 0x100d 0x1 0x2e +write 0x100f 0x1 0x05 +writel 0x5e002000 0x0 +write 0x102d 0x1 0x24 +write 0x103d 0x1 0x2e +write 0x1040 0x1 0xfe +write 0x1041 0x1 0xff +write 0x1042 0x1 0xff +write 0x1043 0x1 0xff +write 0x1044 0x1 0xff +write 0x1045 0x1 0xff +write 0x1046 0x1 0xff +write 0x1047 0x1 0xff +write 0x104d 0x1 0x31 +write 0x104f 0x1 0x05 +write 0x2 0x1 0x11 +write 0x3 0x1 0x07 +write 0xf 0x1 0x73 +write 0x9f 0x1 0x65 +write 0x13f 0x1 0x6d +writel 0x5e002000 0x0 +EOF + +=== Stack Trace === +FIXME xhci_alloc_device_streams:921 guest streams config not identical for all eps +==683875== ERROR: libFuzzer: deadly signal +0x56009f09d311 in __sanitizer_print_stack_trace (fuzz-i386+0x2b16311) +0x56009efe63d8 in fuzzer::PrintStackTrace() (fuzz-i386+0x2a5f3d8) +0x56009efcc413 in fuzzer::Fuzzer::CrashCallback() (fuzz-i386+0x2a45413) +0x7f0aed93e13f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1413f) +0x7f0aed773db0 in __libc_signal_restore_set signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 +0x7f0aed773db0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +0x7f0aed75d536 in abort stdlib/abort.c:79:7 +0x56009f4ecde7 in xhci_alloc_device_streams hw/usb/hcd-xhci.c:921:13 +0x56009f4ecde7 in xhci_configure_slot hw/usb/hcd-xhci.c:2223:11 +0x56009f4ecde7 in xhci_process_commands hw/usb/hcd-xhci.c:2466:31 +0x56009f4e36fb in xhci_doorbell_write hw/usb/hcd-xhci.c:3100:13 +0x5600a07fb025 in memory_region_write_accessor softmmu/memory.c:491:5 +0x5600a07faa93 in access_with_adjusted_size softmmu/memory.c:552:18 +0x5600a07fa2f0 in memory_region_dispatch_write softmmu/memory.c +0x5600a0249f36 in flatview_write_continue softmmu/physmem.c:2759:23 +0x5600a023fbbb in flatview_write softmmu/physmem.c:2799:14 +0x5600a023fbbb in address_space_write softmmu/physmem.c:2891:18 +0x5600a06d4362 in qtest_process_command softmmu/qtest.c:534:13 +0x5600a06d15bf in qtest_process_inbuf softmmu/qtest.c:797:9 +0x5600a06d1315 in qtest_server_inproc_recv softmmu/qtest.c:904:9 +0x5600a0d0edf8 in qtest_sendf tests/qtest/libqtest.c:438:5 +0x5600a0d1038e in qtest_write tests/qtest/libqtest.c:1004:5 +0x5600a0d1038e in qtest_writel tests/qtest/libqtest.c:1020:5 +0x56009f0d7eaa in __wrap_qtest_writel tests/qtest/fuzz/qtest_wrappers.c:180:9 +0x56009f0d0299 in op_write tests/qtest/fuzz/generic_fuzz.c:473:13 +0x56009f0ce4e9 in generic_fuzz tests/qtest/fuzz/generic_fuzz.c:680:17 +0x56009f0c7723 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:151:5 + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28602 + + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/274 + + diff --git a/results/classifier/118/unknown/1884684 b/results/classifier/118/unknown/1884684 new file mode 100644 index 00000000..840515b6 --- /dev/null +++ b/results/classifier/118/unknown/1884684 @@ -0,0 +1,268 @@ +permissions: 0.893 +user-level: 0.885 +performance: 0.881 +ppc: 0.880 +virtual: 0.877 +peripherals: 0.873 +hypervisor: 0.871 +vnc: 0.867 +register: 0.859 +TCG: 0.852 +mistranslation: 0.841 +device: 0.839 +x86: 0.839 +KVM: 0.838 +VMM: 0.837 +architecture: 0.833 +risc-v: 0.832 +graphic: 0.831 +debug: 0.828 +semantic: 0.824 +arm: 0.816 +network: 0.816 +i386: 0.802 +assembly: 0.794 +files: 0.785 +socket: 0.763 +kernel: 0.753 +PID: 0.747 +boot: 0.704 + +QEMU 5.0: Guest VM hangs/freeze when unplugging USB device + +Setup: + +Host: Debian/SID, Kernel 5.6, QEMU 5.0 +Guest: Windows 10 VM with PCI and USB device passthrough. + +Problem: Guest VM suddenly hangs when pulling USB device out from the Host. + +Observations: + - Issue appears to be related to QEMU 5.0 + - It started after an upgrade to QEMU 5.0. + - Downgrading only QEMU on multiple systems fixes the issue. + + - Issue is very reproducible. + - Most of the time within a few attempts of pulling/reconnecting the device. + - Issue happens with multiple devices (I did try standard HID devices, a webcam and an x-ray sensor). + + - Guest just hangs. + - Display output remains on last frame shown. + - Ping to Guest immediately stops working. + - Logs in the Guest stop logging immediately. + + - Host is fine and thinks the Guest is fine. + - Guest continues to show as running in "virsh list". + - No suspicious entries in the QEMU logs. + - No suspicious entries in Host syslogs/messages. + - Host can can kill guest "virsh destroy" and respawn fine. + + - Issue seems widespread. + - Multiple similar reports from ProxMox users after upgrade to ProxMox 6.2 for both Windows and Linux guests (First version that uses QEMU 5.0) + +https://forum.proxmox.com/threads/vm-freezes-when-disconnecting-usb-keyboard-and-mouse.70287/ +https://forum.proxmox.com/threads/usb-drive-crashes-vm.70214/ +https://forum.proxmox.com/threads/latest-proxmox-usb-disconnects-freeze-kvm.70398/ +https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69821/ +https://forum.proxmox.com/threads/vm-with-gpu-passthrough-freezes-when-turning-off-monitor-after-proxmox-6-2-upgrade.69824/ + +I'd be more than happy any debugs that might be helpful. + +Following reports on Proxmox forums, this is still very much seen by multiple users with no known workaround. + +I was able to run QEMU 5.0.13 (Debian) with all traces turned on and capture the following: + +- Behavior is reproducible by unbinding usb device on the host (ex. "echo '1-8' > /sys/bus/usb/drivers/usb/unbind") +- qemu trace logs stops at exactly the same time when VM freezes +- Last few lines of the qemu trace: + +1592303@1596123157.254134:virtio_notify vdev 0x56193d04d820 vq 0x7fcd5c48a010 +1592320@1596123158.822309:usb_xhci_oper_read off 0x0004, ret 0x00000008 +1592320@1596123158.822397:usb_xhci_port_read port 1, off 0x0000, ret 0x0e0002a0 +1592320@1596123158.822459:usb_xhci_port_read port 2, off 0x0000, ret 0x0e0002a0 +1592320@1596123158.822513:usb_xhci_port_read port 3, off 0x0000, ret 0x0e0002a0 +1592320@1596123158.822565:usb_xhci_port_read port 4, off 0x0000, ret 0x0e0002a0 +1592303@1596123159.858372:virtqueue_alloc_element elem 0x56193c8c8990 size 56 in_num 2 out_num 0 +1592303@1596123159.858435:virtqueue_pop vq 0x7fcd5c48a010 elem 0x56193c8c8990 in_num 2 out_num 0 +1592303@1596123159.858482:virtqueue_fill vq 0x7fcd5c48a010 elem 0x56193c8c8990 len 72 idx 0 +1592303@1596123159.858533:virtqueue_flush vq 0x7fcd5c48a010 count 1 +1592303@1596123159.858565:virtio_notify vdev 0x56193d04d820 vq 0x7fcd5c48a010 +1592303@1596123160.272641:virtqueue_alloc_element elem 0x56193c8c8990 size 56 in_num 2 out_num 0 +1592303@1596123160.272702:virtqueue_pop vq 0x7fcd5c48a010 elem 0x56193c8c8990 in_num 2 out_num 0 +1592303@1596123160.272751:virtqueue_fill vq 0x7fcd5c48a010 elem 0x56193c8c8990 len 104 idx 0 +1592303@1596123160.272802:virtqueue_flush vq 0x7fcd5c48a010 count 1 +1592303@1596123160.272833:virtio_notify vdev 0x56193d04d820 vq 0x7fcd5c48a010 +1592303@1596123160.845694:lockcnt_unlock_attempt lockcnt 0x56193bea6514 unlock 5->4 +1592303@1596123160.846821:lockcnt_unlock_success lockcnt 0x56193bea6514 unlock 5->4 succeeded +1592303@1596123160.847923:usb_host_req_complete dev 1:4, packet 0x7fcb84000ea8, status 0, length 0 +1592303@1596123160.849369:usb_packet_state_change bus 0, port 1, ep 2, packet 0x7fcb84000ea8, state async -> complete +1592303@1596123160.851157:usb_xhci_xfer_success 0x7fcb84000ea0: len 0 +1592303@1596123160.851214:usb_xhci_queue_event v 3, idx 5, ER_TRANSFER, CC_SHORT_PACKET, p 0xffffac0c62444ae3, s 0x0d000000, c 0x02058005 +1592303@1596123160.851285:usb_xhci_irq_msix nr 3 +1592303@1596123160.851331:usb_xhci_ep_kick slotid 2, epid 5, streamid 0 +1592303@1596123160.851374:usb_host_req_data dev 1:4, packet 0x56193cce8da8, in 1, ep 2, size 4 +1592303@1596123160.851434:usb_host_req_complete dev 1:4, packet 0x56193cce8da8, status -1, length 0 +1592303@1596123160.851485:usb_packet_state_change bus 0, port 1, ep 2, packet 0x56193cce8da8, state queued -> complete +1592303@1596123160.851541:usb_xhci_xfer_error 0x56193cce8da0: ret -1 +1592303@1596123160.851577:usb_xhci_queue_event v 3, idx 6, ER_TRANSFER, CC_USB_TRANSACTION_ERROR, p 0x00000001c18a4e20, s 0x04000004, c 0x02058001 +1592303@1596123160.851647:usb_xhci_ep_state slotid 2, epid 5, running -> halted +1592303@1596123160.852700:usb_xhci_ep_kick slotid 2, epid 5, streamid 0 +1592303@1596123160.852744:usb_host_req_complete dev 1:4, packet 0x7fcb84000b98, status 0, length 0 +1592303@1596123160.852788:usb_packet_state_change bus 0, port 1, ep 1, packet 0x7fcb84000b98, state async -> complete +1592303@1596123160.852845:usb_xhci_xfer_success 0x7fcb84000b90: len 0 +1592303@1596123160.852879:usb_xhci_queue_event v 3, idx 7, ER_TRANSFER, CC_SHORT_PACKET, p 0xffffac0c6229aae3, s 0x0d000000, c 0x02038005 +1592303@1596123160.852945:usb_xhci_ep_kick slotid 2, epid 3, streamid 0 +1592303@1596123160.852977:usb_host_req_data dev 1:4, packet 0x56193c9da348, in 1, ep 1, size 8 +1592303@1596123160.853031:usb_host_req_complete dev 1:4, packet 0x56193c9da348, status -1, length 0 +1592303@1596123160.853080:usb_packet_state_change bus 0, port 1, ep 1, packet 0x56193c9da348, state queued -> complete +1592303@1596123160.853136:usb_xhci_xfer_error 0x56193c9da340: ret -1 +1592303@1596123160.853170:usb_xhci_queue_event v 3, idx 8, ER_TRANSFER, CC_USB_TRANSACTION_ERROR, p 0x00000001c18a4c20, s 0x04000008, c 0x02038001 +1592303@1596123160.853240:usb_xhci_ep_state slotid 2, epid 3, running -> halted +1592303@1596123160.853280:usb_xhci_ep_kick slotid 2, epid 3, streamid 0 +1592303@1596123160.853316:lockcnt_unlock_attempt lockcnt 0x56193bea6514 unlock 1->4 +1592303@1596123160.853352:lockcnt_unlock_success lockcnt 0x56193bea6514 unlock 1->4 succeeded +1592303@1596123160.853564:usb_host_close dev 1:4 +libusb: error [udev_hotplug_event] ignoring udev action unbind + + +Link to bug on the proxmox side: + +https://bugzilla.proxmox.com/show_bug.cgi?id=2781 + +I do get get the same backtrace in gdb every time every time when we reproduce the hang: + +(gdb) thread apply all bt + +Thread 9 (Thread 0x7fd1415ff700 (LWP 3202)): +#0 0x00007fd323d154bf in __GI___poll (fds=0x7fd1415fe6c0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 +#1 0x00007fd324978bb2 in ?? () from target:/lib/x86_64-linux-gnu/libusb-1.0.so.0 +#2 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#3 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 8 (Thread 0x7fd1437fe700 (LWP 3171)): +#0 0x00007fd323d16d87 in ioctl () at ../sysdeps/unix/syscall-template.S:120 +#1 0x000055a5daef74f7 in kvm_vcpu_ioctl () +#2 0x000055a5daef7631 in kvm_cpu_exec () +#3 0x000055a5daedaede in ?? () +#4 0x000055a5db32194b in ?? () +#5 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 7 (Thread 0x7fd143fff700 (LWP 3170)): +#0 0x00007fd323d16d87 in ioctl () at ../sysdeps/unix/syscall-template.S:120 +#1 0x000055a5daef74f7 in kvm_vcpu_ioctl () +#2 0x000055a5daef7631 in kvm_cpu_exec () +#3 0x000055a5daedaede in ?? () +#4 0x000055a5db32194b in ?? () +#5 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 6 (Thread 0x7fd150dfd700 (LWP 3169)): +#0 __lll_lock_wait (futex=futex@entry=0x55a5db80a540, private=0) at lowlevellock.c:52 +#1 0x00007fd323df2843 in __GI___pthread_mutex_lock (mutex=0x55a5db80a540) at ../nptl/pthread_mutex_lock.c:80 +#2 0x000055a5db321b43 in qemu_mutex_lock_impl () +#3 0x000055a5daedac8e in qemu_mutex_lock_iothread_impl () +#4 0x000055a5dae92ac9 in ?? () +#5 0x000055a5dae97de7 in flatview_read_continue () +#6 0x000055a5dae98023 in ?? () +#7 0x000055a5dae9813b in address_space_read_full () +#8 0x000055a5daef78cf in kvm_cpu_exec () +#9 0x000055a5daedaede in ?? () +#10 0x000055a5db32194b in ?? () +#11 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#12 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 5 (Thread 0x7fd1515fe700 (LWP 3168)): +#0 __lll_lock_wait (futex=futex@entry=0x55a5db80a540, private=0) at lowlevellock.c:52 +#1 0x00007fd323df2843 in __GI___pthread_mutex_lock (mutex=0x55a5db80a540) at ../nptl/pthread_mutex_lock.c:80 +#2 0x000055a5db321b43 in qemu_mutex_lock_impl () +#3 0x000055a5daedac8e in qemu_mutex_lock_iothread_impl () +#4 0x000055a5dae92ac9 in ?? () +#5 0x000055a5dae97de7 in flatview_read_continue () +#6 0x000055a5dae98023 in ?? () +#7 0x000055a5dae9813b in address_space_read_full () +#8 0x000055a5daef78cf in kvm_cpu_exec () +#9 0x000055a5daedaede in ?? () +#10 0x000055a5db32194b in ?? () +#11 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#12 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 4 (Thread 0x7fd151dff700 (LWP 3167)): +#0 __lll_lock_wait (futex=futex@entry=0x55a5db80a540, private=0) at lowlevellock.c:52 +#1 0x00007fd323df2843 in __GI___pthread_mutex_lock (mutex=0x55a5db80a540) at ../nptl/pthread_mutex_lock.c:80 +--Type <RET> for more, q to quit, c to continue without paging-- +#2 0x000055a5db321b43 in qemu_mutex_lock_impl () +#3 0x000055a5daedac8e in qemu_mutex_lock_iothread_impl () +#4 0x000055a5dae92ac9 in ?? () +#5 0x000055a5dae97de7 in flatview_read_continue () +#6 0x000055a5dae98023 in ?? () +#7 0x000055a5dae9813b in address_space_read_full () +#8 0x000055a5daef78cf in kvm_cpu_exec () +#9 0x000055a5daedaede in ?? () +#10 0x000055a5db32194b in ?? () +#11 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#12 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 3 (Thread 0x7fd320d97700 (LWP 3166)): +#0 0x00007fd323d154bf in __GI___poll (fds=0x7fd318003180, nfds=3, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 +#1 0x00007fd324a097ee in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#2 0x00007fd324a09b53 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#3 0x000055a5db016c71 in ?? () +#4 0x000055a5db32194b in ?? () +#5 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 2 (Thread 0x7fd3224de700 (LWP 3156)): +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055a5db3226fa in qemu_event_wait () +#2 0x000055a5db33466a in ?? () +#3 0x000055a5db32194b in ?? () +#4 0x00007fd323defea7 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#5 0x00007fd323d1feaf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 1 (Thread 0x7fd3224dff40 (LWP 3148)): +#0 0x00007fd323d154bf in __GI___poll (fds=0x55a5dca30150, nfds=3, timeout=3) at ../sysdeps/unix/sysv/linux/poll.c:29 +#1 0x00007fd324971f4d in ?? () from target:/lib/x86_64-linux-gnu/libusb-1.0.so.0 +#2 0x00007fd32497316c in libusb_handle_events_timeout_completed () from target:/lib/x86_64-linux-gnu/libusb-1.0.so.0 +#3 0x000055a5db18edc7 in ?? () +#4 0x000055a5db18efab in ?? () +#5 0x000055a5db31abf7 in aio_bh_poll () +#6 0x000055a5db31e3fe in aio_dispatch () +#7 0x000055a5db31aace in ?? () +#8 0x00007fd324a095fd in g_main_context_dispatch () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#9 0x000055a5db31d638 in main_loop_wait () +#10 0x000055a5dafad309 in qemu_main_loop () +#11 0x000055a5dae9125e in main () +(gdb) + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +Issue does not occur in latest version of QEMU anymore. + diff --git a/results/classifier/118/unknown/1885175 b/results/classifier/118/unknown/1885175 new file mode 100644 index 00000000..9ba60559 --- /dev/null +++ b/results/classifier/118/unknown/1885175 @@ -0,0 +1,112 @@ +mistranslation: 0.905 +user-level: 0.894 +permissions: 0.891 +performance: 0.853 +hypervisor: 0.850 +virtual: 0.845 +risc-v: 0.839 +files: 0.836 +peripherals: 0.834 +VMM: 0.833 +graphic: 0.832 +device: 0.822 +debug: 0.818 +semantic: 0.818 +arm: 0.815 +architecture: 0.815 +network: 0.812 +ppc: 0.811 +KVM: 0.808 +vnc: 0.807 +assembly: 0.803 +i386: 0.802 +register: 0.801 +boot: 0.800 +x86: 0.780 +PID: 0.776 +TCG: 0.764 +kernel: 0.762 +socket: 0.754 + +memory.c range assertion hit at full invalidating + +I am able to hit this assertion when a Red Hat 7 guest virtio_net device raises an "Invalidation" of all the TLB entries. This happens in the guest's startup if 'intel_iommu=on' argument is passed to the guest kernel and right IOMMU/ATS devices are declared in qemu's command line. + +Command line: /home/qemu/x86_64-softmmu/qemu-system-x86_64 -name guest=rhel7-test,debug-threads=on -machine pc-q35-5.1,accel=kvm,usb=off,dump-guest-core=off,kernel_irqchip=split -cpu Broadwell,vme=on,ss=on,vmx=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,arch-capabilities=on,xsaveopt=on,pdpe1gb=on,abm=on,skip-l1dfl-vmentry=on,rtm=on,hle=on -m 8096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid d022ecbf-679e-4755-87ce-eb87fc5bbc5d -display none -no-user-config -nodefaults -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device intel-iommu,intremap=on,device-iotlb=on -device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 -device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 -device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 -device pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 -device pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 -device pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 -device pcie-root-port,port=0xe,chassis=7,id=pci.7,bus=pcie.0,addr=0x1.0x6 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -drive file=/home/virtio-test2.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,id=hostnet0,vhost=on,vhostforce=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0d:1d:f2,bus=pci.1,addr=0x0,iommu_platform=on,ats=on -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 -s -msg timestamp=on + +Full backtrace: + +#0 0x00007ffff521370f in raise () at /lib64/libc.so.6 +#1 0x00007ffff51fdb25 in abort () at /lib64/libc.so.6 +#2 0x00007ffff51fd9f9 in _nl_load_domain.cold.0 () at /lib64/libc.so.6 +#3 0x00007ffff520bcc6 in .annobin_assert.c_end () at /lib64/libc.so.6 +#4 0x0000555555888171 in memory_region_notify_one (notifier=0x7ffde05dfde8, entry=0x7ffde5dfe200) at /home/qemu/memory.c:1918 +#5 0x0000555555888247 in memory_region_notify_iommu (iommu_mr=0x555556f6c0b0, iommu_idx=0, entry=...) at /home/qemu/memory.c:1941 +#6 0x0000555555951c8d in vtd_process_device_iotlb_desc (s=0x555557609000, inv_desc=0x7ffde5dfe2d0) + at /home/qemu/hw/i386/intel_iommu.c:2468 +#7 0x0000555555951e6a in vtd_process_inv_desc (s=0x555557609000) at /home/qemu/hw/i386/intel_iommu.c:2531 +#8 0x0000555555951fa5 in vtd_fetch_inv_desc (s=0x555557609000) at /home/qemu/hw/i386/intel_iommu.c:2563 +#9 0x00005555559520e5 in vtd_handle_iqt_write (s=0x555557609000) at /home/qemu/hw/i386/intel_iommu.c:2590 +#10 0x0000555555952b45 in vtd_mem_write (opaque=0x555557609000, addr=136, val=2688, size=4) at /home/qemu/hw/i386/intel_iommu.c:2837 +#11 0x0000555555883e17 in memory_region_write_accessor + (mr=0x555557609330, addr=136, value=0x7ffde5dfe478, size=4, shift=0, mask=4294967295, attrs=...) at /home/qemu/memory.c:483 +#12 0x000055555588401d in access_with_adjusted_size + (addr=136, value=0x7ffde5dfe478, size=4, access_size_min=4, access_size_max=8, access_fn= + 0x555555883d38 <memory_region_write_accessor>, mr=0x555557609330, attrs=...) at /home/qemu/memory.c:544 +#13 0x0000555555886f37 in memory_region_dispatch_write (mr=0x555557609330, addr=136, data=2688, op=MO_32, attrs=...) + at /home/qemu/memory.c:1476 +#14 0x0000555555827a03 in flatview_write_continue + (fv=0x7ffde00935d0, addr=4275634312, attrs=..., ptr=0x7ffff7ff0028, len=4, addr1=136, l=4, mr=0x555557609330) at /home/qemu/exec.c:3146 +#15 0x0000555555827b48 in flatview_write (fv=0x7ffde00935d0, addr=4275634312, attrs=..., buf=0x7ffff7ff0028, len=4) + at /home/qemu/exec.c:3186 +#16 0x0000555555827e9d in address_space_write + (as=0x5555567ca640 <address_space_memory>, addr=4275634312, attrs=..., buf=0x7ffff7ff0028, len=4) at /home/qemu/exec.c:3277 +#17 0x0000555555827f0a in address_space_rw + (as=0x5555567ca640 <address_space_memory>, addr=4275634312, attrs=..., buf=0x7ffff7ff0028, len=4, is_write=true) + at /home/qemu/exec.c:3287 +#18 0x000055555589b633 in kvm_cpu_exec (cpu=0x555556b65640) at /home/qemu/accel/kvm/kvm-all.c:2511 +#19 0x0000555555876ba8 in qemu_kvm_cpu_thread_fn (arg=0x555556b65640) at /home/qemu/cpus.c:1284 +#20 0x0000555555dafff1 in qemu_thread_start (args=0x555556b8c3b0) at util/qemu-thread-posix.c:521 +#21 0x00007ffff55a62de in start_thread () at /lib64/libpthread.so.0 +#22 0x00007ffff52d7e83 in clone () at /lib64/libc.so.6 + +-- + +If we examinate *entry in frame 4 of backtrace: +*entry = {target_as = 0x555556f6c050, iova = 0x0, translated_addr = 0x0, addr_mask = 0xffffffffffffffff, perm = 0x0} + +Which (I think) tries to invalidate all the TLB registers of the device. + +Just deleting that assert is enough for the VM to start and communicate using IOMMU, but maybe a better alternative is possible. We could move it to the caller functions in other cases than IOMMU invalidation, or make it conditional only if not invalidating. + +Guest kernel version: kernel-3.10.0-1136.el7 + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + diff --git a/results/classifier/118/unknown/1886362 b/results/classifier/118/unknown/1886362 new file mode 100644 index 00000000..10fc0e92 --- /dev/null +++ b/results/classifier/118/unknown/1886362 @@ -0,0 +1,818 @@ +register: 0.923 +permissions: 0.915 +debug: 0.899 +virtual: 0.899 +graphic: 0.893 +performance: 0.892 +architecture: 0.879 +device: 0.878 +assembly: 0.869 +user-level: 0.852 +hypervisor: 0.849 +semantic: 0.847 +kernel: 0.842 +arm: 0.832 +TCG: 0.825 +PID: 0.821 +x86: 0.819 +ppc: 0.815 +vnc: 0.813 +socket: 0.806 +network: 0.806 +KVM: 0.803 +boot: 0.802 +risc-v: 0.799 +i386: 0.788 +files: 0.788 +VMM: 0.787 +peripherals: 0.786 +mistranslation: 0.730 + +Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers + +Hello, +This reproducer causes a heap-use-after free. QEMU Built with --enable-sanitizers: +cat << EOF | ./i386-softmmu/qemu-system-i386 -M q35,accel=qtest \ +-qtest stdio -nographic -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe102003b 0x1 0xff +write 0xe1020103 0x1e 0xffffff055c5e5c30be4511d084ffffffffffffffffffffffffffffffffff +write 0xe1020420 0x4 0xffffffff +write 0xe1020424 0x4 0xffffffff +write 0xe102042b 0x1 0xff +write 0xe1020430 0x4 0x055c5e5c +write 0x5c041 0x1 0x04 +write 0x5c042 0x1 0x02 +write 0x5c043 0x1 0xe1 +write 0x5c048 0x1 0x8a +write 0x5c04a 0x1 0x31 +write 0x5c04b 0x1 0xff +write 0xe1020403 0x1 0xff +EOF + +The Output: +==22689==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500026800e at pc 0x55b93bb18bfa bp 0x7fffdbe844f0 sp 0x7fffdbe83cb8 +READ of size 2 at 0x62500026800e thread T0 + #0 in __asan_memcpy (/build/i386-softmmu/qemu-system-i386+) + #1 in lduw_he_p /include/qemu/bswap.h:332:5 + #2 in ldn_he_p /include/qemu/bswap.h:550:1 + #3 in flatview_write_continue /exec.c:3145:19 + #4 in flatview_write /exec.c:3186:14 + #5 in address_space_write /exec.c:3280:18 + #6 in address_space_rw /exec.c:3290:16 + #7 in dma_memory_rw_relaxed /include/sysemu/dma.h:87:18 + #8 in dma_memory_rw /include/sysemu/dma.h:113:12 + #9 in pci_dma_rw /include/hw/pci/pci.h:789:5 + #10 in pci_dma_write /include/hw/pci/pci.h:802:12 + #11 in e1000e_write_to_rx_buffers /hw/net/e1000e_core.c:1412:9 + #12 in e1000e_write_packet_to_guest /hw/net/e1000e_core.c:1582:21 + #13 in e1000e_receive_iov /hw/net/e1000e_core.c:1709:9 + #14 in e1000e_nc_receive_iov /hw/net/e1000e.c:213:12 + #15 in net_tx_pkt_sendv /hw/net/net_tx_pkt.c:544:9 + #16 in net_tx_pkt_send /hw/net/net_tx_pkt.c:620:9 + #17 in net_tx_pkt_send_loopback /hw/net/net_tx_pkt.c:633:11 + #18 in e1000e_tx_pkt_send /hw/net/e1000e_core.c:664:16 + #19 in e1000e_process_tx_desc /hw/net/e1000e_core.c:743:17 + #20 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 + #21 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 + #22 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 + #23 in e1000e_mmio_write /hw/net/e1000e.c:109:5 + #24 in memory_region_write_accessor /memory.c:483:5 + #25 in access_with_adjusted_size /memory.c:544:18 + #26 in memory_region_dispatch_write /memory.c:1476:16 + #27 in flatview_write_continue /exec.c:3146:23 + #28 in flatview_write /exec.c:3186:14 + #29 in address_space_write /exec.c:3280:18 + #30 in qtest_process_command /qtest.c:567:9 + #31 in qtest_process_inbuf /qtest.c:710:9 + #32 in qtest_read /qtest.c:722:5 + #33 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #34 in qemu_chr_be_write /chardev/char.c:200:9 + #35 in fd_chr_read /chardev/char-fd.c:68:9 + #36 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #37 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+) + #38 in glib_pollfds_poll /util/main-loop.c:219:9 + #39 in os_host_main_loop_wait /util/main-loop.c:242:5 + #40 in main_loop_wait /util/main-loop.c:518:11 + #41 in qemu_main_loop /softmmu/vl.c:1664:9 + #42 in main /softmmu/main.c:52:5 + #43 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+) + #44 in _start (/build/i386-softmmu/qemu-system-i386+) + +0x62500026800e is located 14 bytes inside of 138-byte region [0x625000268000,0x62500026808a) +freed by thread T0 here: + #0 in free (/build/i386-softmmu/qemu-system-i386+) + #1 in qemu_vfree /util/oslib-posix.c:238:5 + #2 in address_space_unmap /exec.c:3616:5 + #3 in dma_memory_unmap /include/sysemu/dma.h:148:5 + #4 in pci_dma_unmap /include/hw/pci/pci.h:839:5 + #5 in net_tx_pkt_reset /hw/net/net_tx_pkt.c:453:9 + #6 in e1000e_process_tx_desc /hw/net/e1000e_core.c:749:9 + #7 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 + #8 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 + #9 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 + #10 in e1000e_mmio_write /hw/net/e1000e.c:109:5 + #11 in memory_region_write_accessor /memory.c:483:5 + #12 in access_with_adjusted_size /memory.c:544:18 + #13 in memory_region_dispatch_write /memory.c:1476:16 + #14 in flatview_write_continue /exec.c:3146:23 + #15 in flatview_write /exec.c:3186:14 + #16 in address_space_write /exec.c:3280:18 + #17 in address_space_rw /exec.c:3290:16 + #18 in dma_memory_rw_relaxed /include/sysemu/dma.h:87:18 + #19 in dma_memory_rw /include/sysemu/dma.h:113:12 + #20 in pci_dma_rw /include/hw/pci/pci.h:789:5 + #21 in pci_dma_write /include/hw/pci/pci.h:802:12 + #22 in e1000e_write_to_rx_buffers /hw/net/e1000e_core.c:1412:9 + #23 in e1000e_write_packet_to_guest /hw/net/e1000e_core.c:1582:21 + #24 in e1000e_receive_iov /hw/net/e1000e_core.c:1709:9 + #25 in e1000e_nc_receive_iov /hw/net/e1000e.c:213:12 + #26 in net_tx_pkt_sendv /hw/net/net_tx_pkt.c:544:9 + #27 in net_tx_pkt_send /hw/net/net_tx_pkt.c:620:9 + #28 in net_tx_pkt_send_loopback /hw/net/net_tx_pkt.c:633:11 + #29 in e1000e_tx_pkt_send /hw/net/e1000e_core.c:664:16 + +previously allocated by thread T0 here: + #0 in posix_memalign (/build/i386-softmmu/qemu-system-i386+) + #1 in qemu_try_memalign /util/oslib-posix.c:198:11 + #2 in qemu_memalign /util/oslib-posix.c:214:27 + #3 in address_space_map /exec.c:3558:25 + #4 in dma_memory_map /include/sysemu/dma.h:138:9 + #5 in pci_dma_map /include/hw/pci/pci.h:832:11 + #6 in net_tx_pkt_add_raw_fragment /hw/net/net_tx_pkt.c:391:24 + #7 in e1000e_process_tx_desc /hw/net/e1000e_core.c:731:14 + #8 in e1000e_start_xmit /hw/net/e1000e_core.c:934:9 + #9 in e1000e_set_tctl /hw/net/e1000e_core.c:2431:9 + #10 in e1000e_core_write /hw/net/e1000e_core.c:3265:9 + #11 in e1000e_mmio_write /hw/net/e1000e.c:109:5 + #12 in memory_region_write_accessor /memory.c:483:5 + #13 in access_with_adjusted_size /memory.c:544:18 + #14 in memory_region_dispatch_write /memory.c:1476:16 + #15 in flatview_write_continue /exec.c:3146:23 + #16 in flatview_write /exec.c:3186:14 + #17 in address_space_write /exec.c:3280:18 + #18 in qtest_process_command /qtest.c:567:9 + #19 in qtest_process_inbuf /qtest.c:710:9 + #20 in qtest_read /qtest.c:722:5 + #21 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #22 in qemu_chr_be_write /chardev/char.c:200:9 + #23 in fd_chr_read /chardev/char-fd.c:68:9 + #24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #25 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+) + +-Alex + +Running with '-trace e1000\*': + +e1000e_cb_pci_realize E1000E PCI realize entry +e1000e_mac_set_permanent Set permanent MAC: 52:54:00:12:34:56 +e1000e_cfg_support_virtio Virtio header supported: 0 +e1000e_rx_set_cso RX CSO state set to 0 +e1000e_cb_qdev_reset E1000E qdev reset entry +e1000x_mac_indicate Indicating MAC to guest: 52:54:00:12:34:56 +e1000x_rx_can_recv_disabled link_up: 1, rx_enabled 0, pci_master 0 +e1000x_rx_can_recv_disabled link_up: 1, rx_enabled 0, pci_master 0 +e1000e_vm_state_running VM state is running +[R +0.094581] outl 0xcf8 0x80001010 +[S +0.094604] OK +[R +0.094632] outl 0xcfc 0xe1020000 +[S +0.094654] OK +[R +0.094668] outl 0xcf8 0x80001014 +[S +0.094675] OK +[R +0.094694] outl 0xcf8 0x80001004 +[S +0.094702] OK +[R +0.094712] outw 0xcfc 0x7 +e1000e_rx_start_recv +[S +0.096938] OK +[R +0.096960] outl 0xcf8 0x800010a2 +[S +0.096972] OK +[R +0.096986] write 0xe102003b 0x1 0xff +e1000e_core_write Write to register 0x38, 4 byte(s), value: 0xff +e1000e_vlan_vet Setting VLAN ethernet type 0xFF +[S +0.097019] OK +[R +0.097034] write 0xe1020103 0x1e 0xffffff055c5e5c30be4511d084ffffffffffffffffffffffffffffffffff +e1000e_core_write Write to register 0x100, 4 byte(s), value: 0xff +e1000e_rx_set_rctl RCTL = 0xff +e1000e_rx_desc_buff_sizes buffer sizes: [2048, 0, 0, 0] +e1000e_rx_desc_len RX descriptor length: 16 +e1000e_rx_start_recv +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x104, 4 byte(s), value: 0x5c05ffff +e1000e_core_write Write to register 0x2820, 4 byte(s), value: 0xbe305c5e +e1000e_irq_rdtr_fpd_not_running FPD written while RDTR was not running +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x10c, 4 byte(s), value: 0x84d01145 +e1000e_core_write Write to register 0x2800, 4 byte(s), value: 0xffffffff +e1000e_core_write Write to register 0x2804, 4 byte(s), value: 0xffffffff +e1000e_core_write Write to register 0x2808, 4 byte(s), value: 0xffffffff +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x11c, 4 byte(s), value: 0xffffffff +e1000e_core_write Write to register 0x2810, 4 byte(s), value: 0xff +[S +0.097143] OK +[R +0.097159] write 0xe1020420 0x4 0xffffffff +e1000e_core_write Write to register 0x3800, 4 byte(s), value: 0xffffffff +[S +0.097173] OK +[R +0.097183] write 0xe1020424 0x4 0xffffffff +e1000e_core_write Write to register 0x3804, 4 byte(s), value: 0xffffffff +[S +0.097196] OK +[R +0.097208] write 0xe102042b 0x1 0xff +e1000e_core_write Write to register 0x3808, 4 byte(s), value: 0xff +[S +0.097221] OK +[R +0.097231] write 0xe1020430 0x4 0x055c5e5c +e1000e_core_write Write to register 0x3810, 4 byte(s), value: 0x5c5e5c05 +[S +0.097243] OK +[R +0.097253] write 0x5c041 0x1 0x04 +[S +0.097914] OK +[R +0.097942] write 0x5c042 0x1 0x02 +[S +0.097953] OK +[R +0.097964] write 0x5c043 0x1 0xe1 +[S +0.097972] OK +[R +0.097984] write 0x5c048 0x1 0x8a +[S +0.097992] OK +[R +0.098003] write 0x5c04a 0x1 0x31 +[S +0.098011] OK +[R +0.098022] write 0x5c04b 0x1 0xff +[S +0.098029] OK +[R +0.098040] write 0xe1020403 0x1 0xff +e1000e_core_write Write to register 0x400, 4 byte(s), value: 0xff +e1000e_tx_descr 0xe1020400 : ff31008a 0 +e1000e_core_read Read from register 0x400, 4 byte(s), value: 0xff +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x404, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x408, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x40c, 4 byte(s) +e1000e_core_read Read from register 0x410, 4 byte(s), value: 0x602008 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x414, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x418, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x41c, 4 byte(s) +e1000e_core_read Read from register 0x3800, 4 byte(s), value: 0xfffffff0 +e1000e_core_read Read from register 0x3804, 4 byte(s), value: 0xffffffff +e1000e_core_read Read from register 0x3808, 4 byte(s), value: 0x80 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x42c, 4 byte(s) +e1000e_core_read Read from register 0x3810, 4 byte(s), value: 0x5c05 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x434, 4 byte(s) +e1000e_core_read Read from register 0x3818, 4 byte(s), value: 0x0 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x43c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x3820, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x444, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x448, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x44c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x450, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x454, 4 byte(s) +e1000e_core_read Read from register 0x458, 4 byte(s), value: 0x0 +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x45c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x460, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x464, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x468, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x46c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x470, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x474, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x478, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x47c, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x480, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x484, 4 byte(s) +e1000e_wrn_regs_read_unknown WARNING: Read from unknown register 0x488, 4 byte(s) +e1000e_rx_receive_iov Received vector of 4 fragments +e1000x_vlan_is_vlan_pkt Is VLAN packet: 0, ETH proto: 0x0, VET: 0xFF +e1000e_rx_rss_started Starting RSS processing +e1000e_rx_rss_disabled RSS is disabled +e1000e_rx_rss_dispatched_to_queue Packet being dispatched to queue 0 +e1000e_ring_free_space ring #0: LEN: 1048448, DH: 255, DT: 0 +e1000e_rx_has_buffers ring #0: free descr: 65273, packet size 142, descr buffer size 2048 +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0xfe0, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0xff0, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x1000, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x1010, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +[...] +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x5c020, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x5c030, length: 16 +e1000e_rx_null_descriptor Null RX descriptor!! +e1000e_rx_descr Next RX descriptor: ring #0, PA: 0x5c040, length: 16 +e1000e_rx_desc_buff_write buffer #0, addr: 0xe1020400, offset: 0, from: 0x631000028830, length: 14 +e1000e_core_write Write to register 0x400, 4 byte(s), value: 0xff +e1000e_tx_descr 0xe1020400 : ff31008a 0 +e1000e_irq_rearm_timer Mitigation timer armed for register 0x3820, delay 0 ns +e1000e_irq_set_cause_entry Going to set IRQ cause 0x2, ICR: 0x0 +e1000e_irq_set_cause_exit Set IRQ cause 0x3, ICR: 0x3 +e1000e_irq_fix_icr_asserted ICR_ASSERTED bit fixed: 0x80000003 +e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x80000003, IMS: 0x0) +e1000e_irq_legacy_notify IRQ line state: 0 +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x404, 4 byte(s), value: 0x0 +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x408, 4 byte(s), value: 0x0 +e1000e_wrn_regs_write_unknown WARNING: Write to unknown register 0x40c, 4 byte(s), value: 0x0 +e1000e_rx_desc_buff_write buffer #0, addr: 0xe1020400, offset: 14, from: 0x62500024200e, length: 124 +================================================================= +==32103==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500024200e at pc 0x55cd3c40c9aa bp 0x7ffd97112bf0 sp 0x7ffd971123a0 + + +On 2020/7/10 下午6:37, Li Qiang wrote: +> Paolo Bonzini <email address hidden> 于2020年7月10日周五 上午1:36写道： +>> On 09/07/20 17:51, Li Qiang wrote: +>>> Maybe we should check whether the address is a RAM address in 'dma_memory_rw'? +>>> But it is a hot path. I'm not sure it is right. Hope more discussion. +>> Half of the purpose of dma-helpers.c (as opposed to address_space_* +>> functions in exec.c) is exactly to support writes to MMIO. This is +> Hi Paolo, +> +> Could you please explain more about this(to support writes to MMIO). +> I can just see the dma helpers with sg DMA, not related with MMIO. + + +Please refer doc/devel/memory.rst. + +The motivation of memory API is to allow support modeling different +memory regions. DMA to MMIO is allowed in hardware so Qemu should +emulate this behaviour. + + +> +> +>> especially true of dma_blk_io, which takes care of doing the DMA via a +>> bounce buffer, possibly in multiple steps and even blocking due to +>> cpu_register_map_client. +>> +>> For dma_memory_rw this is not needed, so it only needs to handle +>> QEMUSGList, but I think the design should be the same. +>> +>> However, this is indeed a nightmare for re-entrancy. The easiest +>> solution is to delay processing of descriptors to a bottom half whenever +>> MMIO is doing something complicated. This is also better for latency +>> because it will free the vCPU thread more quickly and leave the work to +>> the I/O thread. +> Do you mean we define a per-e1000e bottom half. And in the MMIO write +> or packet send +> trigger this bh? + + +Probably a TX bh. + + +> So even if we again trigger the MMIO write, then +> second bh will not be executed? + + +Bh is serialized so no re-entrancy issue. + +Thanks + + +> +> +> Thanks, +> Li Qiang +> +>> Paolo +>> + + + + +On 2020/7/14 下午6:48, Li Qiang wrote: +> Jason Wang <email address hidden> 于2020年7月14日周二 下午4:56写道： +>> +>> On 2020/7/10 下午6:37, Li Qiang wrote: +>>> Paolo Bonzini <email address hidden> 于2020年7月10日周五 上午1:36写道： +>>>> On 09/07/20 17:51, Li Qiang wrote: +>>>>> Maybe we should check whether the address is a RAM address in 'dma_memory_rw'? +>>>>> But it is a hot path. I'm not sure it is right. Hope more discussion. +>>>> Half of the purpose of dma-helpers.c (as opposed to address_space_* +>>>> functions in exec.c) is exactly to support writes to MMIO. This is +>>> Hi Paolo, +>>> +>>> Could you please explain more about this(to support writes to MMIO). +>>> I can just see the dma helpers with sg DMA, not related with MMIO. +>> +>> Please refer doc/devel/memory.rst. +>> +>> The motivation of memory API is to allow support modeling different +>> memory regions. DMA to MMIO is allowed in hardware so Qemu should +>> emulate this behaviour. +>> +> I just read the code again. +> So the dma_blk_io is used for some device that will need DMA to +> MMIO(may be related with +> device spec). But for most of the devices(networking card for +> example) there is no need this DMA to MMIO. +> So we just ksuse dma_memory_rw. Is this understanding right? +> +> Then another question. +> Though the dma helpers uses a bouncing buffer, it finally write to the +> device addressspace in 'address_space_unmap'. +> Is there any posibility that we can again write to the MMIO like this issue? + + +I think the point is to make DMA to MMIO work as real hardware. For +e1000e and other networking devices we need make sure such DMA doesn't +break anything. + +Thanks + + +> +> +>>> +>>>> especially true of dma_blk_io, which takes care of doing the DMA via a +>>>> bounce buffer, possibly in multiple steps and even blocking due to +>>>> cpu_register_map_client. +>>>> +>>>> For dma_memory_rw this is not needed, so it only needs to handle +>>>> QEMUSGList, but I think the design should be the same. +>>>> +>>>> However, this is indeed a nightmare for re-entrancy. The easiest +>>>> solution is to delay processing of descriptors to a bottom half whenever +>>>> MMIO is doing something complicated. This is also better for latency +>>>> because it will free the vCPU thread more quickly and leave the work to +>>>> the I/O thread. +>>> Do you mean we define a per-e1000e bottom half. And in the MMIO write +>>> or packet send +>>> trigger this bh? +>> +>> Probably a TX bh. +>> +> I will try to write this tx bh to strength my understanding in this part. +> Maybe reference the virtio-net implementation I think. +> +> +> +> Thanks, +> Li Qiang +> +>>> So even if we again trigger the MMIO write, then +>>> second bh will not be executed? +>> +>> Bh is serialized so no re-entrancy issue. +>> +>> Thanks +>> +>> +>>> +>>> Thanks, +>>> Li Qiang +>>> +>>>> Paolo +>>>> + + + +Another reproducer: (just to record) + +cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc-q35-5.0 \ +-netdev user,id=qtest-bn0 -device e1000e,netdev=qtest-bn0 \ +-display none -nodefaults -nographic -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +write 0xe0000758 0x4 0xfffff1ff +write 0xe0000760 0x6 0xffffdf000000 +write 0xe0000768 0x4 0x0efffff1 +write 0xe0005008 0x4 0x18ffff27 +write 0xe0000c 0x1 0x66 +write 0xe03320 0x1 0xff +write 0xe03620 0x1 0xff +write 0xe00000f3 0x1 0xdf +write 0xe0000100 0x6 0xdfffffdf0000 +write 0xe0000110 0x5 0xdfffffdf00 +write 0xe000011a 0x3 0xffffff +write 0xe0000128 0x5 0x7e00ffffff +write 0xe0000403 0x1 0xdf +write 0xe0000420 0x4 0xdfffffdf +write 0xe000042a 0x3 0xffffff +write 0xe0000438 0x1 0x7e +EOF + +-> https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg05709.html + +On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +> I think the point is to make DMA to MMIO work as real hardware. + +I wouldn't care to give a 100% guarantee that asking a real +h/w device to DMA to itself didn't cause it to misbehave :-) +It's more likely to happen-to-work because the DMA engine bit +of a real h/w device is going to be decoupled somewhat from +the respond-to-memory-transactions-for-registers logic, but +it probably wasn't something the designers were actively +thinking about either... + +> For +> e1000e and other networking devices we need make sure such DMA doesn't +> break anything. + +Yeah, this is the interesting part for QEMU. How should we +structure devices that do DMA so that we can be sure that +the device emulation at least doesn't crash? We could have +a rule that all devices that do DMA must always postpone +all of that DMA to a bottom-half, but that's a lot of +refactoring of a lot of device code... + +thanks +-- PMM + + + +On 2020/7/21 下午8:31, Peter Maydell wrote: +> On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +>> I think the point is to make DMA to MMIO work as real hardware. +> I wouldn't care to give a 100% guarantee that asking a real +> h/w device to DMA to itself didn't cause it to misbehave :-) +> It's more likely to happen-to-work because the DMA engine bit +> of a real h/w device is going to be decoupled somewhat from +> the respond-to-memory-transactions-for-registers logic, but +> it probably wasn't something the designers were actively +> thinking about either... + + +I think some device want such peer to peer transactions: + +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst + + +> +>> For +>> e1000e and other networking devices we need make sure such DMA doesn't +>> break anything. +> Yeah, this is the interesting part for QEMU. How should we +> structure devices that do DMA so that we can be sure that +> the device emulation at least doesn't crash? We could have +> a rule that all devices that do DMA must always postpone +> all of that DMA to a bottom-half, but that's a lot of +> refactoring of a lot of device code... + + +It looks to me the issue happens only for device with loopback + +Simply git grep loopback in hw/net tells me we probably need only to +audit dp8393x and rtl8139. + +Qiang, want to help to audit those devices? + +Thanks + + +> +> thanks +> -- PMM +> + + + +On Tue, 21 Jul 2020 at 14:21, Jason Wang <email address hidden> wrote: +> On 2020/7/21 下午8:31, Peter Maydell wrote: +> > On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +> >> I think the point is to make DMA to MMIO work as real hardware. +> > I wouldn't care to give a 100% guarantee that asking a real +> > h/w device to DMA to itself didn't cause it to misbehave :-) +> > It's more likely to happen-to-work because the DMA engine bit +> > of a real h/w device is going to be decoupled somewhat from +> > the respond-to-memory-transactions-for-registers logic, but +> > it probably wasn't something the designers were actively +> > thinking about either... + +> I think some device want such peer to peer transactions: +> +> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst + +That's a device DMAing to another device, not DMAing to *itself* +(device-to-another-device DMA should work fine in QEMU). And only +a very few devices will ever be sensible targets of the DMA -- +basically things like nvme that have a looks-like-memory area, +or special cases like doorbell registers. + +> > Yeah, this is the interesting part for QEMU. How should we +> > structure devices that do DMA so that we can be sure that +> > the device emulation at least doesn't crash? We could have +> > a rule that all devices that do DMA must always postpone +> > all of that DMA to a bottom-half, but that's a lot of +> > refactoring of a lot of device code... +> +> +> It looks to me the issue happens only for device with loopback + +I think in principle we have a problem for any device that +(a) has memory mapped registers and (b) does DMA reads +whose address is guest-controlled. Loopback isn't a +requirement -- if the guest programs, say, an RX descriptor +base address to point at the device's own registers, you +get exactly the same kind of unexpected-reentrancy. + +thanks +-- PMM + + +On 200721 1444, Peter Maydell wrote: +> On Tue, 21 Jul 2020 at 14:21, Jason Wang <email address hidden> wrote: +> > On 2020/7/21 下午8:31, Peter Maydell wrote: +> > > On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +> > >> I think the point is to make DMA to MMIO work as real hardware. +> > > I wouldn't care to give a 100% guarantee that asking a real +> > > h/w device to DMA to itself didn't cause it to misbehave :-) +> > > It's more likely to happen-to-work because the DMA engine bit +> > > of a real h/w device is going to be decoupled somewhat from +> > > the respond-to-memory-transactions-for-registers logic, but +> > > it probably wasn't something the designers were actively +> > > thinking about either... +> +I searched around but couldn't find anything talking about this case for +real hardware. I also looked at some HDL code for FPGAs that do DMA, but +it seems most of the PCI DMA components are contained in proprietary +IPs, though maybe I'm missing something (I've never programmed +a DMA-capable FPGA). + +> > I think some device want such peer to peer transactions: +> > +> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst +> +> That's a device DMAing to another device, not DMAing to *itself* +> (device-to-another-device DMA should work fine in QEMU). And only +> a very few devices will ever be sensible targets of the DMA -- +> basically things like nvme that have a looks-like-memory area, +> or special cases like doorbell registers. +> +> > > Yeah, this is the interesting part for QEMU. How should we +> > > structure devices that do DMA so that we can be sure that +> > > the device emulation at least doesn't crash? We could have +> > > a rule that all devices that do DMA must always postpone +> > > all of that DMA to a bottom-half, but that's a lot of +> > > refactoring of a lot of device code... +> > +> > +> > It looks to me the issue happens only for device with loopback +> +> I think in principle we have a problem for any device that +> (a) has memory mapped registers and (b) does DMA reads +> whose address is guest-controlled. Loopback isn't a +> requirement -- if the guest programs, say, an RX descriptor +> base address to point at the device's own registers, you +> get exactly the same kind of unexpected-reentrancy. + +Could this be something that we check for in the +pci_dma_* functions in hw/pci/pci.h? There we still have context about +the source device for the dma read/write and could, compare addr against +the device's PCI BARr's. Not sure about: +1.) How to do this without the overhead of convering the addr +to a MemoryRegion, which is normally done, once, at the flatview_write +stage. +2.) What to do if we catch such a DMA request? Quietly drop it? +3.) Non-PCI devices. + +I think this still doesn't cover the even crazier case where: +CPU writes to DEV_A's MMIO +DEV_A writes to DEV_B's MMIO +DEV_B writes to DEV_A's MMIO +and neither DEV_A or DEV_B use BHs... + +-Alex + +> thanks +> -- PMM +> + + + +On 2020/7/21 下午9:44, Peter Maydell wrote: +> On Tue, 21 Jul 2020 at 14:21, Jason Wang <email address hidden> wrote: +>> On 2020/7/21 下午8:31, Peter Maydell wrote: +>>> On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +>>>> I think the point is to make DMA to MMIO work as real hardware. +>>> I wouldn't care to give a 100% guarantee that asking a real +>>> h/w device to DMA to itself didn't cause it to misbehave :-) +>>> It's more likely to happen-to-work because the DMA engine bit +>>> of a real h/w device is going to be decoupled somewhat from +>>> the respond-to-memory-transactions-for-registers logic, but +>>> it probably wasn't something the designers were actively +>>> thinking about either... +>> I think some device want such peer to peer transactions: +>> +>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst +> That's a device DMAing to another device, not DMAing to *itself* +> (device-to-another-device DMA should work fine in QEMU). And only +> a very few devices will ever be sensible targets of the DMA -- +> basically things like nvme that have a looks-like-memory area, +> or special cases like doorbell registers. + + +Well, my understanding is: + +- it's not about whether or not we have an actual device that can do DMA +into itself but whether it's allowed by PCI spec +- it's not really matter whether or not it tries to DMA into itself. +Devices could be taught to DMA into each other's RX: + +e1000e(1) RX DMA to e1000e(2) MMIO (RX) +e1000e(2) RX DMA to e1000e(1) RX + +So we get re-reentrancy again. + + +> +>>> Yeah, this is the interesting part for QEMU. How should we +>>> structure devices that do DMA so that we can be sure that +>>> the device emulation at least doesn't crash? We could have +>>> a rule that all devices that do DMA must always postpone +>>> all of that DMA to a bottom-half, but that's a lot of +>>> refactoring of a lot of device code... +>> +>> It looks to me the issue happens only for device with loopback +> I think in principle we have a problem for any device that +> (a) has memory mapped registers and (b) does DMA reads +> whose address is guest-controlled. Loopback isn't a +> requirement -- if the guest programs, say, an RX descriptor +> base address to point at the device's own registers, you +> get exactly the same kind of unexpected-reentrancy. + + +Right, so about the solution, instead of refactoring DMA I wonder we can +simply detect and fail the RX by device itself. + +Thanks + + +> +> thanks +> -- PMM +> + + + + +On 2020/7/21 下午9:46, Li Qiang wrote: +> Jason Wang <email address hidden> 于2020年7月21日周二 下午9:21写道： +>> +>> On 2020/7/21 下午8:31, Peter Maydell wrote: +>>> On Wed, 15 Jul 2020 at 09:36, Jason Wang <email address hidden> wrote: +>>>> I think the point is to make DMA to MMIO work as real hardware. +>>> I wouldn't care to give a 100% guarantee that asking a real +>>> h/w device to DMA to itself didn't cause it to misbehave :-) +>>> It's more likely to happen-to-work because the DMA engine bit +>>> of a real h/w device is going to be decoupled somewhat from +>>> the respond-to-memory-transactions-for-registers logic, but +>>> it probably wasn't something the designers were actively +>>> thinking about either... +>> +>> I think some device want such peer to peer transactions: +>> +>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst +>> +>> +>>>> For +>>>> e1000e and other networking devices we need make sure such DMA doesn't +>>>> break anything. +>>> Yeah, this is the interesting part for QEMU. How should we +>>> structure devices that do DMA so that we can be sure that +>>> the device emulation at least doesn't crash? We could have +>>> a rule that all devices that do DMA must always postpone +>>> all of that DMA to a bottom-half, but that's a lot of +>>> refactoring of a lot of device code... +>> +>> It looks to me the issue happens only for device with loopback +> IMO I think this is not related-loopback. +> +> It happens when the guest write the MMIO address to the device's +> DMA-related registers. +> The one we see UAF occurs in loopback device because the same +> structure uses in re-entry. +> But we can't say there are no issue for non-loopback device. + + +Yes. + + +>> Simply git grep loopback in hw/net tells me we probably need only to +>> audit dp8393x and rtl8139. +>> +>> Qiang, want to help to audit those devices? +> No problem. Once I finish the e1000e patch I will try to audit those and +> also try to audit some no-loopback device re-entry issue. + + +Thanks. + + +> +> Thanks, +> Li Qiang +> +>> Thanks +>> +>> +>>> thanks +>>> -- PMM +>>> + + + +I can reproduce this problem with QEMU v5.0, but with the current +version, it does not run into this assertion anymore. Seems like this +problem got fixed in the course of time? Could you please check whether +you could still reproduce this? + +This should have been fixed by the qemu_receive_packet/network loopback patches from a few months ago + +Ok, let's mark this as fixed. + diff --git a/results/classifier/118/unknown/1888918 b/results/classifier/118/unknown/1888918 new file mode 100644 index 00000000..8decb48d --- /dev/null +++ b/results/classifier/118/unknown/1888918 @@ -0,0 +1,201 @@ +ppc: 0.944 +peripherals: 0.920 +user-level: 0.918 +TCG: 0.891 +permissions: 0.890 +VMM: 0.886 +risc-v: 0.882 +debug: 0.882 +vnc: 0.881 +graphic: 0.880 +semantic: 0.870 +hypervisor: 0.868 +performance: 0.867 +KVM: 0.866 +assembly: 0.857 +socket: 0.855 +kernel: 0.850 +arm: 0.845 +PID: 0.843 +virtual: 0.840 +device: 0.828 +mistranslation: 0.826 +architecture: 0.805 +files: 0.804 +register: 0.784 +boot: 0.782 +network: 0.782 +x86: 0.770 +i386: 0.757 + +qemu-system-ppc: Floating point instructions do not properly generate the SPE/Embedded Floating-Point Unavailable interrupt + +When emulating certain floating point instructions or vector instructions on PowerPC machines, QEMU does not properly generate the SPE/Embedded Floating-Point Unavailable interrupt. + +As described in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0, available at https://www.nxp.com/docs/en/reference-manual/SPEPEM.pdf: + +> An SPE/embedded floating-point unavailable exception occurs on an attempt to execute any of the +> following instructions and MSR[SPV] is not set: +> * SPE instruction (except brinc) +> * An embedded scalar double-precision instruction +> * A vector single-precision floating-point instructions +> It is not used by embedded scalar single-precision floating-point instructions + +This behavior was partially reported in Bug #1611394, however the issue is larger than what is described in that bug. As mentioned in that bug, some single-precision instructions generate the exception (while they should not), which is incorrect but does not typically produce an incorrect output. What is more of an issue is that several double-precision and vector instructions do not generate the exception (while they should), and this break support for lazy FPU/vector context switching in Linux (for example). + +The upper 32-bit of the double-precision/vector registers (which are in fact hidden in the general purpose registers) is not properly saved/restored, and this causes arithmetic errors. This was observed very frequently on a commercial project that does a lot of double-precision computations. The application works perfectly fine on an MPC8548 CPU, but fails often with QEMU. + +The issue can be reproduced using the attached Linux program "spe-bug.c". This program properly prints the number 42 (as the result of some very simple double-precision computation) on real PowerPC hardware, but prints an incorrect result (typically 0) on QEMU. + +This issue was first discovered in an older version of QEMU, but is also reproduced in the latest: + +# git rev-parse HEAD +7adfbea8fd1efce36019a0c2f198ca73be9d3f18 +# ppc-softmmu/qemu-system-ppc --version +QEMU emulator version 5.0.91 (v5.1.0-rc1-28-g7adfbea8fd-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +Upon further analysis a total of 39 instructions are misbehaving: + +efsabs: raised: 1, expected: 0 +efsnabs: raised: 1, expected: 0 +efsneg: raised: 1, expected: 0 +efdcfs: raised: 0, expected: 1 +efdcfsf: raised: 0, expected: 1 +efdcfsi: raised: 0, expected: 1 +efdcfuf: raised: 0, expected: 1 +efdcfui: raised: 0, expected: 1 +efdctsf: raised: 0, expected: 1 +efdctsi: raised: 0, expected: 1 +efdctsiz: raised: 0, expected: 1 +efdctuf: raised: 0, expected: 1 +efdctui: raised: 0, expected: 1 +efdctuiz: raised: 0, expected: 1 +efscfd: raised: 0, expected: 1 +evfscfsf: raised: 0, expected: 1 +evfscfsi: raised: 0, expected: 1 +evfscfuf: raised: 0, expected: 1 +evfscfui: raised: 0, expected: 1 +evfsctsf: raised: 0, expected: 1 +evfsctsi: raised: 0, expected: 1 +evfsctsiz: raised: 0, expected: 1 +evfsctuf: raised: 0, expected: 1 +evfsctui: raised: 0, expected: 1 +evfsctuiz: raised: 0, expected: 1 +brinc: raised: 0, expected: 1 +efsadd: raised: 1, expected: 0 +efsdiv: raised: 1, expected: 0 +efsmul: raised: 1, expected: 0 +efssub: raised: 1, expected: 0 +evsplatfi: raised: 0, expected: 1 +evsplati: raised: 0, expected: 1 +efscmpeq: raised: 1, expected: 0 +efscmpgt: raised: 1, expected: 0 +efscmplt: raised: 1, expected: 0 +efststeq: raised: 1, expected: 0 +efststgt: raised: 1, expected: 0 +efststlt: raised: 1, expected: 0 +evsel: raised: 0, expected: 1 + +When "raised" is 0 and "expected" is 1, this means that the SPE/Embedded Floating-Point Unavailable interrupt was not generated while it should have. +When "raised" is 1 and "expected" is 0, this means that the SPE/Embedded Floating-Point Unavailable interrupt was generated while it should not have (Bug #1611394). + +A comprehensive program testing all the instructions listed in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0 is posted in the comments of this ticket, and can be used to reproduce the issue, and validate the future fix. + + + +Attaching the test program mentioned in the description. This program (a kernel module, in fact) can be loaded on a Linux system both in QEMU or on real hardware. + +In the next comments, I will attach the detailed output of the test program. + +Attaching the output of the test module (above) when run on a real MPC8548. This is to establish a baseline validating which instructions shall or shall not generate the SPE/Embedded Floating-Point Unavailable interrupt. + +Note that on the MPC8548, it is observed that the "brinc" instruction does generate the interrupt, which contradicts section 4.2.3 SPE/Embedded Floating-Point Unavailable Interrupt of the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0 (see the quote in the description). The test program was modified to pass 100% on real hardware, hence claiming that "brinc" shall generate the interrupt. + +Attaching the output of the test module run on QEMU. As shown in the description, 39 instructions do not comply with the rule described in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0. + +QEMU was run as follows: + +# qemu/ppc-softmmu/qemu-system-ppc -nographic -machine mpc8544ds -kernel buildroot/output/images/uImage -hda buildroot/output/images/rootfs.cpio -append "root=/dev/sda rw single" + +The Linux image is built using buildroot, and the selected configuration is qemu_ppc_mpc8544ds_defconfig with some very mild changes to setup an overlay and initramfs. + +Then, the module is loaded, output can be observed directly in the console, or using dmesg: + +# insmod spe-test.ko + + +I have already written a patch for this issue, that I will be submitting to the community in the next few days. + + +> Note that on the MPC8548, it is observed that the "brinc" +> instruction does generate the interrupt, which contradicts +> section 4.2.3 SPE/Embedded Floating-Point Unavailable Interrupt +> of the Signal Processing Engine (SPE) Programming Environments +> Manual, Rev. 0 (see the quote in the description). The test +> program was modified to pass 100% on real hardware, hence +> claiming that "brinc" shall generate the interrupt. + +I have actually dug up some more on this and changed my mind. There are more references in the PowerPC documentation indicating that "brinc" shall NOT generate the interrupt. + +In the EREF: A Programmer’s Reference Manual for Freescale Power Architecture Processors, Rev. 1 (EIS 2.1), Table 4-22. MSR Field Descriptions clearly states that when SPV==0: + +> The processor cannot execute any category SPE, SP.FD, or SP.FV +> instructions except for the brinc instruction. + +The patch that I am submitting to fix this bug will leave the behavior of "brinc" unchanged (ie: to not generate the interrupt). + + +Testing performed on the patch sent to the mailing list: + +1) make check + +2) Run the "spe-bug.c" userspace program, observed the correct result: + +# qemu/ppc-softmmu/qemu-system-ppc -nographic -machine mpc8544ds -kernel buildroot/output/images/uImage -hda buildroot/output/images/rootfs.cpio -append "root=/dev/sda rw single" +[...] +Run /init as init process +# ./spe-bug +42.000000 +# + +This used to return 0.000000 without the fix. + +3) Run the "spe-test" test module, and observed the correct result: + +# qemu/ppc-softmmu/qemu-system-ppc -nographic -machine mpc8544ds -kernel buildroot/output/images/uImage -hda buildroot/output/images/rootfs.cpio -append "root=/dev/sda rw single" +[...] +Run /init as init process +# insmod spe-test.ko +spe_test: loading out-of-tree module taints kernel. +Begin testing... +Testing efdabs +SPE used in kernel (task=(ptrval), pc=c9042048) +[...] +No errors. +End testing. + +This used to count 39 errors. Attached the full output as well. + +Note that per my previous comment, I have modified the "spe-test" code to expect that the "brinc" instruction does not generate the interrupt, using this diff from the previously attached "spe-test" source code: + +--- spe-test.c.orig 2020-07-25 12:22:23.628315553 -0700 ++++ spe-test.c 2020-07-24 23:12:27.508234566 -0700 +@@ -84,7 +84,7 @@ + TEST_INSN_RD_RA (evfsctuf, 1) \ + TEST_INSN_RD_RA (evfsctui, 1) \ + TEST_INSN_RD_RA (evfsctuiz, 1) \ +- TEST_INSN_RD_RA_RB (brinc, 1) \ ++ TEST_INSN_RD_RA_RB (brinc, 0) \ + TEST_INSN_RD_RA_RB (efdadd, 1) \ + TEST_INSN_RD_RA_RB (efddiv, 1) \ + TEST_INSN_RD_RA_RB (efdmul, 1) \ + + +Assuming that this commit: +https://gitlab.com/qemu-project/qemu/-/commit/8dcdb535d7cc4ba6270bb756e12e1d323254ed4e + +is sufficient to mark this bug as Fix Committed. Please re-open if I am mistaken. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/unknown/1890333 b/results/classifier/118/unknown/1890333 new file mode 100644 index 00000000..2d62e1f8 --- /dev/null +++ b/results/classifier/118/unknown/1890333 @@ -0,0 +1,185 @@ +register: 0.908 +virtual: 0.899 +risc-v: 0.886 +peripherals: 0.882 +i386: 0.879 +permissions: 0.876 +debug: 0.872 +performance: 0.868 +PID: 0.864 +graphic: 0.861 +arm: 0.861 +device: 0.860 +semantic: 0.858 +network: 0.856 +TCG: 0.853 +boot: 0.846 +architecture: 0.846 +kernel: 0.843 +socket: 0.843 +hypervisor: 0.843 +assembly: 0.843 +user-level: 0.841 +files: 0.840 +KVM: 0.838 +vnc: 0.832 +VMM: 0.831 +ppc: 0.830 +mistranslation: 0.820 +x86: 0.812 + +[OSS-Fuzz] Issue 26797: qemu:qemu-fuzz-i386-target-generic-fuzz-virtio-blk: ASSERT: addr < cache->len && 2 <= cache->len - addr + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-device virtio-blk,drive=mydrive \ +-nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001001 +outl 0xcfc 0x6574c1ff +outl 0xcf8 0x8000100e +outl 0xcfc 0xefe5e1e +outl 0xe86 0x3aff9090 +outl 0xe84 0x3aff9090 +outl 0xe8e 0xe +EOF + +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/include/exec/memory_ldst_cached.inc.h:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +Aborted + +I can trigger similar assertions with other VIRTIO devices, as-well. +I reported this at some point in Message-ID: <email address hidden> but never created a Launchpad issue... +-Alex + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26797 + +=== Reproducer (build with --enable-sanitizers) === +cat << EOF | ./qemu-system-i386 -display none \ +-machine accel=qtest, -m 512M -machine q35 \ +-device virtio-blk,drive=disk0 \ +-drive file=null-co://,id=disk0,if=none,format=raw \ +-qtest stdio +outl 0xcf8 0x80001889 +outl 0xcfc 0x1000ffff +outl 0xcf8 0x80001897 +outl 0xcf8 0x80001890 +outl 0xcfc 0x4 +outl 0xcf8 0x800018ff +outl 0xcf8 0x80001897 +inb 0xcfc +outl 0xcf8 0x8000188a +outl 0xcfc 0xd4624 +outl 0xcf8 0x80001897 +outl 0xcf8 0x80001806 +outl 0xcf8 0x80001897 +outl 0xcfc 0xff6ca0ba +outl 0xcf8 0x8000188c +outw 0xcfc 0x14 +outl 0xcf8 0x80001897 +outl 0xcf8 0x8000185a +outl 0xcf8 0x80001897 +outl 0xcfc 0x5f6c6346 +inb 0xcfc +outl 0xcf8 0x80001802 +outl 0xcfc 0x65a6055 +outl 0xcf8 0x80001897 +inb 0xcfc +outl 0xcf8 0x80001889 +outl 0xcfc 0x1869ffff +outl 0xcf8 0x80001812 +outl 0xcf8 0x80001897 +outl 0xcfc 0x5f6c6346 +outl 0xcf8 0x8000188c +outw 0xcfc 0x24 +outl 0xcf8 0x80001890 +outl 0xcf8 0x80001897 +outl 0xcfc 0x1 +outl 0xcf8 0x80001892 +outl 0xcfc 0x1ff04 +outl 0xcf8 0x8000188c +outw 0xcfc 0x1c +outl 0xcf8 0x80001890 +outl 0xcfc 0x1 +outl 0xcf8 0x80001897 +outl 0xcfc 0xfd467562 +outl 0xcf8 0x8000188a +outl 0xcfc 0x245a5546 +outl 0xcf8 0x80001890 +outl 0xcf8 0x80001897 +inb 0xcfc +outl 0xcf8 0x8000188c +outw 0xcfc 0x14 +outl 0xcf8 0x80001897 +outl 0xcf8 0x80001806 +outl 0xcf8 0x80001889 +outl 0xcfc 0x1869ffff +outl 0xcf8 0x80001812 +outl 0xcf8 0x80001897 +outl 0xcfc 0x6c6346 +outl 0xcf8 0x8000188c +outw 0xcfc 0x14 +outl 0xcf8 0x80001890 +outl 0xcf8 0x80001897 +outl 0xcfc 0x1ff04 +EOF + +=== Stack Trace === + +qemu-fuzz-i386-target-generic-fuzz-virtio-blk: /src/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +==46== ERROR: libFuzzer: deadly signal +#0 0x55deb7b59e61 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 +#1 0x55deb7aa1158 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 +#2 0x55deb7a87053 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 +#3 0x7fccd310638f in libpthread.so.0 +#4 0x7fccd273e437 in gsignal +#5 0x7fccd2740039 in abort +#6 0x7fccd2736be6 in libc.so.6 +#7 0x7fccd2736c91 in __assert_fail +#8 0x55deb8416ba3 in address_space_stw_le_cached /src/qemu/include/exec/memory_ldst_cached.h.inc:88:5 +#9 0x55deb8416a40 in stw_le_phys_cached /src/qemu/include/exec/memory_ldst_phys.h.inc:121:5 +#10 0x55deb8416a13 in virtio_stw_phys_cached /src/qemu/include/hw/virtio/virtio-access.h:196:9 +#11 0x55deb8416899 in vring_set_avail_event /src/qemu/hw/virtio/virtio.c:428:5 +#12 0x55deb8406ba8 in virtio_queue_split_set_notification /src/qemu/hw/virtio/virtio.c:437:9 +#13 0x55deb84067a2 in virtio_queue_set_notification /src/qemu/hw/virtio/virtio.c:498:9 +#14 0x55deb84755d3 in virtio_blk_handle_vq /src/qemu/hw/block/virtio-blk.c:795:13 +#15 0x55deb84916ce in virtio_blk_data_plane_handle_output /src/qemu/hw/block/dataplane/virtio-blk.c:165:12 +#16 0x55deb841afaf in virtio_queue_notify_aio_vq /src/qemu/hw/virtio/virtio.c:2325:15 +#17 0x55deb8415adb in virtio_queue_host_notifier_aio_read /src/qemu/hw/virtio/virtio.c:3529:9 +#18 0x55deb892af84 in aio_dispatch_handler /src/qemu/util/aio-posix.c:329:9 +#19 0x55deb8929b8a in aio_dispatch_handlers /src/qemu/util/aio-posix.c:372:20 +#20 0x55deb8929ac0 in aio_dispatch /src/qemu/util/aio-posix.c:382:5 +#21 0x55deb893ae2c in aio_ctx_dispatch /src/qemu/util/async.c:306:5 +#22 0x7fccd3868196 in g_main_context_dispatch +#23 0x55deb8947fed in glib_pollfds_poll /src/qemu/util/main-loop.c:221:9 +#24 0x55deb8947264 in os_host_main_loop_wait /src/qemu/util/main-loop.c:244:5 +#25 0x55deb8946f25 in main_loop_wait /src/qemu/util/main-loop.c:520:11 +#26 0x55deb7b8806a in flush_events /src/qemu/tests/qtest/fuzz/fuzz.c:48:9 +#27 0x55deb7b85a32 in generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:681:17 +#28 0x55deb7b88450 in LLVMFuzzerTestOneInput /src/qemu/tests/qtest/fuzz/fuzz.c:150:5 +#29 0x55deb7a887c1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:595:15 +#30 0x55deb7a73892 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6 +#31 0x55deb7a7994e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:852:9 +#32 0x55deb7aa1932 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 +#33 0x7fccd272983f in __libc_start_main +#34 0x55deb7a4eb38 in _start + +Fix in commit 2d69eba5fe52045b2c8b0d04fd3806414352afc1 + +Hi, + +It seems while the minimized producer doesn't fail the assertion now, the original reproducer provided by OSS-Fuzz[1] can still crash the latest QEMU (1758428, Dec 12, built with --enable-sanitizers --enable-fuzzing). Could anyone check if they trigger different bugs? + +Tested on: + Ubuntu: 20.04.1 5.4.0-58-generic x86_64 + clang: 10.0.0-4ubuntu1 + glibc: 2.31-0ubuntu9.1 + libglib2.0-dev: 2.64.3-1~ubuntu20.04.1 + +[1] https://bugs.launchpad.net/qemu/+bug/1890333/comments/1 + + +There is a new bug that fails the same assertion, and maybe its minimized producer will help: + https://bugs.launchpad.net/qemu/+bug/1908062 + + diff --git a/results/classifier/118/unknown/1892962 b/results/classifier/118/unknown/1892962 new file mode 100644 index 00000000..1aa97131 --- /dev/null +++ b/results/classifier/118/unknown/1892962 @@ -0,0 +1,166 @@ +risc-v: 0.964 +peripherals: 0.929 +permissions: 0.915 +user-level: 0.915 +i386: 0.902 +device: 0.892 +register: 0.889 +architecture: 0.888 +vnc: 0.882 +hypervisor: 0.882 +performance: 0.873 +TCG: 0.872 +graphic: 0.862 +KVM: 0.859 +ppc: 0.854 +socket: 0.854 +assembly: 0.852 +files: 0.852 +virtual: 0.850 +arm: 0.848 +VMM: 0.838 +mistranslation: 0.837 +debug: 0.836 +semantic: 0.831 +kernel: 0.827 +PID: 0.823 +x86: 0.811 +boot: 0.796 +network: 0.782 + +Segfault in usb_bus_from_device + +Hello, +Reproducer: + +cat << EOF | ./qemu-system-i386 -machine q35 \ +-device ich9-usb-ehci1,bus=pcie.0,addr=1d.7,\ +multifunction=on,id=ich9-ehci-1 \ +-device ich9-usb-uhci1,bus=pcie.0,addr=1d.0,\ +multifunction=on,masterbus=ich9-ehci-1.0,firstport=0 \ +-device usb-tablet,bus=ich9-ehci-1.0,port=1,usb_version=1 \ +-display none -nodefaults -qtest stdio -accel qtest +outl 0xcf8 0x8000e803 +outl 0xcfc 0xff00ff00 +outl 0xcf8 0x8000e821 +outb 0xcfc 0xff +outl 0xff10 0x8500057e +clock_step +clock_step +outb 0xff00 0x49 +write 0x2 0x1 0x40 +write 0x400006 0x1 0xfb +write 0x400008 0x1 0x2d +write 0x40000a 0x1 0xe0 +write 0x40000c 0x1 0x16 +write 0x40000e 0x1 0xfa +write 0xfa001c 0x1 0x04 +clock_step +write 0x400006 0x1 0xfb +write 0xfa001d 0x1 0xff +clock_step +write 0x8 0x1 0xe0 +write 0xa 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x1600e8 0x1 0xe1 +write 0x1600eb 0x1 0x30 +clock_step +clock_step +write 0x10 0x1 0xe0 +write 0x12 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +write 0x8 0x1 0xe1 +write 0xa 0x1 0x40 +write 0xb 0x1 0x30 +clock_step +write 0x14 0x1 0xe0 +write 0x16 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +clock_step +write 0x18 0x1 0xe0 +write 0x1a 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +clock_step +write 0x1c 0x1 0xe0 +write 0x1e 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +clock_step +write 0x20 0x1 0xe0 +write 0x22 0x1 0x16 +write 0x1600e6 0x1 0x9c +write 0x6 0x1 0x9c +clock_step +EOF + +The trace: + +... +[S +0.087589] OK +[R +0.087596] write 0x1600e6 0x1 0x9c +OK +[S +0.087603] OK +[R +0.087655] write 0x6 0x1 0x9c +OK +[S +0.087667] OK +[R +0.087675] clock_step +784168@1598406646.189133:usb_uhci_frame_start nr 8 +784168@1598406646.189141:usb_uhci_td_load qh 0x0, td 0x1600e0, ctrl 0x9c0180, token 0x300000e1 +784168@1598406646.189147:usb_uhci_packet_add token 0x0, td 0x1600e0 +784168@1598406646.189151:usb_packet_state_change bus 0, port 1, ep 0, packet 0x611000043c00, state undef -> setup +784168@1598406646.189161:usb_packet_state_change bus 0, port 1, ep 0, packet 0x611000043c00, state setup -> complete +784168@1598406646.189165:usb_uhci_packet_complete_success token 0x0, td 0x1600e0 +784168@1598406646.189168:usb_uhci_packet_del token 0x0, td 0x1600e0 +784168@1598406646.189174:usb_uhci_td_complete qh 0x0, td 0x1600e0 +784168@1598406646.189179:usb_uhci_td_load qh 0x0, td 0x0, ctrl 0x9c0182, token 0x304000e1 +784168@1598406646.189183:usb_uhci_packet_add token 0x0, td 0x0 +784168@1598406646.189187:usb_packet_state_change bus 0, port 1, ep 0, packet 0x611000043d40, state undef -> setup +/home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12: runtime error: member access within null pointer of type 'USBDevice' (aka 'struct USBDevice') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12 in +/home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12: runtime error: member access within null pointer of type 'DeviceState' (aka 'struct DeviceState') +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==784168==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x5599c43df445 bp 0x7ffec2833e50 sp 0x7ffec2833dc0 T0) +==784168==The signal is caused by a READ memory access. +==784168==Hint: address points to the zero page. + #0 0x5599c43df445 in usb_bus_from_device /home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12 + #1 0x5599c43ea95c in usb_packet_set_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:549:23 + #2 0x5599c43e8abd in usb_handle_packet /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:438:17 + #3 0x5599c4b02497 in uhci_handle_td /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-uhci.c:892:9 + #4 0x5599c4afbd26 in uhci_process_frame /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-uhci.c:1075:15 + #5 0x5599c4aed2e3 in uhci_frame_timer /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-uhci.c:1174:9 + #6 0x5599c7620917 in timerlist_run_timers /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-timer.c:572:9 + #7 0x5599c7620e51 in qemu_clock_run_timers /home/alxndr/Development/qemu/general-fuzz/build/../util/qemu-timer.c:586:12 + #8 0x5599c5f35a13 in qtest_clock_warp /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/cpus.c:507:9 + #9 0x5599c61225d8 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:665:9 + #10 0x5599c611063e in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9 + #11 0x5599c610f3e3 in qtest_read /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5 + #12 0x5599c7215762 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9 + #13 0x5599c72158aa in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9 + #14 0x5599c723b514 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9 + #15 0x5599c7127736 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12 + #16 0x7f62623914cd in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd) + #17 0x5599c76b2c67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #18 0x5599c76b0567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #19 0x5599c76aff47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #20 0x5599c5e8e08d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #21 0x5599c382051c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #22 0x7f6261b9acc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #23 0x5599c3775cf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9) + +AddressSanitizer can not provide additional info. +SUMMARY: AddressSanitizer: SEGV /home/alxndr/Development/qemu/general-fuzz/include/hw/usb.h:526:12 in usb_bus_from_device +==784168==ABORTING + +-Alex + +This does not crash for me anymore, so I guess it has been fixed already. Could you still reproduce the crash with the latest version of QEMU? + +OSS-Fuzz never came across this one. Probably fixed + +Ok, let's assume it's fixed - so I'm closing this now. + diff --git a/results/classifier/118/unknown/1892978 b/results/classifier/118/unknown/1892978 new file mode 100644 index 00000000..c6c76c47 --- /dev/null +++ b/results/classifier/118/unknown/1892978 @@ -0,0 +1,838 @@ +hypervisor: 0.884 +peripherals: 0.878 +graphic: 0.866 +virtual: 0.866 +TCG: 0.851 +register: 0.833 +x86: 0.826 +performance: 0.822 +semantic: 0.821 +KVM: 0.816 +risc-v: 0.807 +vnc: 0.806 +debug: 0.803 +mistranslation: 0.802 +VMM: 0.800 +arm: 0.789 +ppc: 0.784 +device: 0.783 +user-level: 0.774 +files: 0.767 +permissions: 0.767 +architecture: 0.767 +assembly: 0.765 +i386: 0.764 +PID: 0.761 +socket: 0.748 +boot: 0.748 +network: 0.745 +kernel: 0.745 + +Heap-use-after-free in e1000e_write_packet_to_guest + +Hello, +Reproducer: +cat << EOF | ./qemu-system-i386 \ +-display none -m 64 -netdev user,id=qtest-bn0 \ +-device e1000e,netdev=qtest-bn0 -display none \ +-nodefaults -accel qtest -qtest stdio +outl 0xcf8 0x80001004 +outl 0xcfc 0x3b2e84ce +outl 0xcf8 0x80001013 +outw 0xcfc 0x2499 +writew 0x990000ff 0x5ea2 +writeq 0x99000429 0x133a940000188101 +outl 0xcfc 0x9b890e04 +writeq 0x4000119 0x5000055ec751c0d +write 0x10707 0x1 0x07 +write 0x51 0x1 0x04 +write 0x53 0x1 0x04 +write 0x140 0x1 0x07 +write 0x141 0x1 0x07 +write 0x142 0x1 0x01 +write 0x148 0x1 0x40 +write 0x14a 0x1 0x7d +write 0x14b 0x1 0xff +writeq 0x4000401 0x413001600027d +EOF + + +The stacktrace: + +[S +0.090759] OK +[R +0.090767] writeq 0x4000401 0x413001600027d +================================================================= +==935641==ERROR: AddressSanitizer: heap-use-after-free on address 0x61900006cc88 at pc 0x555613393d45 bp 0x7fff92f8b7f0 sp 0x7fff92f8b7e8 +READ of size 8 at 0x61900006cc88 thread T0 + #0 0x555613393d44 in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1587:41 + #1 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #2 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #3 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #4 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #5 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #6 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #7 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #8 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #9 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #10 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #11 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #12 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #13 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #14 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #15 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #16 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #17 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #18 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #19 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #20 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #21 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #22 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #23 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #24 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #25 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #26 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #27 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #28 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #29 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #30 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #31 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #32 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #33 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #34 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #35 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #36 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #37 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #38 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #39 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #40 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #41 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #42 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #43 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #44 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #45 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #46 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #47 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #48 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #49 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #50 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #51 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #52 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #53 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #54 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #55 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #56 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #57 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #58 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #59 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #60 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #61 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #62 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #63 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #64 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #65 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #66 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #67 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #68 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #69 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #70 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #71 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #72 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #73 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #74 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #75 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #76 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #77 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #78 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #79 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #80 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #81 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #82 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #83 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #84 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #85 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #86 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #87 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #88 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #89 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #90 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #91 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #92 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #93 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #94 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #95 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #96 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #97 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #98 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #99 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #100 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #101 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #102 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #103 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #104 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #105 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #106 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #107 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #108 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #109 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #110 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #111 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #112 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #113 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #114 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #115 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #116 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #117 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #118 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #119 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #120 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #121 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #122 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #123 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #124 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #125 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #126 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #127 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #128 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #129 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #130 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #131 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #132 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #133 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #134 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #135 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #136 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #137 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #138 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #139 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #140 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #141 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #142 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #143 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #144 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #145 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #146 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #147 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #148 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #149 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #150 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #151 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #152 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #153 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #154 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #155 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #156 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #157 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #158 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #159 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #160 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #161 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #162 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #163 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #164 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #165 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #166 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #167 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #168 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #169 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #170 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #171 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #172 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #173 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #174 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #175 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #176 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #177 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #178 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #179 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #180 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #181 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #182 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #183 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #184 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #185 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #186 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #187 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #188 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #189 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #190 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #191 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #192 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #193 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #194 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #195 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #196 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #197 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #198 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #199 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #200 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #201 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #202 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #203 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #204 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #205 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #206 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #207 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #208 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #209 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #210 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #211 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #212 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #213 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #214 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #215 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #216 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #217 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #218 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #219 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #220 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #221 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #222 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #223 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #224 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #225 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #226 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #227 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #228 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #229 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #230 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #231 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #232 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #233 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #234 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #235 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #236 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #237 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #238 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #239 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #240 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #241 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #242 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #243 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #244 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #245 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #246 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #247 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #248 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #249 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + +0x61900006cc88 is located 8 bytes inside of 1056-byte region [0x61900006cc80,0x61900006d0a0) +freed by thread T0 here: + #0 0x5556126ce1bd in free (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d291bd) + #1 0x555613e2af31 in net_rx_pkt_iovec_realloc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:80:9 + #2 0x555613e18eaa in net_rx_pkt_pull_data /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:103:9 + #3 0x555613e1b5cd in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:158:5 + #4 0x55561338da6e in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1695:5 + #5 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #6 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #7 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #8 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #9 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #10 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #11 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #12 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #13 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #14 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #15 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #16 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #17 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #18 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #19 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #20 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #21 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #22 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #23 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #24 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #25 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #26 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #27 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #28 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #29 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + +previously allocated by thread T0 here: + #0 0x5556126ce43d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d2943d) + #1 0x7fc45f5171b8 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x561b8) + #2 0x555613e18eaa in net_rx_pkt_pull_data /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:103:9 + #3 0x555613e1b5cd in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:158:5 + #4 0x55561338da6e in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1695:5 + #5 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + #6 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 + #7 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 + #8 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 + #9 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 + #10 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 + #11 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 + #12 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 + #13 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 + #14 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 + #15 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #16 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #17 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #18 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #19 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #20 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #21 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 + #22 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 + #23 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 + #24 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 + #25 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 + #26 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 + #27 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 + #28 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 + #29 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 + +SUMMARY: AddressSanitizer: heap-use-after-free /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1587:41 in e1000e_write_packet_to_guest +Shadow bytes around the buggy address: + 0x0c3280005940: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c3280005950: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c3280005960: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c3280005970: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa + 0x0c3280005980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +=>0x0c3280005990: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd + 0x0c32800059e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +Shadow byte legend (one shadow byte represents 8 application bytes): + Addressable: 00 + Partially addressable: 01 02 03 04 05 06 07 + Heap left redzone: fa + Freed heap region: fd + Stack left redzone: f1 + Stack mid redzone: f2 + Stack right redzone: f3 + Stack after return: f5 + Stack use after scope: f8 + Global redzone: f9 + Global init order: f6 + Poisoned by user: f7 + Container overflow: fc + Array cookie: ac + Intra object redzone: bb + ASan internal: fe + Left alloca redzone: ca + Right alloca redzone: cb + Shadow gap: cc +==935641==ABORTING + +-Alex + +This problem does not reproduce for me with the latest version of QEMU anymore. I assume it has been fixed sometime during the past months? Could you please check whether you can still reproduce it with the current version of QEMU? + +I'm this was fixed by Jason's qemu_receive_packet patches. OSS-Fuzz +hasn't seen it in many months + +On 210527 1421, Thomas Huth wrote: +> This problem does not reproduce for me with the latest version of QEMU +> anymore. I assume it has been fixed sometime during the past months? +> Could you please check whether you can still reproduce it with the +> current version of QEMU? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1892978 +> +> Title: +> Heap-use-after-free in e1000e_write_packet_to_guest +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Hello, +> Reproducer: +> cat << EOF | ./qemu-system-i386 \ +> -display none -m 64 -netdev user,id=qtest-bn0 \ +> -device e1000e,netdev=qtest-bn0 -display none \ +> -nodefaults -accel qtest -qtest stdio +> outl 0xcf8 0x80001004 +> outl 0xcfc 0x3b2e84ce +> outl 0xcf8 0x80001013 +> outw 0xcfc 0x2499 +> writew 0x990000ff 0x5ea2 +> writeq 0x99000429 0x133a940000188101 +> outl 0xcfc 0x9b890e04 +> writeq 0x4000119 0x5000055ec751c0d +> write 0x10707 0x1 0x07 +> write 0x51 0x1 0x04 +> write 0x53 0x1 0x04 +> write 0x140 0x1 0x07 +> write 0x141 0x1 0x07 +> write 0x142 0x1 0x01 +> write 0x148 0x1 0x40 +> write 0x14a 0x1 0x7d +> write 0x14b 0x1 0xff +> writeq 0x4000401 0x413001600027d +> EOF +> +> +> The stacktrace: +> +> [S +0.090759] OK +> [R +0.090767] writeq 0x4000401 0x413001600027d +> ================================================================= +> ==935641==ERROR: AddressSanitizer: heap-use-after-free on address 0x61900006cc88 at pc 0x555613393d45 bp 0x7fff92f8b7f0 sp 0x7fff92f8b7e8 +> READ of size 8 at 0x61900006cc88 thread T0 +> #0 0x555613393d44 in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1587:41 +> #1 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #2 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #3 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #4 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #5 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #6 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #7 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #8 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #9 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #10 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #11 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #12 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #13 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #14 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #15 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #16 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #17 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #18 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #19 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #20 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #21 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #22 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #23 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #24 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #25 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #26 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #27 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #28 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #29 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #30 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #31 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #32 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #33 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #34 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #35 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #36 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #37 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #38 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #39 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #40 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #41 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #42 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #43 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #44 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #45 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #46 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #47 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #48 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #49 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #50 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #51 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #52 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #53 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #54 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #55 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #56 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #57 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #58 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #59 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #60 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #61 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #62 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #63 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #64 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #65 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #66 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #67 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #68 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #69 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #70 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #71 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #72 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #73 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #74 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #75 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #76 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #77 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #78 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #79 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #80 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #81 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #82 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #83 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #84 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #85 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #86 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #87 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #88 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #89 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #90 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #91 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #92 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #93 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #94 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #95 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #96 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #97 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #98 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #99 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #100 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #101 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #102 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #103 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #104 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #105 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #106 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #107 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #108 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #109 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #110 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #111 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #112 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #113 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #114 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #115 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #116 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #117 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #118 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #119 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #120 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #121 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #122 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #123 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #124 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #125 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #126 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #127 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #128 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #129 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #130 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #131 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #132 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #133 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #134 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #135 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #136 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #137 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #138 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #139 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #140 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #141 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #142 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #143 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #144 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #145 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #146 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #147 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #148 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #149 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #150 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #151 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #152 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #153 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #154 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #155 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #156 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #157 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #158 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #159 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #160 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #161 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #162 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #163 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #164 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #165 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #166 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #167 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #168 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #169 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #170 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #171 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #172 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #173 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #174 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #175 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #176 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #177 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #178 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #179 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #180 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #181 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #182 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #183 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #184 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #185 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #186 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #187 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #188 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #189 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #190 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #191 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #192 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #193 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #194 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #195 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #196 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #197 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #198 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #199 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #200 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #201 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #202 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #203 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #204 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #205 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #206 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #207 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #208 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #209 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #210 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #211 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #212 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #213 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #214 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #215 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #216 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #217 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #218 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #219 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #220 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #221 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #222 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #223 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #224 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #225 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #226 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #227 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #228 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #229 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #230 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #231 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #232 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #233 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #234 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #235 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #236 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #237 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #238 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #239 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #240 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #241 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #242 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #243 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #244 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #245 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #246 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #247 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #248 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #249 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> +> 0x61900006cc88 is located 8 bytes inside of 1056-byte region [0x61900006cc80,0x61900006d0a0) +> freed by thread T0 here: +> #0 0x5556126ce1bd in free (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d291bd) +> #1 0x555613e2af31 in net_rx_pkt_iovec_realloc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:80:9 +> #2 0x555613e18eaa in net_rx_pkt_pull_data /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:103:9 +> #3 0x555613e1b5cd in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:158:5 +> #4 0x55561338da6e in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1695:5 +> #5 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #6 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #7 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #8 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #9 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #10 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #11 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #12 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #13 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #14 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #15 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #16 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #17 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #18 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #19 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #20 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #21 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #22 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #23 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #24 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #25 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #26 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #27 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #28 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #29 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> +> previously allocated by thread T0 here: +> #0 0x5556126ce43d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d2943d) +> #1 0x7fc45f5171b8 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x561b8) +> #2 0x555613e18eaa in net_rx_pkt_pull_data /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:103:9 +> #3 0x555613e1b5cd in net_rx_pkt_attach_iovec_ex /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_rx_pkt.c:158:5 +> #4 0x55561338da6e in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1695:5 +> #5 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> #6 0x555612812581 in net_tx_pkt_sendv /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:556:9 +> #7 0x55561280fbc8 in net_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:633:9 +> #8 0x555612813f38 in net_tx_pkt_send_loopback /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/net_tx_pkt.c:646:11 +> #9 0x5556133f8c07 in e1000e_tx_pkt_send /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:664:16 +> #10 0x5556133f5359 in e1000e_process_tx_desc /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:743:17 +> #11 0x5556133f302f in e1000e_start_xmit /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:934:9 +> #12 0x5556133daba8 in e1000e_set_tctl /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:2431:9 +> #13 0x55561339901b in e1000e_core_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:3265:9 +> #14 0x555613190f26 in e1000e_mmio_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:109:5 +> #15 0x55561508ade0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 +> #16 0x55561508a2bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 +> #17 0x555615087f70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 +> #18 0x555614ce68a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 +> #19 0x555614ccf878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 +> #20 0x555614ccf3a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 +> #21 0x555614ccfc40 in address_space_rw /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3318:16 +> #22 0x5556133b76c7 in dma_memory_rw_relaxed /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:87:18 +> #23 0x5556133b6ff5 in dma_memory_rw /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:110:12 +> #24 0x5556133b6f3d in pci_dma_rw /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:790:5 +> #25 0x5556133b526a in pci_dma_write /home/alxndr/Development/qemu/general-fuzz/include/hw/pci/pci.h:803:12 +> #26 0x5556133b403f in e1000e_write_to_rx_buffers /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1412:9 +> #27 0x555613393bae in e1000e_write_packet_to_guest /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1582:21 +> #28 0x55561338e419 in e1000e_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1709:9 +> #29 0x55561319680b in e1000e_nc_receive_iov /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e.c:213:12 +> +> SUMMARY: AddressSanitizer: heap-use-after-free /home/alxndr/Development/qemu/general-fuzz/build/../hw/net/e1000e_core.c:1587:41 in e1000e_write_packet_to_guest +> Shadow bytes around the buggy address: +> 0x0c3280005940: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +> 0x0c3280005950: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +> 0x0c3280005960: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +> 0x0c3280005970: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> 0x0c3280005980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +> =>0x0c3280005990: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd +> 0x0c32800059a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +> 0x0c32800059b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +> 0x0c32800059c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +> 0x0c32800059d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +> 0x0c32800059e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +> Shadow byte legend (one shadow byte represents 8 application bytes): +> Addressable: 00 +> Partially addressable: 01 02 03 04 05 06 07 +> Heap left redzone: fa +> Freed heap region: fd +> Stack left redzone: f1 +> Stack mid redzone: f2 +> Stack right redzone: f3 +> Stack after return: f5 +> Stack use after scope: f8 +> Global redzone: f9 +> Global init order: f6 +> Poisoned by user: f7 +> Container overflow: fc +> Array cookie: ac +> Intra object redzone: bb +> ASan internal: fe +> Left alloca redzone: ca +> Right alloca redzone: cb +> Shadow gap: cc +> ==935641==ABORTING +> +> -Alex +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1892978/+subscriptions + + +Ok, thanks, so let's mark it as fixed now :-) + diff --git a/results/classifier/118/unknown/1894071 b/results/classifier/118/unknown/1894071 new file mode 100644 index 00000000..9d30d129 --- /dev/null +++ b/results/classifier/118/unknown/1894071 @@ -0,0 +1,143 @@ +architecture: 0.872 +ppc: 0.853 +permissions: 0.847 +virtual: 0.846 +performance: 0.836 +graphic: 0.836 +semantic: 0.832 +register: 0.831 +arm: 0.829 +mistranslation: 0.828 +peripherals: 0.822 +assembly: 0.819 +KVM: 0.817 +device: 0.814 +TCG: 0.814 +i386: 0.805 +debug: 0.802 +user-level: 0.800 +risc-v: 0.794 +PID: 0.792 +kernel: 0.781 +x86: 0.777 +network: 0.775 +vnc: 0.761 +hypervisor: 0.758 +VMM: 0.752 +socket: 0.750 +files: 0.743 +boot: 0.727 + +qemu-i386-static ioctl return -14 (Bad Address) + +I use qemu-i386-static on 64 bit ARM.But I don't know how to solve some problems. +First I added some ioctl operations. +Then I tried to do some DRM operations like test.c. +This is successful when I use qemu-x86_64-static,but it failed when I use qemu-i386-static. +I can get some strace info like this: + +403 openat(AT_FDCWD,"/dev/dri/card0",O_RDWR|O_LARGEFILE|O_CLOEXEC) = 4 +403 ioctl(4,DRM_IOCTL_GET_CAP,{1,0}) = 0 ({1,1}) +403 ioctl(4,DRM_IOCTL_MODE_GETRESOURCES,{0,0,0,0,0,0,0,0,0,0,0,0}) = 0 ({0,0,0,0,0,2,2,2,0,16384,0,16384}) +403 brk(NULL) = 0x40006000 +403 brk(0x40027000) = 0x40027000 +403 brk(0x40028000) = 0x40028000 +403 ioctl(4,DRM_IOCTL_MODE_GETRESOURCES,{0,1073766816,1073766832,1073766848,0,2,2,2,0,16384,0,16384}) = -1 errno=14 (Bad address) + +And there are similar errors in other self driven operations. +I want to know if it is QEMU's problem, so I hope to get some help. +Thank you! + + + + + + + + + + + +This problem has bothered me for a long time, but I'm not sure whether it's the IOCTL () I added or the QEMU with 32 bits. I hope we can discuss it and help our friends who have other problems. + +Thank you,my friends! + +My environment is that: +schroot + debian(bullseye-i386) +qemu: 5.1.0-rc3 + +Please, send your patches to the QEMU devel mailing list, so we can review them and comment. + +https://wiki.qemu.org/Contribute/SubmitAPatch + +Hi,I found some problems, but I don't know if how to solve it better(I'm not really familiar with the source code). + +When I use ioctl() and use a structure like this: + +struct drm_mode_card_res { + __u64 fb_id_ptr; + __u64 crtc_id_ptr; + __u64 connector_id_ptr; + __u64 encoder_id_ptr; + __u32 count_fbs; + .... +}; + +Look,"fb_id_ptr" is a pointer,and apply for memory allocation through malloc.But I use qemu-i386 on 64 bit ARM.As a result, my pointer has no problem in QEMU, but it is wrong when I use ioctl(bad address).This address is actually an address in QEMU, but it is not the correct address in a 64 bit machine. +Is there any better way to solve this problem? + + + +Hi,I found some problems, but I don't know if how to solve it better(I'm not really familiar with the source code). + +When I use ioctl() and use a structure like this: + +struct drm_mode_card_res { + __u64 fb_id_ptr; + __u64 crtc_id_ptr; + __u64 connector_id_ptr; + __u64 encoder_id_ptr; + __u32 count_fbs; + .... +}; +And in syscall_types.h +STRUCT(drm_mode_card_res, + TYPE_PTRVOID, + TYPE_PTRVOID, + TYPE_PTRVOID, + TYPE_PTRVOID, + TYPE_INT, + ... + ) +Some code: + ... + if (res.count_fbs) { + res.fb_id_ptr = VOID2U64(drmMalloc(res.count_fbs*sizeof(uint32_t))); + if (!res.fb_id_ptr) + goto err_allocs; + } + ... + +This is strace: +openat(AT_FDCWD,"/dev/dri/card0",O_RDWR|O_LARGEFILE|O_CLOEXEC) = 4 +9469 ioctl(4,DRM_IOCTL_GET_CAP,{1,0}) = 0 ({1,1}) +9469 ioctl(4,DRM_IOCTL_MODE_GETRESOURCES,{0x0,0x0,0x0,0x0,0,0,0,0,0,0,0,0}) = 0 ({0x0,0x0,0x0,0x0,0,2,2,2,0,16384,0,16384}) +9469 brk(NULL) = 0x40006000 +9469 brk(0x40027000) = 0x40027000 +9469 brk(0x40028000) = 0x40028000 +9469 ioctl(4,DRM_IOCTL_MODE_GETRESOURCES,{0x0,0x0,0x400061a0,0x0,0,2,1073832368,0,0,16384,0,16384}) = -1 errno=14 (Bad address) +9469 brk(0x40027000) = 0x40027000 + +Look +9469 ioctl(4,DRM_IOCTL_MODE_GETRESOURCES,{0x0,0x0,0x400061a0,0x0,0,2,1073832368,0,0,16384,0,16384}) = -1 errno=14 (Bad address) + +Why does memory overrun occur here??? +I think this is right: +{0x0,0x400061a0,1073832368(0x400061a0),0x400061c0,0,2,2,2,0,16384,0,16384} + +Who can help me? Thank you! + +You need to use IOCTL_SPECIAL() or STRUCT_SPECIAL() macro to convert the target address to the host address. + +Again, share your patches on the qemu-devel mailing list if you want help. + diff --git a/results/classifier/118/unknown/1895310 b/results/classifier/118/unknown/1895310 new file mode 100644 index 00000000..6c17ada7 --- /dev/null +++ b/results/classifier/118/unknown/1895310 @@ -0,0 +1,137 @@ +hypervisor: 0.834 +peripherals: 0.816 +arm: 0.808 +register: 0.808 +x86: 0.808 +semantic: 0.805 +device: 0.801 +mistranslation: 0.799 +graphic: 0.798 +performance: 0.794 +virtual: 0.794 +permissions: 0.792 +risc-v: 0.789 +architecture: 0.777 +files: 0.776 +network: 0.775 +user-level: 0.774 +assembly: 0.772 +debug: 0.772 +kernel: 0.772 +boot: 0.765 +i386: 0.759 +socket: 0.757 +TCG: 0.753 +PID: 0.753 +vnc: 0.749 +KVM: 0.747 +VMM: 0.742 +ppc: 0.716 + +Heap-overflow (read) in sd_erase + +Hello, +One more bug in sd.c ... + +cat << EOF | ./qemu-system-i386 -nodefaults \ +-device sdhci-pci,sd-spec-version=3 \ +-device sd-card,drive=mydrive \ +-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \ +-nographic -qtest stdio -m 64m -trace 'sd*' +outl 0xcf8 0x80001003 +outl 0xcfc 0xd735d735 +outl 0xcf8 0x80001011 +outl 0xcfc 0x3405064c +write 0x5064c2c 0x1 0xd7 +write 0x5064c0f 0x1 0xf7 +write 0x5064c05 0x1 0xd7 +write 0x5064c0a 0x1 0x84 +write 0x5064c0b 0x1 0x4c +write 0x5064c0c 0x1 0x11 +write 0x5064c0f 0x1 0xa9 +write 0x5064c0f 0x1 0x02 +write 0x5064c0f 0x1 0x03 +write 0x5064c0e 0x1 0x2c +write 0x5064c0f 0x1 0x06 +write 0x5064c0f 0x1 0xe1 +write 0x5064c0f 0x1 0x60 +write 0x5064c0f 0x1 0x26 +EOF + + +The crash: +==133840==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x607000059e78 at pc 0x55abd1d761e6 bp 0x7ffc12800630 sp 0x7ffc12800628 +READ of size 8 at 0x607000059e78 thread T0 + #0 0x55abd1d761e5 in test_bit /home/alxndr/Development/qemu/general-fuzz/include/qemu/bitops.h:135:19 + #1 0x55abd1d6cb1e in sd_erase /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:771:13 + #2 0x55abd1d4c893 in sd_normal_command /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:1412:13 + #3 0x55abd1d33c5d in sd_do_command /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:1724:17 + #4 0x55abd20117a4 in sdbus_do_command /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/core.c:99:16 + #5 0x55abd27ecc90 in sdhci_send_command /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:326:12 + #6 0x55abd27e16ed in sdhci_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:1136:9 + #7 0x55abd43aacc0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5 + #8 0x55abd43aa19d in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18 + #9 0x55abd43a7e50 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16 + #10 0x55abd3de5dc6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23 + #11 0x55abd3dced98 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14 + #12 0x55abd3dce8c8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18 + #13 0x55abd3ffabbc in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:567:9 + #14 0x55abd3feb8be in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9 + #15 0x55abd3fea663 in qtest_read /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5 + #16 0x55abd51cb9a2 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9 + #17 0x55abd51cbaea in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9 + #18 0x55abd51e6264 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9 + #19 0x55abd515bef6 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12 + #20 0x7fd5d58bd4cd in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd) + #21 0x55abd54db327 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9 + #22 0x55abd54d8c27 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5 + #23 0x55abd54d8607 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11 + #24 0x55abd3d55afd in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9 + #25 0x55abd16df67c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5 + #26 0x7fd5d4ec0cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #27 0x55abd1634e59 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d3ee59) + +0x607000059e78 is located 0 bytes to the right of 72-byte region [0x607000059e30,0x607000059e78) +allocated by thread T0 here: + #0 0x55abd16ad712 in calloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2db7712) + #1 0x55abd1d75464 in bitmap_try_new /home/alxndr/Development/qemu/general-fuzz/include/qemu/bitmap.h:96:12 + #2 0x55abd1d74bd4 in bitmap_new /home/alxndr/Development/qemu/general-fuzz/include/qemu/bitmap.h:101:26 + #3 0x55abd1d67b68 in sd_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:576:21 + #4 0x55abd47f34b2 in device_transitional_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:1114:9 + #5 0x55abd47f8ca9 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:182:13 + #6 0x55abd47afdbd in bus_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/bus.c:94:9 + #7 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #8 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #9 0x55abd47ec5f8 in device_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:358:9 + #10 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #11 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #12 0x55abd47afdbd in bus_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/bus.c:94:9 + #13 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #14 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #15 0x55abd47ec5f8 in device_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/qdev.c:358:9 + #16 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #17 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #18 0x55abd47afdbd in bus_reset_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/bus.c:94:9 + #19 0x55abd47fdac3 in resettable_child_foreach /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:96:9 + #20 0x55abd47f8685 in resettable_phase_hold /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:173:5 + #21 0x55abd47f6b28 in resettable_assert_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:60:5 + #22 0x55abd47f68cf in resettable_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:45:5 + #23 0x55abd47fb779 in resettable_cold_reset_fn /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/resettable.c:269:5 + #24 0x55abd47f67e5 in qemu_devices_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/core/reset.c:69:9 + #25 0x55abd35a5c1e in pc_machine_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/i386/pc.c:1901:5 + #26 0x55abd3d52d9e in qemu_system_reset /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1403:9 + #27 0x55abd3d67d2e in qemu_init /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:4458:5 + #28 0x55abd16df677 in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:49:5 + #29 0x7fd5d4ec0cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + +SUMMARY: AddressSanitizer: heap-buffer-overflow /home/alxndr/Development/qemu/general-fuzz/include/qemu/bitops.h:135:19 in test_bit + +-Alex + +Tentative fix: +https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg06828.html + +Fixed in commit 1bd6fd8ed5933bfba53e5f5eadebd845094c3707. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/unknown/1897481 b/results/classifier/118/unknown/1897481 new file mode 100644 index 00000000..24417ab0 --- /dev/null +++ b/results/classifier/118/unknown/1897481 @@ -0,0 +1,2106 @@ +debug: 0.836 +user-level: 0.829 +risc-v: 0.826 +semantic: 0.813 +PID: 0.813 +architecture: 0.812 +register: 0.811 +device: 0.810 +permissions: 0.808 +files: 0.808 +mistranslation: 0.807 +assembly: 0.805 +virtual: 0.804 +graphic: 0.801 +kernel: 0.800 +arm: 0.798 +socket: 0.796 +network: 0.795 +performance: 0.794 +boot: 0.786 +VMM: 0.785 +KVM: 0.784 +ppc: 0.779 +x86: 0.764 +vnc: 0.758 +TCG: 0.758 +hypervisor: 0.752 +i386: 0.723 +peripherals: 0.713 + +qemu crashes with VGA pass-through, e-GPU, nvidia 1060 + +I try to pass-through nvidia 1060 6gb card, which is connected via ExpressCard (EXP-GDC converter). + +I can successfully run my virtual machine without pass-through, but when I try to add the devices, qemu crashes. + +The coredump contains: + +Stack trace of thread 3289311: +#0 0x0000000000614c49 memory_region_update_container_subregions (qemu-system-x86_64 + 0x214c49) +#1 0x00000000005c0e8c vfio_probe_nvidia_bar0_quirk (qemu-system-x86_64 + 0x1c0e8c) +#2 0x00000000005bcec0 vfio_realize (qemu-system-x86_64 + 0x1bcec0) +#3 0x000000000079b423 pci_qdev_realize (qemu-system-x86_64 + 0x39b423) +#4 0x00000000006facda device_set_realized (qemu-system-x86_64 + 0x2facda) +#5 0x0000000000887e57 property_set_bool (qemu-system-x86_64 + 0x487e57) +#6 0x000000000088ac48 object_property_set (qemu-system-x86_64 + 0x48ac48) +#7 0x000000000088d1d2 object_property_set_qobject (qemu-system-x86_64 + 0x48d1d2) +#8 0x000000000088b1f7 object_property_set_bool (qemu-system-x86_64 + 0x48b1f7) +#9 0x0000000000693785 qdev_device_add (qemu-system-x86_64 + 0x293785) +#10 0x000000000061aad0 device_init_func (qemu-system-x86_64 + 0x21aad0) +#11 0x000000000098c87b qemu_opts_foreach (qemu-system-x86_64 + 0x58c87b) +#12 0x00000000006211cb qemu_init (qemu-system-x86_64 + 0x2211cb) +#13 0x00000000005002aa main (qemu-system-x86_64 + 0x1002aa) +#14 0x00007fce8af21152 __libc_start_main (libc.so.6 + 0x28152) +#15 0x000000000050087e _start (qemu-system-x86_64 + 0x10087e) + +The whole running command is pretty long, since I use libvirt to manage my machines: + +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-2-Win10 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-Win10/.config \ +QEMU_AUDIO_DRV=spice \ +/usr/bin/qemu-system-x86_64 \ +-name guest=Win10,debug-threads=on \ +-S \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2-ovmf/x64/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/Win10_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ +-machine pc-q35-5.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ +-cpu host,migratable=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff \ +-m 8192 \ +-overcommit mem-lock=off \ +-smp 2,sockets=2,cores=1,threads=1 \ +-uuid 7043c77b-4903-4527-8089-9679d9a17fee \ +-no-user-config \ +-nodefaults \ +-chardev stdio,mux=on,id=charmonitor \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-hpet \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \ +-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \ +-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \ +-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \ +-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \ +-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \ +-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \ +-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \ +-blockdev '{"driver":"file","filename":"/home/sergiy/VirtualBox VMs/win4games.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"driver":"raw","file":"libvirt-2-storage"}' \ +-device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1 \ +-blockdev '{"driver":"file","filename":"/home/sergiy/Downloads/Win10_2004_Ukrainian_x64.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}' \ +-device ide-cd,bus=ide.1,drive=libvirt-1-format,id=sata0-0-1 \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev spicevmc,id=charchannel0,name=vdagent \ +-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \ +-spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \ +-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \ +-chardev spicevmc,id=charredir0,name=usbredir \ +-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=1 \ +-chardev spicevmc,id=charredir1,name=usbredir \ +-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=2 \ +-device vfio-pci,host=0000:04:00.0,id=hostdev0,bus=pci.4,multifunction=on,addr=0x0 \ +-device vfio-pci,host=0000:04:00.1,id=hostdev1,bus=pci.4,addr=0x0.0x1 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on + +I've forced vfio_pci module for the VGA, and ensured that lspci shows + + Kernel driver in use: vfio_pci + +My laptop is Thinkpad x230, that runs on Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz. +I run 5.8.6-1-MANJARO kernel and run QEMU emulator version 5.1.0. + +Thank you for your attention. I'd love to provide more information, but I don't know what else matters. + +Please attach output from `dmesg` and `sudo lspci -vvv`, both from the host. Laptops typically don't provide sufficient resources for GPUs attached like this, so my guess is that we're trying to add a quirk on top of a BAR that isn't mapped. If that's the case, the following host kernel options might help: pci=realloc,assign-busses,nocrs + +dmesg: + +[ 0.000000] microcode: microcode updated early to revision 0x21, date = 2019-02-13 +[ 0.000000] Linux version 5.8.6-1-MANJARO (builder@db927223e331) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP PREEMPT Thu Sep 3 14:19:36 UTC 2020 +[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.8-x86_64 root=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 rw resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 resume_offset=7829504 intel_iommu=on quiet resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 resume_offset=7829504 intel_iommu=on +[ 0.000000] KERNEL supported cpus: +[ 0.000000] Intel GenuineIntel +[ 0.000000] AMD AuthenticAMD +[ 0.000000] Hygon HygonGenuine +[ 0.000000] Centaur CentaurHauls +[ 0.000000] zhaoxin Shanghai +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' +[ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' +[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 +[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000008ffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000000090000-0x00000000000bffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000020200000-0x0000000040003fff] usable +[ 0.000000] BIOS-e820: [mem 0x0000000040004000-0x0000000040004fff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000040005000-0x00000000cfef6fff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000cfef7000-0x00000000d00f8fff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000d00f9000-0x00000000d684efff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000d684f000-0x00000000d6a4efff] type 20 +[ 0.000000] BIOS-e820: [mem 0x00000000d6a4f000-0x00000000dae9efff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000dae9f000-0x00000000daf9efff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000daf9f000-0x00000000daffefff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x00000000dafff000-0x00000000daffffff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000db000000-0x00000000df9fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000f80f8000-0x00000000f80f8fff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041e5fffff] usable +[ 0.000000] BIOS-e820: [mem 0x000000041e600000-0x000000041effffff] reserved +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] efi: EFI v2.31 by Lenovo +[ 0.000000] efi: ACPI 2.0=0xdaffe014 ACPI=0xdaffe000 SMBIOS=0xdae9e000 +[ 0.000000] SMBIOS 2.7 present. +[ 0.000000] DMI: LENOVO 2325KZ5/2325KZ5, BIOS G2ETB5WW (2.75 ) 04/09/2019 +[ 0.000000] tsc: Fast TSC calibration using PIT +[ 0.000000] tsc: Detected 2594.172 MHz processor +[ 0.000921] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000923] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000929] last_pfn = 0x41e600 max_arch_pfn = 0x400000000 +[ 0.000933] MTRR default type: uncachable +[ 0.000934] MTRR fixed ranges enabled: +[ 0.000935] 00000-9FFFF write-back +[ 0.000936] A0000-BFFFF uncachable +[ 0.000937] C0000-FFFFF write-protect +[ 0.000938] MTRR variable ranges enabled: +[ 0.000939] 0 base 0FFC00000 mask FFFC00000 write-protect +[ 0.000940] 1 base 000000000 mask F80000000 write-back +[ 0.000941] 2 base 080000000 mask FC0000000 write-back +[ 0.000942] 3 base 0C0000000 mask FE0000000 write-back +[ 0.000943] 4 base 0DC000000 mask FFC000000 uncachable +[ 0.000944] 5 base 0DB000000 mask FFF000000 uncachable +[ 0.000944] 6 base 100000000 mask F00000000 write-back +[ 0.000945] 7 base 200000000 mask E00000000 write-back +[ 0.000946] 8 base 400000000 mask FE0000000 write-back +[ 0.000947] 9 base 41F000000 mask FFF000000 uncachable +[ 0.001364] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.001580] last_pfn = 0xdb000 max_arch_pfn = 0x400000000 +[ 0.011180] check: Scanning 1 areas for low memory corruption +[ 0.011968] Secure boot could not be determined +[ 0.011969] RAMDISK: [mem 0x3676b000-0x373acfff] +[ 0.011975] ACPI: Early table checksum verification disabled +[ 0.011979] ACPI: RSDP 0x00000000DAFFE014 000024 (v02 LENOVO) +[ 0.011982] ACPI: XSDT 0x00000000DAFFE170 0000C4 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.011988] ACPI: FACP 0x00000000DAFE5000 00010C (v05 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.011994] ACPI: DSDT 0x00000000DAFE7000 011383 (v01 LENOVO TP-G2 00002750 INTL 20061109) +[ 0.011997] ACPI: FACS 0x00000000DAF5A000 000040 +[ 0.012000] ACPI: SLIC 0x00000000DAFFD000 000176 (v01 LENOVO TP-G2 00002750 PTL 00000001) +[ 0.012003] ACPI: TCPA 0x00000000DAFFC000 000032 (v02 PTL LENOVO 06040000 LNVO 00000001) +[ 0.012006] ACPI: SSDT 0x00000000DAFFB000 000408 (v01 LENOVO TP-SSDT2 00000200 INTL 20061109) +[ 0.012009] ACPI: SSDT 0x00000000DAFFA000 000033 (v01 LENOVO TP-SSDT1 00000100 INTL 20061109) +[ 0.012012] ACPI: SSDT 0x00000000DAFF9000 0007A8 (v01 LENOVO SataAhci 00001000 INTL 20061109) +[ 0.012014] ACPI: HPET 0x00000000DAFE3000 000038 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012017] ACPI: APIC 0x00000000DAFE2000 000098 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012020] ACPI: MCFG 0x00000000DAFE1000 00003C (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012023] ACPI: ECDT 0x00000000DAFE0000 000052 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012026] ACPI: FPDT 0x00000000DAFDF000 000064 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012028] ACPI: ASF! 0x00000000DAFE6000 0000A5 (v32 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012031] ACPI: UEFI 0x00000000DAFDE000 00003E (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012034] ACPI: UEFI 0x00000000DAFDD000 000042 (v01 PTL COMBUF 00000001 PTL 00000001) +[ 0.012037] ACPI: POAT 0x00000000DAFDC000 000055 (v03 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012040] ACPI: SSDT 0x00000000DAFDB000 000C79 (v01 PmRef Cpu0Ist 00003000 INTL 20061109) +[ 0.012043] ACPI: SSDT 0x00000000DAFDA000 000A83 (v01 PmRef CpuPm 00003000 INTL 20061109) +[ 0.012046] ACPI: DMAR 0x00000000DAFD9000 0000B8 (v01 INTEL SNB 00000001 INTL 00000001) +[ 0.012049] ACPI: UEFI 0x00000000DAFD8000 000292 (v01 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012052] ACPI: DBG2 0x00000000DAFD7000 0000E9 (v00 LENOVO TP-G2 00002750 PTL 00000002) +[ 0.012059] ACPI: Local APIC address 0xfee00000 +[ 0.012101] No NUMA configuration found +[ 0.012101] Faking a node at [mem 0x0000000000000000-0x000000041e5fffff] +[ 0.012105] NODE_DATA(0) allocated [mem 0x41e5ef000-0x41e5f2fff] +[ 0.012143] Zone ranges: +[ 0.012144] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.012145] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] +[ 0.012146] Normal [mem 0x0000000100000000-0x000000041e5fffff] +[ 0.012147] Device empty +[ 0.012148] Movable zone start for each node +[ 0.012148] Early memory node ranges +[ 0.012149] node 0: [mem 0x0000000000001000-0x000000000008ffff] +[ 0.012150] node 0: [mem 0x0000000000100000-0x000000001fffffff] +[ 0.012151] node 0: [mem 0x0000000020200000-0x0000000040003fff] +[ 0.012151] node 0: [mem 0x0000000040005000-0x00000000cfef6fff] +[ 0.012152] node 0: [mem 0x00000000d00f9000-0x00000000d684efff] +[ 0.012153] node 0: [mem 0x00000000dafff000-0x00000000daffffff] +[ 0.012153] node 0: [mem 0x0000000100000000-0x000000041e5fffff] +[ 0.012637] Zeroed struct page in unavailable ranges: 46628 pages +[ 0.012639] Initmem setup node 0 [mem 0x0000000000001000-0x000000041e5fffff] +[ 0.012640] On node 0 totalpages: 4147676 +[ 0.012642] DMA zone: 64 pages used for memmap +[ 0.012642] DMA zone: 92 pages reserved +[ 0.012643] DMA zone: 3983 pages, LIFO batch:0 +[ 0.012668] DMA32 zone: 13650 pages used for memmap +[ 0.012669] DMA32 zone: 873549 pages, LIFO batch:63 +[ 0.018035] Normal zone: 51096 pages used for memmap +[ 0.018038] Normal zone: 3270144 pages, LIFO batch:63 +[ 0.038035] Reserving Intel graphics memory at [mem 0xdba00000-0xdf9fffff] +[ 0.038332] ACPI: PM-Timer IO Port: 0x408 +[ 0.038335] ACPI: Local APIC address 0xfee00000 +[ 0.038343] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) +[ 0.038343] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) +[ 0.038355] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 +[ 0.038358] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.038359] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.038361] ACPI: IRQ0 used by override. +[ 0.038362] ACPI: IRQ9 used by override. +[ 0.038364] Using ACPI (MADT) for SMP configuration information +[ 0.038365] ACPI: HPET id: 0x8086a301 base: 0xfed00000 +[ 0.038370] TSC deadline timer available +[ 0.038371] smpboot: Allowing 8 CPUs, 4 hotplug CPUs +[ 0.038390] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff] +[ 0.038392] PM: hibernation: Registered nosave memory: [mem 0x00090000-0x000bffff] +[ 0.038393] PM: hibernation: Registered nosave memory: [mem 0x000c0000-0x000fffff] +[ 0.038394] PM: hibernation: Registered nosave memory: [mem 0x20000000-0x201fffff] +[ 0.038395] PM: hibernation: Registered nosave memory: [mem 0x40004000-0x40004fff] +[ 0.038397] PM: hibernation: Registered nosave memory: [mem 0xcfef7000-0xd00f8fff] +[ 0.038398] PM: hibernation: Registered nosave memory: [mem 0xd684f000-0xd6a4efff] +[ 0.038399] PM: hibernation: Registered nosave memory: [mem 0xd6a4f000-0xdae9efff] +[ 0.038400] PM: hibernation: Registered nosave memory: [mem 0xdae9f000-0xdaf9efff] +[ 0.038400] PM: hibernation: Registered nosave memory: [mem 0xdaf9f000-0xdaffefff] +[ 0.038402] PM: hibernation: Registered nosave memory: [mem 0xdb000000-0xdf9fffff] +[ 0.038402] PM: hibernation: Registered nosave memory: [mem 0xdfa00000-0xf80f7fff] +[ 0.038403] PM: hibernation: Registered nosave memory: [mem 0xf80f8000-0xf80f8fff] +[ 0.038403] PM: hibernation: Registered nosave memory: [mem 0xf80f9000-0xfed1bfff] +[ 0.038404] PM: hibernation: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff] +[ 0.038405] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xffffffff] +[ 0.038406] [mem 0xdfa00000-0xf80f7fff] available for PCI devices +[ 0.038408] Booting paravirtualized kernel on bare hardware +[ 0.038411] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370452778343963 ns +[ 0.043530] setup_percpu: NR_CPUS:320 nr_cpumask_bits:320 nr_cpu_ids:8 nr_node_ids:1 +[ 0.043778] percpu: Embedded 56 pages/cpu s192512 r8192 d28672 u262144 +[ 0.043785] pcpu-alloc: s192512 r8192 d28672 u262144 alloc=1*2097152 +[ 0.043786] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 +[ 0.043809] Built 1 zonelists, mobility grouping on. Total pages: 4082774 +[ 0.043810] Policy zone: Normal +[ 0.043811] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.8-x86_64 root=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 rw resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 resume_offset=7829504 intel_iommu=on quiet resume=UUID=f04fa3cc-b1c5-433a-896b-7194abdefa13 resume_offset=7829504 intel_iommu=on +[ 0.043874] DMAR: IOMMU enabled +[ 0.043916] DMAR: IOMMU enabled +[ 0.044717] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes, linear) +[ 0.045120] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) +[ 0.045211] mem auto-init: stack:byref_all, heap alloc:on, heap free:off +[ 0.086772] Memory: 16117516K/16590704K available (14339K kernel code, 1480K rwdata, 4656K rodata, 1648K init, 3016K bss, 473188K reserved, 0K cma-reserved) +[ 0.086780] random: get_random_u64 called from __kmem_cache_create+0x3e/0x600 with crng_init=0 +[ 0.086908] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 +[ 0.086920] Kernel/User page tables isolation: enabled +[ 0.086939] ftrace: allocating 40167 entries in 157 pages +[ 0.101966] ftrace: allocated 157 pages with 5 groups +[ 0.102079] rcu: Preemptible hierarchical RCU implementation. +[ 0.102080] rcu: RCU dyntick-idle grace-period acceleration is enabled. +[ 0.102081] rcu: RCU restricting CPUs from NR_CPUS=320 to nr_cpu_ids=8. +[ 0.102082] rcu: RCU priority boosting: priority 1 delay 500 ms. +[ 0.102083] Trampoline variant of Tasks RCU enabled. +[ 0.102083] Rude variant of Tasks RCU enabled. +[ 0.102084] rcu: RCU calculated value of scheduler-enlistment delay is 30 jiffies. +[ 0.102084] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 +[ 0.105514] NR_IRQS: 20736, nr_irqs: 488, preallocated irqs: 16 +[ 0.105776] Console: colour dummy device 80x25 +[ 0.105780] printk: console [tty0] enabled +[ 0.105797] ACPI: Core revision 20200528 +[ 0.105953] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns +[ 0.105967] APIC: Switch to symmetric I/O mode setup +[ 0.105969] DMAR: Host address width 36 +[ 0.105970] DMAR: DRHD base: 0x000000fed90000 flags: 0x0 +[ 0.105975] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a +[ 0.105976] DMAR: DRHD base: 0x000000fed91000 flags: 0x1 +[ 0.105979] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a +[ 0.105979] DMAR: RMRR base: 0x000000da2ba000 end: 0x000000da2d0fff +[ 0.105981] DMAR: RMRR base: 0x000000db800000 end: 0x000000df9fffff +[ 0.105983] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 +[ 0.105983] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 +[ 0.105984] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. +[ 0.106395] DMAR-IR: Enabled IRQ remapping in x2apic mode +[ 0.106396] x2apic enabled +[ 0.106403] Switched APIC routing to cluster x2apic. +[ 0.106850] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.122635] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2564baca675, max_idle_ns: 440795329072 ns +[ 0.122639] Calibrating delay loop (skipped), value calculated using timer frequency.. 5190.52 BogoMIPS (lpj=8647240) +[ 0.122642] pid_max: default: 32768 minimum: 301 +[ 0.128651] LSM: Security Framework initializing +[ 0.128657] Yama: becoming mindful. +[ 0.128696] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes, linear) +[ 0.128720] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes, linear) +[ 0.129469] mce: CPU0: Thermal monitoring enabled (TM1) +[ 0.129480] process: using mwait in idle threads +[ 0.129482] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 +[ 0.129483] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 +[ 0.129486] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.129488] Spectre V2 : Mitigation: Full generic retpoline +[ 0.129489] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.129489] Spectre V2 : Enabling Restricted Speculation for firmware calls +[ 0.129491] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.129491] Spectre V2 : User space: Mitigation: STIBP via seccomp and prctl +[ 0.129493] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp +[ 0.129496] SRBDS: Vulnerable: No microcode +[ 0.129497] MDS: Mitigation: Clear CPU buffers +[ 0.129713] Freeing SMP alternatives memory: 32K +[ 0.131560] smpboot: CPU0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz (family: 0x6, model: 0x3a, stepping: 0x9) +[ 0.131675] Performance Events: PEBS fmt1+, IvyBridge events, 16-deep LBR, full-width counters, Intel PMU driver. +[ 0.131682] ... version: 3 +[ 0.131682] ... bit width: 48 +[ 0.131683] ... generic registers: 4 +[ 0.131683] ... value mask: 0000ffffffffffff +[ 0.131684] ... max period: 00007fffffffffff +[ 0.131684] ... fixed-purpose events: 3 +[ 0.131685] ... event mask: 000000070000000f +[ 0.131727] rcu: Hierarchical SRCU implementation. +[ 0.132580] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter. +[ 0.132636] smp: Bringing up secondary CPUs ... +[ 0.132636] x86: Booting SMP configuration: +[ 0.132636] .... node #0, CPUs: #1 +[ 0.132748] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. +[ 0.132822] #2 #3 +[ 0.138404] smp: Brought up 1 node, 4 CPUs +[ 0.138404] smpboot: Max logical packages: 2 +[ 0.138404] smpboot: Total of 4 processors activated (20761.10 BogoMIPS) +[ 0.139729] devtmpfs: initialized +[ 0.139729] x86/mm: Memory block size: 128MB +[ 0.140581] PM: Registering ACPI NVS region [mem 0xdae9f000-0xdaf9efff] (1048576 bytes) +[ 0.140581] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns +[ 0.140581] futex hash table entries: 2048 (order: 5, 131072 bytes, linear) +[ 0.140581] pinctrl core: initialized pinctrl subsystem +[ 0.140581] PM: RTC time: 14:55:39, date: 2020-09-30 +[ 0.140581] thermal_sys: Registered thermal governor 'fair_share' +[ 0.140581] thermal_sys: Registered thermal governor 'bang_bang' +[ 0.140581] thermal_sys: Registered thermal governor 'step_wise' +[ 0.140581] thermal_sys: Registered thermal governor 'user_space' +[ 0.140581] thermal_sys: Registered thermal governor 'power_allocator' +[ 0.140581] NET: Registered protocol family 16 +[ 0.140581] DMA: preallocated 2048 KiB GFP_KERNEL pool for atomic allocations +[ 0.140581] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations +[ 0.140581] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations +[ 0.140581] audit: initializing netlink subsys (disabled) +[ 0.140581] audit: type=2000 audit(1601477739.033:1): state=initialized audit_enabled=0 res=1 +[ 0.140581] cpuidle: using governor ladder +[ 0.140581] cpuidle: using governor menu +[ 0.140581] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it +[ 0.140581] ACPI: bus type PCI registered +[ 0.140581] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 +[ 0.140581] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) +[ 0.140581] PCI: not using MMCONFIG +[ 0.140581] PCI: Using configuration type 1 for base access +[ 0.140581] core: PMU erratum BJ122, BV98, HSD29 worked around, HT is on +[ 0.142898] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' +[ 0.143934] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.143934] ACPI: Added _OSI(Module Device) +[ 0.143934] ACPI: Added _OSI(Processor Device) +[ 0.143934] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.143934] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.143934] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.143934] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.143934] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.160850] ACPI: 6 ACPI AML tables successfully acquired and loaded +[ 0.161606] ACPI: EC: EC started +[ 0.161606] ACPI: EC: interrupt blocked +[ 0.162552] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62 +[ 0.162553] ACPI: EC: Boot ECDT EC used to handle transactions +[ 0.162869] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored +[ 0.167432] ACPI: Dynamic OEM Table Load: +[ 0.167440] ACPI: SSDT 0xFFFFA3690B880000 000A01 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) +[ 0.168544] ACPI: Dynamic OEM Table Load: +[ 0.168549] ACPI: SSDT 0xFFFFA3690BA2CC00 000303 (v01 PmRef ApIst 00003000 INTL 20061109) +[ 0.169420] ACPI: Dynamic OEM Table Load: +[ 0.169425] ACPI: SSDT 0xFFFFA3690BA17800 000119 (v01 PmRef ApCst 00003000 INTL 20061109) +[ 0.171021] ACPI: Interpreter enabled +[ 0.171043] ACPI: (supports S0 S3 S4 S5) +[ 0.171044] ACPI: Using IOAPIC for interrupt routing +[ 0.171070] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) +[ 0.171729] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in ACPI motherboard resources +[ 0.171738] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.172087] ACPI: Enabled 6 GPEs in block 00 to 3F +[ 0.175796] ACPI: Power Resource [PUBS] (on) +[ 0.175953] acpi PNP0C0A:01: ACPI dock station (docks/bays count: 1) +[ 0.177107] acpi LNXIOBAY:00: ACPI dock station (docks/bays count: 2) +[ 0.179763] acpi IBM0079:00: ACPI dock station (docks/bays count: 3) +[ 0.180348] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11) +[ 0.180449] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180547] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180645] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180742] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180839] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.180936] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.181034] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. +[ 0.181137] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f]) +[ 0.181142] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3] +[ 0.181329] acpi PNP0A08:00: _OSC: platform does not support [SHPCHotplug PCIeCapability LTR DPC] +[ 0.181414] acpi PNP0A08:00: _OSC: not requesting control; platform does not support [PCIeCapability] +[ 0.181416] acpi PNP0A08:00: _OSC: OS requested [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR DPC] +[ 0.181417] acpi PNP0A08:00: _OSC: platform willing to grant [PCIeHotplug PME AER] +[ 0.181418] acpi PNP0A08:00: _OSC failed (AE_SUPPORT); disabling ASPM +[ 0.181622] PCI host bridge to bus 0000:00 +[ 0.181624] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.181626] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.181627] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.181628] pci_bus 0000:00: root bus resource [mem 0xdfa00000-0xfebfffff window] +[ 0.181629] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed4bfff window] +[ 0.181630] pci_bus 0000:00: root bus resource [bus 00-3f] +[ 0.181640] pci 0000:00:00.0: [8086:0154] type 00 class 0x060000 +[ 0.181733] pci 0000:00:02.0: [8086:0166] type 00 class 0x030000 +[ 0.181745] pci 0000:00:02.0: reg 0x10: [mem 0xf0000000-0xf03fffff 64bit] +[ 0.181750] pci 0000:00:02.0: reg 0x18: [mem 0xe0000000-0xefffffff 64bit pref] +[ 0.181755] pci 0000:00:02.0: reg 0x20: [io 0x7000-0x703f] +[ 0.181768] pci 0000:00:02.0: BAR 2: assigned to efifb +[ 0.181871] pci 0000:00:14.0: [8086:1e31] type 00 class 0x0c0330 +[ 0.181895] pci 0000:00:14.0: reg 0x10: [mem 0xf2520000-0xf252ffff 64bit] +[ 0.181966] pci 0000:00:14.0: PME# supported from D3hot D3cold +[ 0.182056] pci 0000:00:16.0: [8086:1e3a] type 00 class 0x078000 +[ 0.182078] pci 0000:00:16.0: reg 0x10: [mem 0xf2535000-0xf253500f 64bit] +[ 0.182143] pci 0000:00:16.0: PME# supported from D0 D3hot D3cold +[ 0.182213] pci 0000:00:16.3: [8086:1e3d] type 00 class 0x070002 +[ 0.182231] pci 0000:00:16.3: reg 0x10: [io 0x70b0-0x70b7] +[ 0.182240] pci 0000:00:16.3: reg 0x14: [mem 0xf253c000-0xf253cfff] +[ 0.182374] pci 0000:00:19.0: [8086:1502] type 00 class 0x020000 +[ 0.182394] pci 0000:00:19.0: reg 0x10: [mem 0xf2500000-0xf251ffff] +[ 0.182402] pci 0000:00:19.0: reg 0x14: [mem 0xf253b000-0xf253bfff] +[ 0.182410] pci 0000:00:19.0: reg 0x18: [io 0x7080-0x709f] +[ 0.182472] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold +[ 0.182560] pci 0000:00:1a.0: [8086:1e2d] type 00 class 0x0c0320 +[ 0.182583] pci 0000:00:1a.0: reg 0x10: [mem 0xf253a000-0xf253a3ff] +[ 0.182670] pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold +[ 0.182762] pci 0000:00:1b.0: [8086:1e20] type 00 class 0x040300 +[ 0.182784] pci 0000:00:1b.0: reg 0x10: [mem 0xf2530000-0xf2533fff 64bit] +[ 0.182865] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold +[ 0.182961] pci 0000:00:1c.0: [8086:1e10] type 01 class 0x060400 +[ 0.183061] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold +[ 0.183084] pci 0000:00:1c.0: Enabling MPC IRBNCE +[ 0.183087] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled +[ 0.183175] pci 0000:00:1c.1: [8086:1e12] type 01 class 0x060400 +[ 0.183273] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold +[ 0.183295] pci 0000:00:1c.1: Enabling MPC IRBNCE +[ 0.183297] pci 0000:00:1c.1: Intel PCH root port ACS workaround enabled +[ 0.183384] pci 0000:00:1c.2: [8086:1e14] type 01 class 0x060400 +[ 0.183483] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold +[ 0.183503] pci 0000:00:1c.2: Enabling MPC IRBNCE +[ 0.183506] pci 0000:00:1c.2: Intel PCH root port ACS workaround enabled +[ 0.183596] pci 0000:00:1d.0: [8086:1e26] type 00 class 0x0c0320 +[ 0.183619] pci 0000:00:1d.0: reg 0x10: [mem 0xf2539000-0xf25393ff] +[ 0.183704] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold +[ 0.183793] pci 0000:00:1f.0: [8086:1e55] type 00 class 0x060100 +[ 0.183982] pci 0000:00:1f.2: [8086:1e03] type 00 class 0x010601 +[ 0.184000] pci 0000:00:1f.2: reg 0x10: [io 0x70a8-0x70af] +[ 0.184008] pci 0000:00:1f.2: reg 0x14: [io 0x70bc-0x70bf] +[ 0.184015] pci 0000:00:1f.2: reg 0x18: [io 0x70a0-0x70a7] +[ 0.184023] pci 0000:00:1f.2: reg 0x1c: [io 0x70b8-0x70bb] +[ 0.184031] pci 0000:00:1f.2: reg 0x20: [io 0x7060-0x707f] +[ 0.184038] pci 0000:00:1f.2: reg 0x24: [mem 0xf2538000-0xf25387ff] +[ 0.184081] pci 0000:00:1f.2: PME# supported from D3hot +[ 0.184164] pci 0000:00:1f.3: [8086:1e22] type 00 class 0x0c0500 +[ 0.184182] pci 0000:00:1f.3: reg 0x10: [mem 0xf2534000-0xf25340ff 64bit] +[ 0.184203] pci 0000:00:1f.3: reg 0x20: [io 0xefa0-0xefbf] +[ 0.184567] pci 0000:02:00.0: [1180:e823] type 00 class 0x088001 +[ 0.184595] pci 0000:02:00.0: MMC controller base frequency changed to 50Mhz. +[ 0.184633] pci 0000:02:00.0: reg 0x10: [mem 0xf1d00000-0xf1d000ff] +[ 0.184864] pci 0000:02:00.0: supports D1 D2 +[ 0.184865] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold +[ 0.185275] pci 0000:00:1c.0: PCI bridge to [bus 02] +[ 0.185279] pci 0000:00:1c.0: bridge window [io 0x6000-0x6fff] +[ 0.185283] pci 0000:00:1c.0: bridge window [mem 0xf1d00000-0xf24fffff] +[ 0.185289] pci 0000:00:1c.0: bridge window [mem 0xf0400000-0xf0bfffff 64bit pref] +[ 0.185355] pci 0000:03:00.0: [10ec:8176] type 00 class 0x028000 +[ 0.185404] pci 0000:03:00.0: reg 0x10: [io 0x5000-0x50ff] +[ 0.185452] pci 0000:03:00.0: reg 0x18: [mem 0xf1c00000-0xf1c03fff 64bit] +[ 0.185646] pci 0000:03:00.0: supports D1 D2 +[ 0.185647] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold +[ 0.185820] pci 0000:00:1c.1: PCI bridge to [bus 03] +[ 0.185824] pci 0000:00:1c.1: bridge window [io 0x5000-0x5fff] +[ 0.185828] pci 0000:00:1c.1: bridge window [mem 0xf1c00000-0xf1cfffff] +[ 0.185904] acpiphp: Slot [1] registered +[ 0.185910] pci 0000:00:1c.2: PCI bridge to [bus 04-0b] +[ 0.185914] pci 0000:00:1c.2: bridge window [io 0x4000-0x4fff] +[ 0.185918] pci 0000:00:1c.2: bridge window [mem 0xf1400000-0xf1bfffff] +[ 0.185924] pci 0000:00:1c.2: bridge window [mem 0xf0c00000-0xf13fffff 64bit pref] +[ 0.187251] ACPI: EC: interrupt unblocked +[ 0.187251] ACPI: EC: event unblocked +[ 0.187257] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62 +[ 0.187258] ACPI: EC: GPE=0x11 +[ 0.187260] ACPI: \_SB_.PCI0.LPC_.EC__: Boot ECDT EC initialization complete +[ 0.187261] ACPI: \_SB_.PCI0.LPC_.EC__: EC: Used to handle transactions and events +[ 0.187337] iommu: Default domain type: Translated +[ 0.187350] pci 0000:00:02.0: vgaarb: setting as boot VGA device +[ 0.187350] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none +[ 0.187350] pci 0000:00:02.0: vgaarb: bridge control possible +[ 0.187350] vgaarb: loaded +[ 0.187350] SCSI subsystem initialized +[ 0.187350] libata version 3.00 loaded. +[ 0.187350] ACPI: bus type USB registered +[ 0.187350] usbcore: registered new interface driver usbfs +[ 0.187350] usbcore: registered new interface driver hub +[ 0.187350] usbcore: registered new device driver usb +[ 0.187350] pps_core: LinuxPPS API ver. 1 registered +[ 0.187350] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <email address hidden> +[ 0.187350] PTP clock support registered +[ 0.187350] EDAC MC: Ver: 3.0.0 +[ 0.187350] Registered efivars operations +[ 0.187350] NetLabel: Initializing +[ 0.187350] NetLabel: domain hash size = 128 +[ 0.187350] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 0.187350] NetLabel: unlabeled traffic allowed by default +[ 0.187350] PCI: Using ACPI for IRQ routing +[ 0.187350] PCI: pci_cache_line_size set to 64 bytes +[ 0.187350] e820: reserve RAM buffer [mem 0x40004000-0x43ffffff] +[ 0.187350] e820: reserve RAM buffer [mem 0xcfef7000-0xcfffffff] +[ 0.187350] e820: reserve RAM buffer [mem 0xd684f000-0xd7ffffff] +[ 0.187350] e820: reserve RAM buffer [mem 0xdb000000-0xdbffffff] +[ 0.187350] e820: reserve RAM buffer [mem 0x41e600000-0x41fffffff] +[ 0.189970] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0 +[ 0.189975] hpet0: 8 comparators, 64-bit 14.318180 MHz counter +[ 0.192689] clocksource: Switched to clocksource tsc-early +[ 0.205145] VFS: Disk quotas dquot_6.6.0 +[ 0.205164] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) +[ 0.205242] pnp: PnP ACPI init +[ 0.205897] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved +[ 0.205899] system 00:00: [mem 0x000c0000-0x000c3fff] could not be reserved +[ 0.205900] system 00:00: [mem 0x000c4000-0x000c7fff] could not be reserved +[ 0.205902] system 00:00: [mem 0x000c8000-0x000cbfff] has been reserved +[ 0.205904] system 00:00: [mem 0x000cc000-0x000cffff] has been reserved +[ 0.205905] system 00:00: [mem 0x000d0000-0x000d3fff] has been reserved +[ 0.205906] system 00:00: [mem 0x000d4000-0x000d7fff] has been reserved +[ 0.205908] system 00:00: [mem 0x000d8000-0x000dbfff] has been reserved +[ 0.205909] system 00:00: [mem 0x000dc000-0x000dffff] has been reserved +[ 0.205910] system 00:00: [mem 0x000e0000-0x000e3fff] has been reserved +[ 0.205911] system 00:00: [mem 0x000e4000-0x000e7fff] has been reserved +[ 0.205913] system 00:00: [mem 0x000e8000-0x000ebfff] has been reserved +[ 0.205914] system 00:00: [mem 0x000ec000-0x000effff] has been reserved +[ 0.205915] system 00:00: [mem 0x000f0000-0x000fffff] could not be reserved +[ 0.205916] system 00:00: [mem 0x00100000-0xdf9fffff] could not be reserved +[ 0.205918] system 00:00: [mem 0xfec00000-0xfed3ffff] could not be reserved +[ 0.205919] system 00:00: [mem 0xfed4c000-0xffffffff] could not be reserved +[ 0.205926] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active) +[ 0.206051] pnp 00:01: [Firmware Bug]: PNP resource [mem 0xfed10000-0xfed13fff] covers only part of 0000:00:00.0 Intel MCH; extending to [mem 0xfed10000-0xfed17fff] +[ 0.206071] system 00:01: [io 0x0400-0x047f] has been reserved +[ 0.206072] system 00:01: [io 0x0500-0x057f] has been reserved +[ 0.206073] system 00:01: [io 0x0800-0x080f] has been reserved +[ 0.206075] system 00:01: [io 0x15e0-0x15ef] has been reserved +[ 0.206076] system 00:01: [io 0x1600-0x167f] has been reserved +[ 0.206079] system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved +[ 0.206080] system 00:01: [mem 0xfffff000-0xffffffff] has been reserved +[ 0.206082] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved +[ 0.206083] system 00:01: [mem 0xfed10000-0xfed17fff] has been reserved +[ 0.206084] system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved +[ 0.206086] system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved +[ 0.206087] system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved +[ 0.206091] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) +[ 0.206154] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active) +[ 0.206177] pnp 00:03: Plug and Play ACPI device, IDs LEN0071 PNP0303 (active) +[ 0.206197] pnp 00:04: Plug and Play ACPI device, IDs LEN0020 PNP0f13 (active) +[ 0.206250] pnp 00:05: Plug and Play ACPI device, IDs SMO1200 PNP0c31 (active) +[ 0.206871] pnp: PnP ACPI: found 6 devices +[ 0.212684] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.212744] NET: Registered protocol family 2 +[ 0.212898] tcp_listen_portaddr_hash hash table entries: 8192 (order: 5, 131072 bytes, linear) +[ 0.212978] TCP established hash table entries: 131072 (order: 8, 1048576 bytes, linear) +[ 0.213207] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes, linear) +[ 0.213287] TCP: Hash tables configured (established 131072 bind 65536) +[ 0.213405] UDP hash table entries: 8192 (order: 6, 262144 bytes, linear) +[ 0.213449] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes, linear) +[ 0.213550] NET: Registered protocol family 1 +[ 0.213555] NET: Registered protocol family 44 +[ 0.213567] pci 0000:00:1c.0: PCI bridge to [bus 02] +[ 0.213571] pci 0000:00:1c.0: bridge window [io 0x6000-0x6fff] +[ 0.213577] pci 0000:00:1c.0: bridge window [mem 0xf1d00000-0xf24fffff] +[ 0.213581] pci 0000:00:1c.0: bridge window [mem 0xf0400000-0xf0bfffff 64bit pref] +[ 0.213587] pci 0000:00:1c.1: PCI bridge to [bus 03] +[ 0.213590] pci 0000:00:1c.1: bridge window [io 0x5000-0x5fff] +[ 0.213595] pci 0000:00:1c.1: bridge window [mem 0xf1c00000-0xf1cfffff] +[ 0.213603] pci 0000:00:1c.2: PCI bridge to [bus 04-0b] +[ 0.213606] pci 0000:00:1c.2: bridge window [io 0x4000-0x4fff] +[ 0.213611] pci 0000:00:1c.2: bridge window [mem 0xf1400000-0xf1bfffff] +[ 0.213615] pci 0000:00:1c.2: bridge window [mem 0xf0c00000-0xf13fffff 64bit pref] +[ 0.213621] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.213623] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.213624] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.213625] pci_bus 0000:00: resource 7 [mem 0xdfa00000-0xfebfffff window] +[ 0.213626] pci_bus 0000:00: resource 8 [mem 0xfed40000-0xfed4bfff window] +[ 0.213628] pci_bus 0000:02: resource 0 [io 0x6000-0x6fff] +[ 0.213629] pci_bus 0000:02: resource 1 [mem 0xf1d00000-0xf24fffff] +[ 0.213630] pci_bus 0000:02: resource 2 [mem 0xf0400000-0xf0bfffff 64bit pref] +[ 0.213631] pci_bus 0000:03: resource 0 [io 0x5000-0x5fff] +[ 0.213632] pci_bus 0000:03: resource 1 [mem 0xf1c00000-0xf1cfffff] +[ 0.213633] pci_bus 0000:04: resource 0 [io 0x4000-0x4fff] +[ 0.213634] pci_bus 0000:04: resource 1 [mem 0xf1400000-0xf1bfffff] +[ 0.213635] pci_bus 0000:04: resource 2 [mem 0xf0c00000-0xf13fffff 64bit pref] +[ 0.213740] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] +[ 0.214328] PCI: CLS 64 bytes, default 64 +[ 0.214377] Trying to unpack rootfs image as initramfs... +[ 0.352872] Freeing initrd memory: 12552K +[ 0.352906] DMAR: No ATSR found +[ 0.352951] DMAR: dmar0: Using Queued invalidation +[ 0.352956] DMAR: dmar1: Using Queued invalidation +[ 0.428205] pci 0000:00:00.0: Adding to iommu group 0 +[ 0.428215] pci 0000:00:02.0: Adding to iommu group 1 +[ 0.428223] pci 0000:00:14.0: Adding to iommu group 2 +[ 0.428238] pci 0000:00:16.0: Adding to iommu group 3 +[ 0.428246] pci 0000:00:16.3: Adding to iommu group 3 +[ 0.428256] pci 0000:00:19.0: Adding to iommu group 4 +[ 0.428265] pci 0000:00:1a.0: Adding to iommu group 5 +[ 0.428273] pci 0000:00:1b.0: Adding to iommu group 6 +[ 0.428283] pci 0000:00:1c.0: Adding to iommu group 7 +[ 0.428291] pci 0000:00:1c.1: Adding to iommu group 8 +[ 0.428300] pci 0000:00:1c.2: Adding to iommu group 9 +[ 0.428308] pci 0000:00:1d.0: Adding to iommu group 10 +[ 0.428327] pci 0000:00:1f.0: Adding to iommu group 11 +[ 0.428336] pci 0000:00:1f.2: Adding to iommu group 11 +[ 0.428345] pci 0000:00:1f.3: Adding to iommu group 11 +[ 0.428520] pci 0000:02:00.0: Adding to iommu group 12 +[ 0.428529] pci 0000:03:00.0: Adding to iommu group 13 +[ 0.436768] DMAR: Intel(R) Virtualization Technology for Directed I/O +[ 0.436770] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) +[ 0.436772] software IO TLB: mapped [mem 0xc9b58000-0xcdb58000] (64MB) +[ 0.436923] check: Scanning for low memory corruption every 60 seconds +[ 0.437269] Initialise system trusted keyrings +[ 0.437278] Key type blacklist registered +[ 0.437328] workingset: timestamp_bits=41 max_order=22 bucket_order=0 +[ 0.438473] zbud: loaded +[ 0.449701] Key type asymmetric registered +[ 0.449702] Asymmetric key parser 'x509' registered +[ 0.449710] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245) +[ 0.449758] io scheduler mq-deadline registered +[ 0.449759] io scheduler kyber registered +[ 0.449784] io scheduler bfq registered +[ 0.450464] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 +[ 0.450538] efifb: probing for efifb +[ 0.450554] efifb: No BGRT, not showing boot graphics +[ 0.450555] efifb: framebuffer at 0xe0000000, using 1216k, total 1216k +[ 0.450556] efifb: mode is 640x480x32, linelength=2560, pages=1 +[ 0.450557] efifb: scrolling: redraw +[ 0.450558] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 +[ 0.450597] fbcon: Deferring console take-over +[ 0.450598] fb0: EFI VGA frame buffer device +[ 0.450605] intel_idle: MWAIT substates: 0x21120 +[ 0.450606] intel_idle: v0.5.1 model 0x3A +[ 0.450787] intel_idle: Local APIC timer is reliable in all C-states +[ 0.450840] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0 +[ 0.452673] ACPI: Lid Switch [LID] +[ 0.452708] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 +[ 0.452803] ACPI: Sleep Button [SLPB] +[ 0.452856] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 +[ 0.459347] ACPI: Power Button [PWRF] +[ 0.461649] thermal LNXTHERM:00: registered as thermal_zone0 +[ 0.461650] ACPI: Thermal Zone [THM0] (69 C) +[ 0.461851] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled +[ 0.462453] 0000:00:16.3: ttyS0 at I/O 0x70b0 (irq = 19, base_baud = 115200) is a 16550A +[ 0.462614] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel <email address hidden> +[ 0.462615] AMD-Vi: AMD IOMMUv2 functionality not available on this system +[ 0.463199] ahci 0000:00:1f.2: version 3.0 +[ 0.463335] ahci 0000:00:1f.2: SSS flag set, parallel bus scan disabled +[ 0.476048] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x13 impl SATA mode +[ 0.476050] ahci 0000:00:1f.2: flags: 64bit ncq stag pm led clo pio slum part ems sxs apst +[ 0.496625] scsi host0: ahci +[ 0.496888] scsi host1: ahci +[ 0.497098] scsi host2: ahci +[ 0.497198] scsi host3: ahci +[ 0.497278] scsi host4: ahci +[ 0.497360] scsi host5: ahci +[ 0.497398] ata1: SATA max UDMA/133 abar m2048@0xf2538000 port 0xf2538100 irq 29 +[ 0.497400] ata2: SATA max UDMA/133 abar m2048@0xf2538000 port 0xf2538180 irq 29 +[ 0.497401] ata3: DUMMY +[ 0.497402] ata4: DUMMY +[ 0.497404] ata5: SATA max UDMA/133 abar m2048@0xf2538000 port 0xf2538300 irq 29 +[ 0.497405] ata6: DUMMY +[ 0.497458] usbcore: registered new interface driver usbserial_generic +[ 0.497462] usbserial: USB Serial support registered for generic +[ 0.497483] rtc_cmos 00:02: RTC can wake from S4 +[ 0.497692] rtc_cmos 00:02: registered as rtc0 +[ 0.497722] rtc_cmos 00:02: setting system clock to 2020-09-30T14:55:40 UTC (1601477740) +[ 0.497738] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs +[ 0.497800] intel_pstate: Intel P-state driver initializing +[ 0.498090] ledtrig-cpu: registered to indicate activity on CPUs +[ 0.498292] drop_monitor: Initializing network drop monitor service +[ 0.498617] NET: Registered protocol family 10 +[ 0.503608] Segment Routing with IPv6 +[ 0.503610] RPL Segment Routing with IPv6 +[ 0.503645] NET: Registered protocol family 17 +[ 0.503977] microcode: sig=0x306a9, pf=0x10, revision=0x21 +[ 0.504057] microcode: Microcode Update Driver: v2.2. +[ 0.504061] IPI shorthand broadcast: enabled +[ 0.504067] sched_clock: Marking stable (503804188, 248333)->(526000639, -21948118) +[ 0.504159] registered taskstats version 1 +[ 0.504166] Loading compiled-in X.509 certificates +[ 0.506862] Loaded X.509 cert 'Build time autogenerated kernel key: 5996b3c054c5a5d45f30f3a31bd2b8088edb6449' +[ 0.507441] zswap: loaded using pool zstd/z3fold +[ 0.507638] Key type ._fscrypt registered +[ 0.507639] Key type .fscrypt registered +[ 0.507639] Key type fscrypt-provisioning registered +[ 0.507942] PM: Magic number: 4:649:941 +[ 0.508087] RAS: Correctable Errors collector initialized. +[ 0.812686] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) +[ 0.813178] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded +[ 0.813180] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out +[ 0.813182] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out +[ 0.813570] ata1.00: supports DRM functions and may not be fully accessible +[ 0.814813] ata1.00: ATA-11: Samsung SSD 860 EVO 1TB, RVT02B6Q, max UDMA/133 +[ 0.814817] ata1.00: 1953525168 sectors, multi 1: LBA48 NCQ (depth 32), AA +[ 0.817782] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded +[ 0.817788] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out +[ 0.817791] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out +[ 0.818135] ata1.00: supports DRM functions and may not be fully accessible +[ 0.821054] ata1.00: configured for UDMA/133 +[ 0.832922] scsi 0:0:0:0: Direct-Access ATA Samsung SSD 860 2B6Q PQ: 0 ANSI: 5 +[ 0.833090] ata1.00: Enabling discard_zeroes_data +[ 0.833177] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) +[ 0.833186] sd 0:0:0:0: [sda] Write Protect is off +[ 0.833188] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 +[ 0.833200] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +[ 0.833383] ata1.00: Enabling discard_zeroes_data +[ 0.835027] sda: sda1 sda2 sda3 sda4 sda5 sda6 +[ 0.835615] ata1.00: Enabling discard_zeroes_data +[ 0.836706] sd 0:0:0:0: [sda] supports TCG Opal +[ 0.836708] sd 0:0:0:0: [sda] Attached SCSI disk +[ 1.149363] ata2: SATA link down (SStatus 0 SControl 300) +[ 1.439347] tsc: Refined TSC clocksource calibration: 2594.106 MHz +[ 1.439360] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x25647bfab01, max_idle_ns: 440795211785 ns +[ 1.439409] clocksource: Switched to clocksource tsc +[ 1.462669] ata5: SATA link down (SStatus 0 SControl 300) +[ 1.465182] Freeing unused decrypted memory: 2040K +[ 1.465785] Freeing unused kernel image (initmem) memory: 1648K +[ 1.465870] Write protecting the kernel read-only data: 22528k +[ 1.467009] Freeing unused kernel image (text/rodata gap) memory: 2044K +[ 1.467616] Freeing unused kernel image (rodata/data gap) memory: 1488K +[ 1.559627] x86/mm: Checked W+X mappings: passed, no W+X pages found. +[ 1.559629] x86/mm: Checking user space page tables +[ 1.606251] x86/mm: Checked W+X mappings: passed, no W+X pages found. +[ 1.606257] Run /init as init process +[ 1.606258] with arguments: +[ 1.606259] /init +[ 1.606260] with environment: +[ 1.606260] HOME=/ +[ 1.606260] TERM=linux +[ 1.606261] BOOT_IMAGE=/boot/vmlinuz-5.8-x86_64 +[ 1.606261] intel_iommu=on +[ 1.694613] VFIO - User Level meta-driver version: 0.3 +[ 1.700271] vfio_pci: add [10de:1c03[ffffffff:ffffffff]] class 0x000000/00000000 +[ 1.700275] vfio_pci: add [10de:10f1[ffffffff:ffffffff]] class 0x000000/00000000 +[ 1.764714] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 +[ 1.766602] serio: i8042 KBD port at 0x60,0x64 irq 1 +[ 1.766655] serio: i8042 AUX port at 0x60,0x64 irq 12 +[ 1.776170] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 1.789364] ehci-pci: EHCI PCI platform driver +[ 1.789543] ehci-pci 0000:00:1a.0: EHCI Host Controller +[ 1.790301] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1 +[ 1.790317] ehci-pci 0000:00:1a.0: debug port 2 +[ 1.795166] ehci-pci 0000:00:1a.0: cache line size of 64 is not supported +[ 1.795190] ehci-pci 0000:00:1a.0: irq 16, io mem 0xf253a000 +[ 1.798914] sdhci: Secure Digital Host Controller Interface driver +[ 1.798916] sdhci: Copyright(c) Pierre Ossman +[ 1.801256] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 +[ 1.804905] sdhci-pci 0000:02:00.0: SDHCI controller found [1180:e823] (rev 4) +[ 1.805339] mmc0 bounce up to 128 segments into one, max segment size 65536 bytes +[ 1.805692] mmc0: SDHCI controller on PCI [0000:02:00.0] using DMA +[ 1.806182] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00 +[ 1.806293] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 +[ 1.806295] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 1.806297] usb usb1: Product: EHCI Host Controller +[ 1.806298] usb usb1: Manufacturer: Linux 5.8.6-1-MANJARO ehci_hcd +[ 1.806300] usb usb1: SerialNumber: 0000:00:1a.0 +[ 1.806450] hub 1-0:1.0: USB hub found +[ 1.806461] hub 1-0:1.0: 3 ports detected +[ 1.806654] xhci_hcd 0000:00:14.0: xHCI Host Controller +[ 1.806661] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2 +[ 1.807744] xhci_hcd 0000:00:14.0: hcc params 0x20007181 hci version 0x100 quirks 0x000000000000b930 +[ 1.807750] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported +[ 1.807908] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 +[ 1.807910] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 1.807911] usb usb2: Product: xHCI Host Controller +[ 1.807912] usb usb2: Manufacturer: Linux 5.8.6-1-MANJARO xhci-hcd +[ 1.807913] usb usb2: SerialNumber: 0000:00:14.0 +[ 1.808031] hub 2-0:1.0: USB hub found +[ 1.808041] hub 2-0:1.0: 4 ports detected +[ 1.808472] ehci-pci 0000:00:1d.0: EHCI Host Controller +[ 1.808478] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 3 +[ 1.808494] ehci-pci 0000:00:1d.0: debug port 2 +[ 1.808509] xhci_hcd 0000:00:14.0: xHCI Host Controller +[ 1.808512] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4 +[ 1.808515] xhci_hcd 0000:00:14.0: Host supports USB 3.0 SuperSpeed +[ 1.808574] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.08 +[ 1.808575] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 1.808577] usb usb4: Product: xHCI Host Controller +[ 1.808578] usb usb4: Manufacturer: Linux 5.8.6-1-MANJARO xhci-hcd +[ 1.808579] usb usb4: SerialNumber: 0000:00:14.0 +[ 1.808685] hub 4-0:1.0: USB hub found +[ 1.808697] hub 4-0:1.0: 4 ports detected +[ 1.812429] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported +[ 1.812446] ehci-pci 0000:00:1d.0: irq 23, io mem 0xf2539000 +[ 1.822660] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 +[ 1.822720] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08 +[ 1.822722] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 1.822723] usb usb3: Product: EHCI Host Controller +[ 1.822724] usb usb3: Manufacturer: Linux 5.8.6-1-MANJARO ehci_hcd +[ 1.822725] usb usb3: SerialNumber: 0000:00:1d.0 +[ 1.823025] hub 3-0:1.0: USB hub found +[ 1.823033] hub 3-0:1.0: 3 ports detected +[ 1.847655] PM: Image not found (code -22) +[ 1.850473] random: fast init done +[ 1.885663] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) +[ 1.991139] systemd[1]: RTC configured in localtime, applying delta of 180 minutes to system time. +[ 2.013666] systemd[1]: systemd 246.4-1-manjaro running in system mode. (+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid) +[ 2.029440] systemd[1]: Detected architecture x86-64. +[ 2.044045] systemd[1]: Set hostname to <thinkpad>. +[ 2.135993] usb 1-1: new high-speed USB device number 2 using ehci-pci +[ 2.152659] usb 3-1: new high-speed USB device number 2 using ehci-pci +[ 2.216664] systemd[1]: Queued start job for default target Graphical Interface. +[ 2.217451] systemd[1]: Created slice Virtual Machine and Container Slice. +[ 2.217964] systemd[1]: Created slice system-getty.slice. +[ 2.218211] systemd[1]: Created slice system-modprobe.slice. +[ 2.218516] systemd[1]: Created slice system-systemd\x2dfsck.slice. +[ 2.218748] systemd[1]: Created slice User and Session Slice. +[ 2.218806] systemd[1]: Started Dispatch Password Requests to Console Directory Watch. +[ 2.218849] systemd[1]: Started Forward Password Requests to Wall Directory Watch. +[ 2.219000] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. +[ 2.219029] systemd[1]: Reached target Local Encrypted Volumes. +[ 2.219040] systemd[1]: Reached target Login Prompts. +[ 2.219064] systemd[1]: Reached target Remote File Systems. +[ 2.219074] systemd[1]: Reached target Slices. +[ 2.219143] systemd[1]: Listening on Device-mapper event daemon FIFOs. +[ 2.219409] systemd[1]: Listening on LVM2 metadata daemon socket. +[ 2.219477] systemd[1]: Listening on LVM2 poll daemon socket. +[ 2.220755] systemd[1]: Listening on Process Core Dump Socket. +[ 2.220880] systemd[1]: Listening on Journal Audit Socket. +[ 2.220959] systemd[1]: Listening on Journal Socket (/dev/log). +[ 2.221047] systemd[1]: Listening on Journal Socket. +[ 2.221142] systemd[1]: Listening on udev Control Socket. +[ 2.221207] systemd[1]: Listening on udev Kernel Socket. +[ 2.222093] systemd[1]: Mounting Huge Pages File System... +[ 2.223184] systemd[1]: Mounting POSIX Message Queue File System... +[ 2.224506] systemd[1]: Mounting Kernel Debug File System... +[ 2.225932] systemd[1]: Mounting Kernel Trace File System... +[ 2.227458] systemd[1]: Starting Create list of static device nodes for the current kernel... +[ 2.228877] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling... +[ 2.229812] systemd[1]: Starting Load Kernel Module drm... +[ 2.231475] systemd[1]: Starting Set Up Additional Binary Formats... +[ 2.231570] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. +[ 2.233649] systemd[1]: Starting Journal Service... +[ 2.237952] systemd[1]: Starting Load Kernel Modules... +[ 2.239270] Linux agpgart interface v0.103 +[ 2.239725] systemd[1]: Starting Remount Root and Kernel File Systems... +[ 2.239836] systemd[1]: Condition check resulted in Repartition Root Disk being skipped. +[ 2.242013] systemd[1]: Starting Coldplug All udev Devices... +[ 2.247722] systemd[1]: Mounted Huge Pages File System. +[ 2.247922] systemd[1]: Mounted POSIX Message Queue File System. +[ 2.248097] systemd[1]: Mounted Kernel Debug File System. +[ 2.248268] systemd[1]: Mounted Kernel Trace File System. +[ 2.249206] systemd[1]: Finished Create list of static device nodes for the current kernel. +[ 2.249492] systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 237 (systemd-binfmt) +[ 2.251082] systemd[1]: Mounting Arbitrary Executable File Formats File System... +[ 2.252759] random: lvm: uninitialized urandom read (4 bytes read) +[ 2.254303] systemd[1]: Mounted Arbitrary Executable File Formats File System. +[ 2.257672] EXT4-fs (sda2): re-mounted. Opts: discard +[ 2.259658] systemd[1]: Finished Set Up Additional Binary Formats. +[ 2.260720] systemd[1]: Finished Remount Root and Kernel File Systems. +[ 2.262093] systemd[1]: Activating swap /swapfile... +[ 2.262194] systemd[1]: Condition check resulted in First Boot Wizard being skipped. +[ 2.263201] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. +[ 2.264580] systemd[1]: Starting Load/Save Random Seed... +[ 2.264697] systemd[1]: Condition check resulted in Create System Users being skipped. +[ 2.266147] systemd[1]: Starting Create Static Device Nodes in /dev... +[ 2.283363] usb 1-1: New USB device found, idVendor=8087, idProduct=0024, bcdDevice= 0.00 +[ 2.283367] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 +[ 2.283896] hub 1-1:1.0: USB hub found +[ 2.284101] hub 1-1:1.0: 6 ports detected +[ 2.299736] usb 3-1: New USB device found, idVendor=8087, idProduct=0024, bcdDevice= 0.00 +[ 2.299739] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 +[ 2.299830] systemd[1]: <email address hidden>: Succeeded. +[ 2.300029] hub 3-1:1.0: USB hub found +[ 2.300105] hub 3-1:1.0: 8 ports detected +[ 2.300160] systemd[1]: Finished Load Kernel Module drm. +[ 2.320351] vboxdrv: loading out-of-tree module taints kernel. +[ 2.320579] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel +[ 2.330511] systemd[1]: Finished Create Static Device Nodes in /dev. +[ 2.332431] systemd[1]: Starting Rule-based Manager for Device Events and Files... +[ 2.333641] vboxdrv: Found 4 processor cores +[ 2.359495] vboxdrv: TSC mode is Invariant, tentative frequency 2594105600 Hz +[ 2.359497] vboxdrv: Successfully loaded version 6.1.14 (interface 0x002e0000) +[ 2.360661] VBoxNetAdp: Successfully started. +[ 2.363175] VBoxNetFlt: Successfully started. +[ 2.364683] systemd[1]: Finished Coldplug All udev Devices. +[ 2.369357] systemd[1]: Finished Load Kernel Modules. +[ 2.369651] systemd[1]: Condition check resulted in FUSE Control File System being skipped. +[ 2.370971] systemd[1]: Mounting Kernel Configuration File System... +[ 2.372281] systemd[1]: Starting Apply Kernel Variables... +[ 2.375624] systemd[1]: Mounted Kernel Configuration File System. +[ 2.384195] systemd[1]: Finished Apply Kernel Variables. +[ 2.386538] systemd[1]: Starting CLI Netfilter Manager... +[ 2.404397] systemd[1]: Finished CLI Netfilter Manager. +[ 2.565984] usb 1-1.4: new full-speed USB device number 3 using ehci-pci +[ 2.662343] systemd[1]: Started Journal Service. +[ 2.662451] audit: type=1130 audit(1601466942.659:2): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 2.670056] usb 1-1.4: New USB device found, idVendor=0a5c, idProduct=21e6, bcdDevice= 1.12 +[ 2.670059] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +[ 2.670061] usb 1-1.4: Product: BCM20702A0 +[ 2.670063] usb 1-1.4: Manufacturer: Broadcom Corp +[ 2.670064] usb 1-1.4: SerialNumber: F4B7E2E92DEF +[ 2.745987] usb 1-1.6: new high-speed USB device number 4 using ehci-pci +[ 2.770684] audit: type=1130 audit(1601466942.769:3): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-journal-flush comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 2.770915] audit: type=1130 audit(1601466942.769:4): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 2.772398] audit: type=1130 audit(1601466942.769:5): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-lvmetad comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 2.851031] usb 1-1.6: New USB device found, idVendor=5986, idProduct=02d2, bcdDevice= 0.11 +[ 2.851035] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 +[ 2.851037] usb 1-1.6: Product: Integrated Camera +[ 2.851038] usb 1-1.6: Manufacturer: Ricoh Company Ltd. +[ 2.904083] ACPI: AC Adapter [AC] (on-line) +[ 2.966499] battery: ACPI: Battery Slot [BAT0] (battery present) +[ 2.976328] acpi PNP0C14:01: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) +[ 2.976465] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00) +[ 3.017433] random: mktemp: uninitialized urandom read (6 bytes read) +[ 3.017676] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\_SB.PCI0.LPC.PMIO) (20200528/utaddress-204) +[ 3.017682] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver +[ 3.017686] ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB.PCI0.LPC.LPIO) (20200528/utaddress-204) +[ 3.017690] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver +[ 3.017691] ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB.PCI0.LPC.LPIO) (20200528/utaddress-204) +[ 3.017694] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver +[ 3.017695] ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB.PCI0.LPC.LPIO) (20200528/utaddress-204) +[ 3.017699] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver +[ 3.017699] lpc_ich: Resource conflict(s) found affecting gpio_ich +[ 3.035132] random: tlp-readconfs: uninitialized urandom read (4 bytes read) +[ 3.094537] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k +[ 3.094539] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. +[ 3.094756] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode +[ 3.127128] tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78) +[ 3.147475] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt +[ 3.150102] i2c i2c-0: 2/2 memory slots populated (from DMI) +[ 3.150460] i2c i2c-0: Successfully instantiated SPD at 0x50 +[ 3.150800] i2c i2c-0: Successfully instantiated SPD at 0x51 +[ 3.192717] e1000e 0000:00:19.0 0000:00:19.0 (uninitialized): registered PHC clock +[ 3.211534] Non-volatile memory driver v1.3 +[ 3.213353] input: PC Speaker as /devices/platform/pcspkr/input/input5 +[ 3.251233] audit: type=1130 audit(1601466943.249:6): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-monitor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.264130] cfg80211: Loading compiled-in X.509 certificates for regulatory database +[ 3.289666] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' +[ 3.303123] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 3c:97:0e:91:ec:f6 +[ 3.303131] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection +[ 3.303180] e1000e 0000:00:19.0 eth0: MAC: 10, PHY: 11, PBA No: 1000FF-0FF +[ 3.311874] thinkpad_acpi: ThinkPad ACPI Extras v0.26 +[ 3.311875] thinkpad_acpi: http://ibm-acpi.sf.net/ +[ 3.311877] thinkpad_acpi: ThinkPad BIOS G2ETB5WW (2.75 ), EC G2HT35WW +[ 3.311878] thinkpad_acpi: Lenovo ThinkPad X230, model 2325KZ5 +[ 3.317265] thinkpad_acpi: radio switch found; radios are enabled +[ 3.317428] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver +[ 3.317429] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... +[ 3.321289] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked +[ 3.326080] audit: type=1130 audit(1601466943.323:7): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck@dev-disk-by\x2duuid-93fcb36f\x2df56a\x2d40a4\x2d844f\x2d9119b0bd77ce comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.340751] thinkpad_acpi: battery 1 registered (start 0, stop 100) +[ 3.340757] battery: new extension: ThinkPad Battery Extension +[ 3.340817] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input6 +[ 3.343823] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: discard +[ 3.405270] audit: type=1130 audit(1601466943.403:8): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck@dev-disk-by\x2duuid-4AF3\x2d613F comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.466596] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 163840 ms ovfl timer +[ 3.466598] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules +[ 3.466599] RAPL PMU: hw unit of domain package 2^-16 Joules +[ 3.466600] RAPL PMU: hw unit of domain pp1-gpu 2^-16 Joules +[ 3.576034] cryptd: max_cpu_qlen set to 1000 +[ 3.584933] iTCO_vendor_support: vendor-support=0 +[ 3.605149] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 +[ 3.605206] iTCO_wdt: Found a Panther Point TCO device (Version=2, TCOBASE=0x0460) +[ 3.609336] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) +[ 3.660146] urandom_read: 6 callbacks suppressed +[ 3.660148] random: mktemp: uninitialized urandom read (6 bytes read) +[ 3.703193] at24 0-0050: supply vcc not found, using dummy regulator +[ 3.703847] AVX version of gcm_enc/dec engaged. +[ 3.703848] AES CTR mode by8 optimization enabled +[ 3.704961] at24 0-0050: 256 byte spd EEPROM, read-only +[ 3.704998] at24 0-0051: supply vcc not found, using dummy regulator +[ 3.705693] at24 0-0051: 256 byte spd EEPROM, read-only +[ 3.724158] e1000e 0000:00:19.0 enp0s25: renamed from eth0 +[ 3.749166] audit: type=1130 audit(1601466943.746:9): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.766769] audit: type=1130 audit(1601466943.766:10): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-backlight@leds:tpacpi::kbd_backlight comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 3.880398] rtl8192ce: Chip Version ID: B_CHIP_88C +[ 3.890805] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin +[ 3.893648] ieee80211 phy0: Selected rate control algorithm 'rtl_rc' +[ 3.894756] rtlwifi: rtlwifi: wireless switch is on +[ 3.898985] rtl8192ce 0000:03:00.0 wlp3s0: renamed from wlan0 +[ 3.970027] i915 0000:00:02.0: [drm] VT-d active for gfx access +[ 3.970031] checking generic (e0000000 130000) vs hw (f0000000 400000) +[ 3.970032] checking generic (e0000000 130000) vs hw (e0000000 10000000) +[ 3.970033] fb0: switching to inteldrmfb from EFI VGA +[ 3.970116] i915 0000:00:02.0: vgaarb: deactivate vga console +[ 3.970165] i915 0000:00:02.0: [drm] DMAR active, disabling use of stolen memory +[ 3.970759] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). +[ 3.971190] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem +[ 4.015237] [drm] Initialized i915 1.6.0 20200515 for 0000:00:02.0 on minor 0 +[ 4.016186] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) +[ 4.016482] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8 +[ 4.016700] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) +[ 4.045994] Adding 17825788k swap on /swapfile. Priority:-2 extents:13 across:19259388k SSFS +[ 4.080096] psmouse serio1: synaptics: queried max coordinates: x [..5768], y [..5062] +[ 4.110834] psmouse serio1: synaptics: queried min coordinates: x [1174..], y [790..] +[ 4.163668] psmouse serio1: synaptics: Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd002a3/0x940300/0x123800/0x0, board id: 1611, fw id: 1099905 +[ 4.163677] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0 +[ 4.203728] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7 +[ 4.216023] fbcon: i915drmfb (fb0) is primary device +[ 4.216025] fbcon: Deferring console take-over +[ 4.216028] i915 0000:00:02.0: fb0: i915drmfb frame buffer device +[ 4.242713] intel_rapl_common: Found RAPL domain package +[ 4.242715] intel_rapl_common: Found RAPL domain core +[ 4.242716] intel_rapl_common: Found RAPL domain uncore +[ 4.242724] intel_rapl_common: RAPL package-0 domain package locked by BIOS +[ 4.244682] mousedev: PS/2 mouse device common for all mice +[ 4.247572] random: crng init done +[ 4.285878] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC269VC: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker +[ 4.285881] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) +[ 4.285883] snd_hda_codec_realtek hdaudioC0D0: hp_outs=2 (0x15/0x1b/0x0/0x0/0x0) +[ 4.285884] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 +[ 4.285886] snd_hda_codec_realtek hdaudioC0D0: inputs: +[ 4.285888] snd_hda_codec_realtek hdaudioC0D0: Mic=0x18 +[ 4.285889] snd_hda_codec_realtek hdaudioC0D0: Dock Mic=0x19 +[ 4.285891] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 +[ 4.318453] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10 +[ 4.318514] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11 +[ 4.318566] input: HDA Intel PCH Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12 +[ 4.318620] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13 +[ 4.318670] input: HDA Intel PCH Dock Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input14 +[ 4.318722] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input15 +[ 4.318775] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input16 +[ 4.318825] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input17 +[ 4.822473] psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3 +[ 5.012240] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input9 +[ 5.230247] kauditd_printk_skb: 23 callbacks suppressed +[ 5.230249] audit: type=1130 audit(1601466945.229:34): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 5.232515] audit: type=1130 audit(1601466945.229:35): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=libvirtd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 5.236612] audit: type=1130 audit(1601466945.236:36): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lightdm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 5.256886] audit: type=1130 audit(1601466945.256:37): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=accounts-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 5.335642] i915 0000:00:02.0: [drm] *ERROR* uncleared fifo underrun on pipe A +[ 5.335644] i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun +[ 5.337805] i915 0000:00:02.0: [drm] *ERROR* uncleared pch fifo underrun on pch transcoder A +[ 5.337808] i915 0000:00:02.0: [drm] *ERROR* PCH transcoder A FIFO underrun +[ 5.934162] mc: Linux media interface: v0.10 +[ 5.961594] videodev: Linux video capture interface: v2.00 +[ 5.985997] Bluetooth: Core ver 2.22 +[ 5.986064] NET: Registered protocol family 31 +[ 5.986065] Bluetooth: HCI device and connection manager initialized +[ 5.986069] Bluetooth: HCI socket layer initialized +[ 5.986072] Bluetooth: L2CAP socket layer initialized +[ 5.986077] Bluetooth: SCO socket layer initialized +[ 6.002062] usbcore: registered new interface driver btusb +[ 6.033197] audit: type=1130 audit(1601466946.033:38): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=bluetooth comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 6.039668] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 +[ 6.039670] Bluetooth: BNEP filters: protocol multicast +[ 6.039676] Bluetooth: BNEP socket layer initialized +[ 6.060552] uvcvideo: Found UVC 1.00 device Integrated Camera (5986:02d2) +[ 6.070700] uvcvideo 1-1.6:1.0: Entity type for entity Extension 4 was not initialized! +[ 6.070703] uvcvideo 1-1.6:1.0: Entity type for entity Extension 3 was not initialized! +[ 6.070704] uvcvideo 1-1.6:1.0: Entity type for entity Processing 2 was not initialized! +[ 6.070706] uvcvideo 1-1.6:1.0: Entity type for entity Camera 1 was not initialized! +[ 6.070786] input: Integrated Camera: Integrated C as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input18 +[ 6.070861] usbcore: registered new interface driver uvcvideo +[ 6.070862] USB Video Class driver (1.1.1) +[ 6.111534] Bluetooth: hci0: BCM: chip id 63 +[ 6.112503] Bluetooth: hci0: BCM: features 0x07 +[ 6.116008] audit: type=1130 audit(1601466946.113:39): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=wpa_supplicant comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 6.122845] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. +[ 6.128588] Bluetooth: hci0: BCM20702A +[ 6.128593] Bluetooth: hci0: BCM20702A1 (001.002.014) build 0000 +[ 6.129778] Bluetooth: hci0: BCM: firmware Patch file not found, tried: +[ 6.129780] Bluetooth: hci0: BCM: 'brcm/BCM20702A1-0a5c-21e6.hcd' +[ 6.129781] Bluetooth: hci0: BCM: 'brcm/BCM-0a5c-21e6.hcd' +[ 6.133100] tun: Universal TUN/TAP device driver, 1.6 +[ 6.133959] virbr0: port 1(virbr0-nic) entered blocking state +[ 6.134022] virbr0: port 1(virbr0-nic) entered disabled state +[ 6.134083] device virbr0-nic entered promiscuous mode +[ 6.134109] audit: type=1700 audit(1601466946.133:40): dev=virbr0-nic prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 +[ 6.145750] audit: type=1325 audit(1601466946.143:41): table=filter family=2 entries=0 op=register pid=848 comm="modprobe" +[ 6.163630] audit: type=1325 audit(1601466946.159:42): table=filter family=10 entries=0 op=register pid=851 comm="modprobe" +[ 6.183964] audit: type=1325 audit(1601466946.183:43): table=filter family=7 entries=0 op=register pid=854 comm="modprobe" +[ 6.189144] NET: Registered protocol family 38 +[ 6.578829] fuse: init (API version 7.31) +[ 6.648185] virbr0: port 1(virbr0-nic) entered blocking state +[ 6.648188] virbr0: port 1(virbr0-nic) entered listening state +[ 6.702935] virbr0: port 1(virbr0-nic) entered disabled state +[ 7.014810] L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details. +[ 10.892892] wlp3s0: authenticate with 50:d4:f7:b7:b0:ed +[ 10.910194] wlp3s0: send auth to 50:d4:f7:b7:b0:ed (try 1/3) +[ 10.912094] wlp3s0: authenticated +[ 10.912715] wlp3s0: associate with 50:d4:f7:b7:b0:ed (try 1/3) +[ 10.932804] wlp3s0: RX AssocResp from 50:d4:f7:b7:b0:ed (capab=0xc11 status=0 aid=5) +[ 10.933479] wlp3s0: associated +[ 11.025620] kauditd_printk_skb: 81 callbacks suppressed +[ 11.025624] audit: type=1131 audit(1601466951.023:124): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 11.055536] IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready +[ 13.309352] audit: type=1130 audit(1601466953.306:125): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-wait-online comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 13.423001] audit: type=1130 audit(1601466953.423:126): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=colord comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 13.544579] audit: type=1130 audit(1601466953.543:127): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=org.cups.cupsd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 14.221038] Bridge firewalling registered +[ 14.249278] audit: type=1325 audit(1601466954.246:128): table=nat family=2 entries=13 op=replace pid=1141 comm="iptables" +[ 14.251315] audit: type=1325 audit(1601466954.249:129): table=filter family=2 entries=32 op=replace pid=1143 comm="iptables" +[ 14.253178] audit: type=1325 audit(1601466954.253:130): table=filter family=2 entries=34 op=replace pid=1145 comm="iptables" +[ 14.254933] audit: type=1325 audit(1601466954.253:131): table=filter family=2 entries=36 op=replace pid=1147 comm="iptables" +[ 14.257058] audit: type=1325 audit(1601466954.256:132): table=filter family=2 entries=38 op=replace pid=1149 comm="iptables" +[ 14.259112] audit: type=1325 audit(1601466954.256:133): table=filter family=2 entries=39 op=replace pid=1151 comm="iptables" +[ 14.268897] Initializing XFRM netlink socket +[ 14.558667] docker0: port 1(vethc346366) entered blocking state +[ 14.558684] docker0: port 1(vethc346366) entered disabled state +[ 14.558779] device vethc346366 entered promiscuous mode +[ 14.558998] docker0: port 1(vethc346366) entered blocking state +[ 14.559001] docker0: port 1(vethc346366) entered forwarding state +[ 14.559059] IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready +[ 14.559147] docker0: port 1(vethc346366) entered disabled state +[ 14.622969] docker0: port 2(vethefbac9e) entered blocking state +[ 14.624737] docker0: port 2(vethefbac9e) entered disabled state +[ 14.625098] device vethefbac9e entered promiscuous mode +[ 14.625858] docker0: port 2(vethefbac9e) entered blocking state +[ 14.625862] docker0: port 2(vethefbac9e) entered forwarding state +[ 14.701963] docker0: port 3(veth7ff194c) entered blocking state +[ 14.702134] docker0: port 3(veth7ff194c) entered disabled state +[ 14.702204] device veth7ff194c entered promiscuous mode +[ 14.705997] docker0: port 3(veth7ff194c) entered blocking state +[ 14.706000] docker0: port 3(veth7ff194c) entered forwarding state +[ 14.863084] cgroup: cgroup: disabling cgroup2 socket matching due to net_prio or net_cls activation +[ 15.190945] eth0: renamed from veth4181187 +[ 15.206320] IPv6: ADDRCONF(NETDEV_CHANGE): vethefbac9e: link becomes ready +[ 15.206427] docker0: port 3(veth7ff194c) entered disabled state +[ 15.252007] eth0: renamed from veth33298ad +[ 15.283368] IPv6: ADDRCONF(NETDEV_CHANGE): vethc346366: link becomes ready +[ 15.283406] docker0: port 1(vethc346366) entered blocking state +[ 15.283409] docker0: port 1(vethc346366) entered forwarding state +[ 15.283620] eth0: renamed from vethbac852e +[ 15.294070] IPv6: ADDRCONF(NETDEV_CHANGE): veth7ff194c: link becomes ready +[ 15.294111] docker0: port 3(veth7ff194c) entered blocking state +[ 15.294112] docker0: port 3(veth7ff194c) entered forwarding state +[ 15.750977] process 'docker/tmp/qemu-check214394182/check' started with executable stack +[ 16.354169] kauditd_printk_skb: 99 callbacks suppressed +[ 16.354171] audit: type=1130 audit(1601466956.353:233): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tlp comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 19.288351] audit: type=1131 audit(1601466959.286:234): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user@620 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 19.305252] audit: type=1131 audit(1601466959.303:235): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=user-runtime-dir@620 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 23.420216] audit: type=1334 audit(1601466963.416:236): prog-id=16 op=LOAD +[ 23.420222] audit: type=1334 audit(1601466963.416:237): prog-id=17 op=LOAD +[ 24.227782] audit: type=1325 audit(1601466964.226:238): table=filter family=7 entries=0 op=register pid=2255 comm="(t-daemon)" +[ 24.234672] audit: type=1130 audit(1601466964.233:239): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 24.272943] audit: type=1130 audit(1601466964.273:240): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=upower comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 24.589346] Bluetooth: RFCOMM TTY layer initialized +[ 24.589353] Bluetooth: RFCOMM socket layer initialized +[ 24.589360] Bluetooth: RFCOMM ver 1.11 +[ 36.076399] audit: type=1131 audit(1601466970.474:241): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 36.287646] audit: type=1325 audit(1601466970.684:242): table=filter family=7 entries=0 op=unregister pid=122 comm="kworker/u16:3" +[ 36.326100] audit: type=1334 audit(1601466970.727:243): prog-id=12 op=UNLOAD +[ 36.326105] audit: type=1334 audit(1601466970.727:244): prog-id=11 op=UNLOAD +[ 39.871925] audit: type=1130 audit(1601466974.270:245): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=udisks2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 42.210875] audit: type=1325 audit(1601466976.610:246): table=filter family=7 entries=0 op=register pid=2359 comm="skypeforlinux" +[ 42.319924] audit: type=1325 audit(1601466976.714:247): table=filter family=7 entries=0 op=register pid=2351 comm="slack" +[ 46.362800] audit: type=1130 audit(1601466980.760:248): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=blueman-mechanism comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 47.283320] audit: type=1325 audit(1601466981.680:249): table=filter family=7 entries=0 op=register pid=2860 comm="electron" +[ 71.687189] pci 0000:04:00.0: [10de:1c03] type 00 class 0x030000 +[ 71.687253] pci 0000:04:00.0: reg 0x10: [mem 0x00000000-0x00ffffff] +[ 71.687286] pci 0000:04:00.0: reg 0x14: [mem 0x00000000-0x0fffffff 64bit pref] +[ 71.687312] pci 0000:04:00.0: reg 0x1c: [mem 0x00000000-0x01ffffff 64bit pref] +[ 71.687327] pci 0000:04:00.0: reg 0x24: [io 0x0000-0x007f] +[ 71.687341] pci 0000:04:00.0: reg 0x30: [mem 0x00000000-0x0007ffff pref] +[ 71.687663] pci 0000:04:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:1c.2 (capable of 126.016 Gb/s with 8.0 GT/s PCIe x16 link) +[ 71.687809] pci 0000:04:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none +[ 71.687814] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem +[ 71.687857] pci 0000:04:00.0: Adding to iommu group 14 +[ 71.688011] pci 0000:04:00.1: [10de:10f1] type 00 class 0x040300 +[ 71.688054] pci 0000:04:00.1: reg 0x10: [mem 0x00000000-0x00003fff] +[ 71.688404] pci 0000:04:00.1: Adding to iommu group 14 +[ 71.688544] pci 0000:04:00.0: BAR 1: no space for [mem size 0x10000000 64bit pref] +[ 71.688546] pci 0000:04:00.0: BAR 1: failed to assign [mem size 0x10000000 64bit pref] +[ 71.688549] pci 0000:04:00.0: BAR 3: no space for [mem size 0x02000000 64bit pref] +[ 71.688551] pci 0000:04:00.0: BAR 3: failed to assign [mem size 0x02000000 64bit pref] +[ 71.688553] pci 0000:04:00.0: BAR 0: no space for [mem size 0x01000000] +[ 71.688554] pci 0000:04:00.0: BAR 0: failed to assign [mem size 0x01000000] +[ 71.688556] pci 0000:04:00.0: BAR 6: assigned [mem 0xf1400000-0xf147ffff pref] +[ 71.688559] pci 0000:04:00.1: BAR 0: assigned [mem 0xf1480000-0xf1483fff] +[ 71.688566] pci 0000:04:00.0: BAR 5: assigned [io 0x4000-0x407f] +[ 71.688733] vfio-pci 0000:04:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none +[ 71.703798] pci 0000:04:00.1: D0 power state depends on 0000:04:00.0 +[ 78.083410] audit: type=2502 audit(1601467012.486:250): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee vm-ctx=+65534:+992 img-ctx=+65534:+992 model=dac exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.097608] audit: type=1130 audit(1601467012.503:251): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=virtlogd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 78.117228] virbr0: port 2(vnet0) entered blocking state +[ 78.117699] virbr0: port 2(vnet0) entered disabled state +[ 78.117830] device vnet0 entered promiscuous mode +[ 78.117854] audit: type=1700 audit(1601467012.523:252): dev=vnet0 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295 +[ 78.123436] virbr0: port 2(vnet0) entered blocking state +[ 78.123440] virbr0: port 2(vnet0) entered listening state +[ 78.125703] audit: type=2501 audit(1601467012.529:253): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=net reason=open vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee net=52:54:00:91:65:de path="/dev/net/tun" rdev=0A:C8 exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167333] audit: type=2501 audit(1601467012.573:254): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=deny vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=all exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167449] audit: type=2501 audit(1601467012.573:255): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=major category=pty maj=88 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167514] audit: type=2501 audit(1601467012.573:256): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=path path="/dev/null" rdev=01:03 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167575] audit: type=2501 audit(1601467012.573:257): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=path path="/dev/full" rdev=01:07 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167636] audit: type=2501 audit(1601467012.573:258): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=path path="/dev/zero" rdev=01:05 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 78.167696] audit: type=2501 audit(1601467012.573:259): pid=716 uid=0 auid=4294967295 ses=4294967295 msg='virt=kvm resrc=cgroup reason=allow vm="Win10" uuid=7043c77b-4903-4527-8089-9679d9a17fee cgroup="/sys/fs/cgroup/devices/machine.slice/machine-qemu\x2d1\x2dWin10.scope/" class=path path="/dev/random" rdev=01:08 acl=rw exe="/usr/bin/libvirtd" hostname=? addr=? terminal=? res=success' +[ 79.719645] vfio-pci 0000:04:00.0: enabling device (0000 -> 0001) +[ 79.720391] vfio-pci 0000:04:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 +[ 80.016048] virbr0: port 2(vnet0) entered disabled state +[ 80.019134] device vnet0 left promiscuous mode +[ 80.019146] virbr0: port 2(vnet0) entered disabled state +[ 88.001283] kauditd_printk_skb: 28 callbacks suppressed +[ 88.001287] audit: type=1131 audit(1601467022.409:287): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 99.367742] audit: type=1100 audit(1601467033.774:288): pid=6124 uid=1000 auid=1000 ses=2 msg='op=PAM:authentication grantors=pam_faillock,pam_permit,pam_faillock acct="sergiy" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 99.369626] audit: type=1101 audit(1601467033.778:289): pid=6124 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_permit,pam_time acct="sergiy" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 99.369821] audit: type=1110 audit(1601467033.778:290): pid=6124 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 99.370907] audit: type=1105 audit(1601467033.778:291): pid=6124 uid=0 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 100.802449] vfio-pci 0000:04:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 +[ 100.805303] qemu-system-x86[6198]: segfault at a8 ip 0000000000614c49 sp 00007ffc9a791da0 error 4 in qemu-system-x86_64[4fe000+51c000] +[ 100.805310] Code: 00 55 53 48 89 fb 48 83 ec 08 48 8b 6f 58 67 e8 3d fe ee ff 48 8b 7b 40 83 05 4e 02 a8 00 01 48 85 ff 74 06 67 e8 e7 4f 27 00 <48> 8b 85 a8 00 00 00 48 85 c0 74 53 8b 93 a0 00 00 00 eb 0f 0f 1f +[ 100.805337] audit: type=1701 audit(1601467035.215:292): auid=1000 uid=0 gid=0 ses=2 pid=6198 comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=11 res=1 +[ 100.817647] audit: type=1334 audit(1601467035.225:293): prog-id=20 op=LOAD +[ 100.817803] audit: type=1334 audit(1601467035.225:294): prog-id=21 op=LOAD +[ 100.819022] audit: type=1130 audit(1601467035.228:295): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@1-6254-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' +[ 100.819781] audit: type=1325 audit(1601467035.228:296): table=filter family=7 entries=0 op=register pid=6255 comm="(coredump)" +[ 114.388954] kauditd_printk_skb: 6 callbacks suppressed +[ 114.388957] audit: type=1101 audit(1601467048.799:303): pid=6766 uid=1000 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_permit,pam_time acct="sergiy" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 114.389190] audit: type=1110 audit(1601467048.799:304): pid=6766 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' +[ 114.389701] audit: type=1105 audit(1601467048.799:305): pid=6766 uid=0 auid=1000 ses=2 msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' + +lspci -vvv: + +00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx- + Latency: 0 + IOMMU group: 0 + Capabilities: [e0] Vendor Specific Information: Len=0c <?> + Kernel driver in use: ivb_uncore + +00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 33 + IOMMU group: 1 + Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M] + Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] + Region 4: I/O ports at 7000 [size=64] + Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] + Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee00018 Data: 0000 + Capabilities: [d0] Power Management version 2 + Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [a4] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: i915 + Kernel modules: i915 + +00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 30 + IOMMU group: 2 + Region 0: Memory at f2520000 (64-bit, non-prefetchable) [size=64K] + Capabilities: [70] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ + Address: 00000000fee00318 Data: 0000 + Kernel driver in use: xhci_hcd + Kernel modules: xhci_pci + +00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 32 + IOMMU group: 3 + Region 0: Memory at f2535000 (64-bit, non-prefetchable) [size=16] + Capabilities: [50] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+ + Address: 00000000fee00378 Data: 0000 + Kernel driver in use: mei_me + Kernel modules: mei_me + +00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller (rev 04) (prog-if 02 [16550]) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin B routed to IRQ 19 + IOMMU group: 3 + Region 0: I/O ports at 70b0 [size=8] + Region 1: Memory at f253c000 (32-bit, non-prefetchable) [size=4K] + Capabilities: [c8] Power Management version 3 + Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Kernel driver in use: serial + +00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04) + Subsystem: Lenovo Device 21f3 + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 31 + IOMMU group: 4 + Region 0: Memory at f2500000 (32-bit, non-prefetchable) [size=128K] + Region 1: Memory at f253b000 (32-bit, non-prefetchable) [size=4K] + Region 2: I/O ports at 7080 [size=32] + Capabilities: [c8] Power Management version 2 + Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- + Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ + Address: 00000000fee00358 Data: 0000 + Capabilities: [e0] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: e1000e + Kernel modules: e1000e + +00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 16 + IOMMU group: 5 + Region 0: Memory at f253a000 (32-bit, non-prefetchable) [size=1K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Debug port: BAR=1 offset=00a0 + Capabilities: [98] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: ehci-pci + Kernel modules: ehci_pci + +00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 34 + IOMMU group: 6 + Region 0: Memory at f2530000 (64-bit, non-prefetchable) [size=16K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ + Address: 00000000fee003b8 Data: 0000 + Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0 + ExtTag- RBE- FLReset+ + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + Capabilities: [100 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 + Status: NegoPending- InProgress- + VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=22 + Status: NegoPending- InProgress- + Capabilities: [130 v1] Root Complex Link + Desc: PortNumber=0f ComponentID=00 EltType=Config + Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+ + Addr: 00000000fed1c000 + Kernel driver in use: snd_hda_intel + Kernel modules: snd_hda_intel + +00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode]) + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 26 + IOMMU group: 7 + Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 + I/O behind bridge: 00006000-00006fff [size=4K] + Memory behind bridge: f1d00000-f24fffff [size=8M] + Prefetchable memory behind bridge: 00000000f0400000-00000000f0bfffff [size=8M] + Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- + BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B- + PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- + Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0 + ExtTag- RBE+ + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <16us + ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp- + LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- + SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ + Slot #0, PowerLimit 10.000W; Interlock- NoCompl+ + SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg- + Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- + SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- + Changed: MRL- PresDet- LinkState- + RootCap: CRSVisible- + RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- + RootSta: PME ReqID 0000, PMEStatus- PMEPending- + DevCap2: Completion Timeout: Range BC, TimeoutDis+ NROPrPrP- LTR- + 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- ARIFwd- + AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, ARIFwd- + AtomicOpsCtl: ReqEn- EgressBlck- + LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee00218 Data: 0000 + Capabilities: [90] Subsystem: Lenovo Device 21fa + Capabilities: [a0] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Kernel driver in use: pcieport + +00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4) (prog-if 00 [Normal decode]) + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin B routed to IRQ 27 + IOMMU group: 8 + Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 + I/O behind bridge: 00005000-00005fff [size=4K] + Memory behind bridge: f1c00000-f1cfffff [size=1M] + Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff [disabled] + Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- + BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B- + PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- + Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0 + ExtTag- RBE+ + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + LnkCap: Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <16us + ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp- + LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- + SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- + Slot #1, PowerLimit 10.000W; Interlock- NoCompl+ + SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- + Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- + SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- + Changed: MRL- PresDet- LinkState+ + RootCap: CRSVisible- + RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- + RootSta: PME ReqID 0000, PMEStatus- PMEPending- + DevCap2: Completion Timeout: Range BC, TimeoutDis+ NROPrPrP- LTR- + 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- ARIFwd- + AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, ARIFwd- + AtomicOpsCtl: ReqEn- EgressBlck- + LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee00258 Data: 0000 + Capabilities: [90] Subsystem: Lenovo Device 21fa + Capabilities: [a0] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Kernel driver in use: pcieport + +00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4) (prog-if 00 [Normal decode]) + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin C routed to IRQ 28 + IOMMU group: 9 + Bus: primary=00, secondary=04, subordinate=0b, sec-latency=0 + I/O behind bridge: 00004000-00004fff [size=4K] + Memory behind bridge: f1400000-f1bfffff [size=8M] + Prefetchable memory behind bridge: 00000000f0c00000-00000000f13fffff [size=8M] + Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- + BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B- + PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- + Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0 + ExtTag- RBE+ + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 128 bytes + DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- + LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <16us + ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp- + LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- + SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ + Slot #2, PowerLimit 10.000W; Interlock- NoCompl+ + SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg- + Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- + SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- + Changed: MRL- PresDet- LinkState- + RootCap: CRSVisible- + RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- + RootSta: PME ReqID 0000, PMEStatus- PMEPending- + DevCap2: Completion Timeout: Range BC, TimeoutDis+ NROPrPrP- LTR- + 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- ARIFwd- + AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, ARIFwd- + AtomicOpsCtl: ReqEn- EgressBlck- + LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee00298 Data: 0000 + Capabilities: [90] Subsystem: Lenovo Device 21fa + Capabilities: [a0] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Kernel driver in use: pcieport + +00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI]) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin A routed to IRQ 23 + IOMMU group: 10 + Region 0: Memory at f2539000 (32-bit, non-prefetchable) [size=1K] + Capabilities: [50] Power Management version 2 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [58] Debug port: BAR=1 offset=00a0 + Capabilities: [98] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: ehci-pci + Kernel modules: ehci_pci + +00:1f.0 ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller (rev 04) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + IOMMU group: 11 + Capabilities: [e0] Vendor Specific Information: Len=0c <?> + Kernel driver in use: lpc_ich + Kernel modules: lpc_ich + +00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0]) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0 + Interrupt: pin B routed to IRQ 29 + IOMMU group: 11 + Region 0: I/O ports at 70a8 [size=8] + Region 1: I/O ports at 70bc [size=4] + Region 2: I/O ports at 70a0 [size=8] + Region 3: I/O ports at 70b8 [size=4] + Region 4: I/O ports at 7060 [size=32] + Region 5: Memory at f2538000 (32-bit, non-prefetchable) [size=2K] + Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- + Address: fee002d8 Data: 0000 + Capabilities: [70] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004 + Capabilities: [b0] PCI Advanced Features + AFCap: TP+ FLR+ + AFCtrl: FLR- + AFStatus: TP- + Kernel driver in use: ahci + +00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04) + Subsystem: Lenovo Device 21fa + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin C routed to IRQ 18 + IOMMU group: 11 + Region 0: Memory at f2534000 (64-bit, non-prefetchable) [size=256] + Region 4: I/O ports at efa0 [size=32] + Kernel driver in use: i801_smbus + Kernel modules: i2c_i801 + +02:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 07) (prog-if 01) + Subsystem: Lenovo Device 21fa + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 16 + IOMMU group: 12 + Region 0: Memory at f1d00000 (32-bit, non-prefetchable) [size=256] + Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [78] Power Management version 3 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) + Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME- + Capabilities: [80] Express (v1) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited + ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE+ FLReset- SlotPowerLimit 10.000W + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend- + LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + Capabilities: [100 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff + Status: NegoPending- InProgress- + Capabilities: [800 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Kernel driver in use: sdhci-pci + Kernel modules: sdhci_pci + +03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01) + Subsystem: Realtek Semiconductor Co., Ltd. Device 8195 + Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Latency: 0, Cache Line Size: 64 bytes + Interrupt: pin A routed to IRQ 17 + IOMMU group: 13 + Region 0: I/O ports at 5000 [size=256] + Region 2: Memory at f1c00000 (64-bit, non-prefetchable) [size=16K] + Capabilities: [40] Power Management version 3 + Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) + Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [70] Express (v2) Endpoint, MSI 00 + DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us + ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend- + LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- + LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR- + 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- TPHComp- ExtTPHComp- + AtomicOpsCap: 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+ LTR- OBFF Disabled, + AtomicOpsCtl: ReqEn- + LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [100 v1] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr+ BadTLP- BadDLLP+ Rollover- Timeout- AdvNonFatalErr+ + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Capabilities: [140 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff + Status: NegoPending- InProgress- + Capabilities: [160 v1] Device Serial Number 01-91-81-fe-ff-4c-e0-00 + Kernel driver in use: rtl8192ce + Kernel modules: rtl8192ce + +04:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1) (prog-if 00 [VGA controller]) + Subsystem: ASUSTeK Computer Inc. Device 85b6 + Physical Slot: 1 + Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin A routed to IRQ 18 + IOMMU group: 14 + Region 1: Memory at <unassigned> (64-bit, prefetchable) [disabled] + Region 3: Memory at <unassigned> (64-bit, prefetchable) [disabled] + Region 5: I/O ports at 4000 [size=128] + Expansion ROM at f1400000 [virtual] [disabled] [size=512K] + Capabilities: [60] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [78] Express (v2) Legacy Endpoint, MSI 00 + DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us + ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend- + LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <512ns, L1 <4us + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ + LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + DevCap2: Completion Timeout: Range AB, TimeoutDis+ NROPrPrP- LTR+ + 10BitTagComp- 10BitTagReq- OBFF Via message, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, + AtomicOpsCtl: ReqEn- + LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink- Retimer- 2Retimers- DRS- + LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- + Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- + Compliance De-emphasis: -6dB + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [100 v1] Virtual Channel + Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 + Arb: Fixed- WRR32- WRR64- WRR128- + Ctrl: ArbSelect=Fixed + Status: InProgress- + VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- + Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- + Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff + Status: NegoPending- InProgress- + Capabilities: [250 v1] Latency Tolerance Reporting + Max snoop latency: 0ns + Max no snoop latency: 0ns + Capabilities: [128 v1] Power Budgeting <?> + Capabilities: [420 v2] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> + Capabilities: [900 v1] Secondary PCI Express + LnkCtl3: LnkEquIntrruptEn- PerformEqu- + LaneErrStat: 0 + Kernel driver in use: vfio-pci + Kernel modules: nouveau + +04:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller (rev a1) + Subsystem: ASUSTeK Computer Inc. Device 85b6 + Physical Slot: 1 + Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- + Interrupt: pin B routed to IRQ 0 + IOMMU group: 14 + Region 0: Memory at f1480000 (32-bit, non-prefetchable) [disabled] [size=16K] + Capabilities: [60] Power Management version 3 + Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) + Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- + Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ + Address: 0000000000000000 Data: 0000 + Capabilities: [78] Express (v2) Endpoint, MSI 00 + DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us + ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W + DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- + RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ + MaxPayload 128 bytes, MaxReadReq 512 bytes + DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend- + LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <512ns, L1 <4us + ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ + LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+ + ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- + LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded) + TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- + DevCap2: Completion Timeout: Range AB, TimeoutDis+ NROPrPrP- LTR+ + 10BitTagComp- 10BitTagReq- OBFF Via message, ExtFmt- EETLPPrefix- + EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- + FRS- TPHComp- ExtTPHComp- + AtomicOpsCap: 32bit- 64bit- 128bitCAS- + DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, + AtomicOpsCtl: ReqEn- + LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- + EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- + Retimer- 2Retimers- CrosslinkRes: unsupported + Capabilities: [100 v2] Advanced Error Reporting + UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- + UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- + CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ + AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- + MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- + HeaderLog: 00000000 00000000 00000000 00000000 + Kernel driver in use: vfio-pci + Kernel modules: snd_hda_intel + + + +Thank you Alex for answering me. + +It seems, I've got it working, if I boot the host with the connected GPU from the very beginning. +Previously, I tried hotplug and it crashes. + +So previously I had: + 1. enable the host + 2. enable GPU + 3. connect the cable + +And this time I tried: + 1. enable GPU + 2. connect the cable + 3. enable the host + +And this works great. Actually, I was able to install nvidia drivers to the Win10 guest and it runs well. + +Now, I'm not sure if there is a bug. From one side, it might be an expected requirement to exclude hotplug. From the other side, every crash is a bug, so there can be an extra check for that. It's up to you guys. + +I'm thankful for your hard work and for the rocket science technologies I can use with my laptop. + +I'm attaching dmesg for the fresh boot host with the GPU connected from the very beginning. + +P.S. I'm sorry for the big files. I've just noticed the ability to upload attachments. + + +What's more interesting, it doesn't crash if I hotplug GPU after it was boot with it. So if I do + + 1. enable GPU + 2. connect the cord + 3. enable the host + 4. run qemu (I'm not sure, if it's mandatory) + 5. disable cord + 6. disable GPU + 7. enable GPU + 8. enable cord + 9. run qemu again + +qemu doesn't crash. but the windows guest doesn't load too - it just hangs with a single core 100% load. + +Not sure, if it's related, but trying to provide as much info as possible + +There are definitely resource allocation issues on the host in the crashing case. The quirks currently enumerate the device BARs without testing them, we identify a device and know what the resources should be, which is why I think QEMU crashes. Are you able to test if the patch below is sufficient to resolve the crash? I'd expect the GPU not to work in the guest as it doesn't have enough resources, but the goal would be to resolve the crash; QEMU cannot fix the device mappings on the host. + +diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c +index 0d83eb0e47bb..10477af9fc14 100644 +--- a/hw/vfio/pci.c ++++ b/hw/vfio/pci.c +@@ -2921,7 +2921,9 @@ static void vfio_realize(PCIDevice *pdev, Error **errp) + } + + for (i = 0; i < PCI_ROM_SLOT; i++) { +- vfio_bar_quirk_setup(vdev, i); ++ if (vdev->bars[i].size) { ++ vfio_bar_quirk_setup(vdev, i); ++ } + } + + if (!vdev->igd_opregion && + + +non-mangled patch + +Can confirm that it does not crash after applying that patch. I've added the `fprintf` statement there: + + if (vdev->bars[i].size) { + vfio_bar_quirk_setup(vdev, i); + } else { + fprintf(stderr, "%04x:%04x bars for %d are empty\n", vdev->vendor_id, vdev->device_id, i); + } + +and the output is: + + 10de:1c03 bars for 0 are empty + 10de:1c03 bars for 1 are empty + 10de:1c03 bars for 2 are empty + 10de:1c03 bars for 3 are empty + 10de:1c03 bars for 4 are empty + 10de:10f1 bars for 1 are empty + 10de:10f1 bars for 2 are empty + 10de:10f1 bars for 3 are empty + 10de:10f1 bars for 4 are empty + 10de:10f1 bars for 5 are empty + +What's interesting that 5 bar is available for VGA and 0 bar is available for the sound. Don't know if it gives some valuable information. + +I understand that it's completely not a fault of QEMU, since the underlying layer gives wrong information. Any insight about potential problematic places? Is it completely a hardware issue (laptop's BIOS, nvidia) or something can be done in software? What's the next place to send a bugreport? + +Thank you + + +I recorded both lspci -vvvv and lspci -xxxx for the following connections: + + - hotplug: when GPU is connected after the host was loaded + - fresh: when GPU is connected before the host was started + +The main difference is the following: + +1c1 +< # hotplug +--- +> # fresh +6c6 +< Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- +--- +> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- +8c8 +< Interrupt: pin A routed to IRQ 18 +--- +> Interrupt: pin A routed to IRQ 255 +10,13c10,14 +< Region 1: Memory at <unassigned> (64-bit, prefetchable) [disabled] +< Region 3: Memory at <unassigned> (64-bit, prefetchable) [disabled] +< Region 5: I/O ports at 4000 [size=128] +< Expansion ROM at f1400000 [virtual] [disabled] [size=512K] +--- +> Region 0: Memory at f0000000 (32-bit, non-prefetchable) [size=16M] +> Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M] +> Region 3: Memory at d0000000 (64-bit, prefetchable) [size=32M] +> Region 5: I/O ports at 4000 [disabled] [size=128] +> Expansion ROM at f1080000 [disabled] [size=512K] +30c31 +< LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded) +--- +> LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded) +35a37 +> AtomicOpsCap: 32bit- 64bit- 128bitCAS- +79c81 +< Interrupt: pin B routed to IRQ 19 +--- +> Interrupt: pin B routed to IRQ 255 +81c83 +< Region 0: Memory at f1480000 (32-bit, non-prefetchable) [size=16K] +--- +> Region 0: Memory at f1000000 (32-bit, non-prefetchable) [size=16K] +98c100 +< LnkSta: Speed 5GT/s (downgraded), Width x1 (downgraded) +--- +> LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded) +124,125c126,127 + +I can tell, that hotplug connects as 5GT/s and fresh - 2.5GT/s. And there is an obvious difference between Regions. + +The difference between lspci -xxxx but I don't know how to interpret the result: + +124,125c126,127 +< 00: de 10 03 1c 01 00 10 00 a1 00 00 03 00 00 80 00 +< 10: 00 00 00 00 0c 00 00 00 00 00 00 00 0c 00 00 00 +--- +> 00: de 10 03 1c 02 00 10 00 a1 00 00 03 10 00 80 00 +> 10: 00 00 00 f0 0c 00 00 c0 00 00 00 00 0c 00 00 d0 +127c129 +< 30: 00 00 00 00 60 00 00 00 00 00 00 00 00 01 00 00 +--- +> 30: 00 00 f8 ff 60 00 00 00 00 00 00 00 ff 01 00 00 +132c134 +< 80: 10 29 09 00 03 3d 45 00 43 01 12 10 00 00 00 00 +--- +> 80: 10 29 09 00 03 3d 45 00 43 01 11 10 00 00 00 00 +198c200 +< 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 +--- +> 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff +221c223 +< 610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +--- +> 610: 01 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +257c259 +< 850: 00 00 00 00 78 00 00 00 ff 3f 00 00 00 00 00 00 +--- +> 850: 00 00 00 00 af 04 00 00 ff 3f 00 00 00 00 00 00 +382,383c384,385 +< 00: de 10 f1 10 02 00 10 00 a1 00 03 04 00 00 80 00 +< 10: 00 00 48 f1 00 00 00 00 00 00 00 00 00 00 00 00 +--- +> 00: de 10 f1 10 02 00 10 00 a1 00 03 04 10 00 80 00 +> 10: 00 00 00 f1 00 00 00 00 00 00 00 00 00 00 00 00 +385c387 +< 30: 00 00 00 00 60 00 00 00 00 00 00 00 00 02 00 00 +--- +> 30: 00 00 00 00 60 00 00 00 00 00 00 00 ff 02 00 00 +390c392 +< 80: 10 29 09 00 03 3d 45 00 43 01 12 10 00 00 00 00 +--- +> 80: 10 29 09 00 03 3d 45 00 43 01 11 10 00 00 00 00 +456,457c458,459 +< 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 +< 4b0: 78 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +--- +> 4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff +> 4b0: af 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1897783 b/results/classifier/118/unknown/1897783 new file mode 100644 index 00000000..db0b9fb3 --- /dev/null +++ b/results/classifier/118/unknown/1897783 @@ -0,0 +1,186 @@ +peripherals: 0.922 +risc-v: 0.905 +user-level: 0.900 +hypervisor: 0.894 +TCG: 0.890 +VMM: 0.883 +virtual: 0.883 +KVM: 0.872 +permissions: 0.870 +ppc: 0.867 +vnc: 0.863 +files: 0.858 +register: 0.845 +architecture: 0.844 +mistranslation: 0.843 +network: 0.838 +x86: 0.837 +device: 0.833 +debug: 0.830 +performance: 0.826 +graphic: 0.826 +arm: 0.819 +assembly: 0.819 +semantic: 0.815 +kernel: 0.799 +PID: 0.793 +socket: 0.791 +i386: 0.769 +boot: 0.762 + +avocado tests not running on aarch64 host + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04.1 LTS +Release: 20.04 +Codename: focal + +$ make check-venv + VENV /home/phil/qemu/build/tests/venv + PIP /home/phil/qemu/tests/requirements.txt + ERROR: Command errored out with exit status 1: + command: /home/phil/qemu/build/tests/venv/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"'; __file__='"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-ic25ctcg + cwd: /tmp/pip-install-w1h2bh4a/pycdlib/ + Complete output (6 lines): + usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] + or: setup.py --help [cmd1 cmd2 ...] + or: setup.py --help-commands + or: setup.py cmd --help + + error: invalid command 'bdist_wheel' + ---------------------------------------- + ERROR: Failed building wheel for pycdlib +$ + +Eric Auger suggested the fix: 'pip install wheel'. + +Looks like an installation problem. On Ubuntu 20.04, python3-pip depends on python3-wheel: + + +$ apt-cache show python3-pip | grep Depends +Depends: ca-certificates, python3-distutils, python3-setuptools, python3-wheel, python-pip-whl (= 20.0.2-5ubuntu1), python3:any + + +And it gets pulled during an installation attempt: + +$ apt install python3-pip +Reading package lists... Done +Building dependency tree +Reading state information... Done +The following additional packages will be installed: + binutils binutils-aarch64-linux-gnu binutils-common build-essential ca-certificates cpp cpp-9 dirmngr dpkg-dev fakeroot file g++ g++-9 gcc + gcc-9 gcc-9-base gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm libalgorithm-diff-perl + libalgorithm-diff-xs-perl libalgorithm-merge-perl libasan5 libasn1-8-heimdal libassuan0 libatomic1 libbinutils libc-dev-bin libc6-dev + libcc1-0 libcrypt-dev libctf-nobfd0 libctf0 libdpkg-perl libexpat1 libexpat1-dev libfakeroot libfile-fcntllock-perl libgcc-9-dev + libgdbm-compat4 libgdbm6 libgomp1 libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhx509-5-heimdal + libisl22 libitm1 libkrb5-26-heimdal libksba8 libldap-2.4-2 libldap-common liblocale-gettext-perl liblsan0 libmagic-mgc libmagic1 libmpc3 + libmpdec2 libmpfr6 libnpth0 libperl5.30 libpython3-dev libpython3-stdlib libpython3.8 libpython3.8-dev libpython3.8-minimal + libpython3.8-stdlib libreadline8 libroken18-heimdal libsasl2-2 libsasl2-modules libsasl2-modules-db libsqlite3-0 libssl1.1 libstdc++-9-dev + libtsan0 libubsan1 libwind0-heimdal linux-libc-dev make manpages manpages-dev mime-support netbase openssl patch perl perl-modules-5.30 + pinentry-curses python-pip-whl python3 python3-dev python3-distutils python3-lib2to3 python3-minimal python3-pkg-resources python3-setuptools + python3-wheel python3.8 python3.8-dev python3.8-minimal readline-common xz-utils zlib1g-dev + +This is on: + +lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04.1 LTS +Release: 20.04 +Codename: focal + +This seems to happen on this specific machine, not because it's an aarch64 machine, but because it has python3-minimal installed. The docs on the acceptance test state that: + +--- +Note: the build environment must be using a Python 3 stack, and have +the ``venv`` and ``pip`` packages installed. If necessary, make sure +``configure`` is called with ``--python=`` and that those modules are +available. On Debian and Ubuntu based systems, depending on the +specific version, they may be on packages named ``python3-venv`` and +``python3-pip``. +--- + +As a mitigation, I'm asking the pycdlib maintainer the possibility of also shipping wheels: + +https://github.com/clalancette/pycdlib/issues/53 + +On 10/9/20 10:55 PM, Cleber Rosa wrote: +> On with certain versions of "pip", package installations will attempt +> to create wheels. And, on environments without a "complete" Python +> installation (as described in the acceptance tests requirements docs), +> that will fail. +> +> pycdlib, starting with version 1.11.0, is now being made available +> as wheels, so its instalation on those constrained environments is +> now possible. +> +> Cc: Bug 1897783 <email address hidden> +> Buglink: https://bugs.launchpad.net/qemu/+bug/1880189 + +This BZ is different. The correct URL is: +https://bugs.launchpad.net/qemu/+bug/1897783 + +Reviewed-by: Philippe Mathieu-Daudé <email address hidden> +Tested-by: Philippe Mathieu-Daudé <email address hidden> + +> Reported-by: Philippe Mathieu-Daudé <email address hidden> +> Signed-off-by: Cleber Rosa <email address hidden> +> --- +> tests/requirements.txt | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/tests/requirements.txt b/tests/requirements.txt +> index 036691c922..a1c631fa59 100644 +> --- a/tests/requirements.txt +> +++ b/tests/requirements.txt +> @@ -2,4 +2,4 @@ +> # in the tests/venv Python virtual environment. For more info, +> # refer to: https://pip.pypa.io/en/stable/user_guide/#id1 +> avocado-framework==81.0 +> -pycdlib==1.9.0 +> +pycdlib==1.11.0 +> + + + +On Fri, Oct 9, 2020 at 5:55 PM Cleber Rosa <email address hidden> wrote: +> +> On with certain versions of "pip", package installations will attempt +> to create wheels. And, on environments without a "complete" Python +> installation (as described in the acceptance tests requirements docs), +> that will fail. +> +> pycdlib, starting with version 1.11.0, is now being made available +> as wheels, so its instalation on those constrained environments is +> now possible. +> +> Cc: Bug 1897783 <email address hidden> +> Buglink: https://bugs.launchpad.net/qemu/+bug/1880189 +> Reported-by: Philippe Mathieu-Daudé <email address hidden> +> Signed-off-by: Cleber Rosa <email address hidden> +> --- +> tests/requirements.txt | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/tests/requirements.txt b/tests/requirements.txt +> index 036691c922..a1c631fa59 100644 +> --- a/tests/requirements.txt +> +++ b/tests/requirements.txt +> @@ -2,4 +2,4 @@ +> # in the tests/venv Python virtual environment. For more info, +> # refer to: https://pip.pypa.io/en/stable/user_guide/#id1 +> avocado-framework==81.0 +> -pycdlib==1.9.0 +> +pycdlib==1.11.0 +> -- +> 2.25.4 +> + +Reviewed-by: Willian Rampazzo <email address hidden> + + + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/unknown/1900241 b/results/classifier/118/unknown/1900241 new file mode 100644 index 00000000..2770d1f6 --- /dev/null +++ b/results/classifier/118/unknown/1900241 @@ -0,0 +1,267 @@ +mistranslation: 0.922 +permissions: 0.918 +user-level: 0.905 +hypervisor: 0.905 +assembly: 0.900 +performance: 0.897 +register: 0.896 +semantic: 0.879 +peripherals: 0.878 +architecture: 0.877 +debug: 0.871 +graphic: 0.871 +TCG: 0.866 +boot: 0.861 +socket: 0.857 +device: 0.845 +vnc: 0.845 +VMM: 0.843 +PID: 0.842 +arm: 0.840 +kernel: 0.835 +ppc: 0.833 +files: 0.831 +network: 0.829 +virtual: 0.827 +KVM: 0.810 +x86: 0.780 +i386: 0.778 +risc-v: 0.761 + +[regression][powerpc] some vcpus are found offline inside guest with different vsmt setting from qemu-cmdline and breaks subsequent vcpu hotplug operation (xive) + +Env: +Host: Power9 HW ppc64le + +# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 128 +On-line CPU(s) list: 24-31,40-159 +Thread(s) per core: 4 +Core(s) per socket: 16 +Socket(s): 2 +NUMA node(s): 2 +Model: 2.3 (pvr 004e 1203) +Model name: POWER9, altivec supported +Frequency boost: enabled +CPU max MHz: 3800.0000 +CPU min MHz: 2300.0000 +L1d cache: 1 MiB +L1i cache: 1 MiB +L2 cache: 8 MiB +L3 cache: 160 MiB +NUMA node0 CPU(s): 24-31,40-79 +NUMA node8 CPU(s): 80-159 +Vulnerability Itlb multihit: Not affected +Vulnerability L1tf: Mitigation; RFI Flush, L1D private per thread +Vulnerability Mds: Not affected +Vulnerability Meltdown: Mitigation; RFI Flush, L1D private per thread +Vulnerability Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) +Vulnerability Spectre v1: Mitigation; __user pointer sanitization, ori31 speculation barrier enabled +Vulnerability Spectre v2: Mitigation; Software count cache flush (hardware accelerated), Software link stack flush +Vulnerability Srbds: Not affected +Vulnerability Tsx async abort: Not affected + + + +Host Kernel: 5.9.0-0.rc8.28.fc34.ppc64le (Fedora rawhide) +Guest Kernel: Fedora33(5.8.6-301.fc33.ppc64le) + +Qemu: e12ce85b2c79d83a340953291912875c30b3af06 (qemu/master) + + +Steps to reproduce: + +Boot below kvm guest: (-M pseries,vsmt=2 -smp 8,cores=8,threads=1) + + /home/sath/qemu/build/qemu-system-ppc64 -name vm1 -M pseries,vsmt=2 -accel kvm -m 4096 -smp 8,cores=8,threads=1 -nographic -nodefaults -serial mon:stdio -vga none -nographic -device virtio-scsi-pci -drive file=/home/sath/tests/data/avocado-vt/images/fdevel-ppc64le.qcow2,if=none,id=hd0,format=qcow2,cache=none -device scsi-hd,drive=hd0 + + +lscpu inside guest: +Actual: +[root@atest-guest ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 8 +On-line CPU(s) list: 0,2,4,6 +Off-line CPU(s) list: 1,3,5,7 --------------------------NOK +Thread(s) per core: 1 +Core(s) per socket: 4 +Socket(s): 1 +NUMA node(s): 1 +Model: 2.3 (pvr 004e 1203) +Model name: POWER9 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 128 KiB +L1i cache: 128 KiB +NUMA node0 CPU(s): 0,2,4,6 +Vulnerability Itlb multihit: Not affected +Vulnerability L1tf: Mitigation; RFI Flush, L1D private per thread +Vulnerability Mds: Not affected +Vulnerability Meltdown: Mitigation; RFI Flush, L1D private per thread +Vulnerability Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) +Vulnerability Spectre v1: Mitigation; __user pointer sanitization, ori31 + speculation barrier enabled +Vulnerability Spectre v2: Mitigation; Software count cache flush (hardwar + e accelerated), Software link stack flush +Vulnerability Srbds: Not affected +Vulnerability Tsx async abort: Not affected + + +Expected: + +[root@atest-guest ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 8 +On-line CPU(s) list: 0-7 +Thread(s) per core: 1 +Core(s) per socket: 8 +Socket(s): 1 +NUMA node(s): 1 +Model: 2.3 (pvr 004e 1203) +Model name: POWER9 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 256 KiB +L1i cache: 256 KiB +NUMA node0 CPU(s): 0-7 +Vulnerability Itlb multihit: Not affected +Vulnerability L1tf: Mitigation; RFI Flush, L1D private per thread +Vulnerability Mds: Not affected +Vulnerability Meltdown: Mitigation; RFI Flush, L1D private per thread +Vulnerability Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio) +Vulnerability Spectre v1: Mitigation; __user pointer sanitization, ori31 + speculation barrier enabled +Vulnerability Spectre v2: Mitigation; Software count cache flush (hardwar + e accelerated), Software link stack flush +Vulnerability Srbds: Not affected +Vulnerability Tsx async abort: Not affected + + + +There by further vcpuhotplug operation fails... + +Did a git bisect and the bad commit is + +acbdb9956fe93f4669141f103cb543d3025775db is the first bad commit +commit acbdb9956fe93f4669141f103cb543d3025775db +Author: Cédric Le Goater <email address hidden> +Date: Thu Aug 20 15:45:46 2020 +0200 + + spapr/xive: Allocate IPIs independently from the other sources + + The vCPU IPIs are now allocated in kvmppc_xive_cpu_connect() when the + vCPU connects to the KVM device and not when all the sources are reset + in kvmppc_xive_source_reset() + + This requires extra care for hotplug vCPUs and VM restore. + + Signed-off-by: Cédric Le Goater <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: David Gibson <email address hidden> + + hw/intc/spapr_xive_kvm.c | 47 ++++++++++++++++++++++++++++++++++++++++++----- + 1 file changed, 42 insertions(+), 5 deletions(-) + + + + +# git bisect log +git bisect start +# good: [d0ed6a69d399ae193959225cdeaa9382746c91cc] Update version for v5.1.0 release +git bisect good d0ed6a69d399ae193959225cdeaa9382746c91cc +# bad: [7daf8f8d011cdd5d3e86930ed2bde969425c790c] Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging +git bisect bad 7daf8f8d011cdd5d3e86930ed2bde969425c790c +# skip: [7595a65818ea9b49c36650a8c217a1ef9bd6e62a] hw/riscv: Sort the Kconfig options in alphabetical order +git bisect skip 7595a65818ea9b49c36650a8c217a1ef9bd6e62a +# skip: [3b65b742543bc6c2ad35e3b42401a26b48a87f26] target/hppa: Fix boot with old Linux installation CDs +git bisect skip 3b65b742543bc6c2ad35e3b42401a26b48a87f26 +# bad: [f4ef8c9cc10b3bee829b9775879d4ff9f77c2442] Merge remote-tracking branch 'remotes/ehabkost/tags/machine-next-pull-request' into staging +git bisect bad f4ef8c9cc10b3bee829b9775879d4ff9f77c2442 +# good: [4ee40a6b98c02b72fc5dd262df9d3ac8680d767b] hw/usb: Add U2F device check to passthru mode +git bisect good 4ee40a6b98c02b72fc5dd262df9d3ac8680d767b +# skip: [fe4b0b5bfa96c38ad1cad0689a86cca9f307e353] tcg: Implement 256-bit dup for tcg_gen_gvec_dup_mem +git bisect skip fe4b0b5bfa96c38ad1cad0689a86cca9f307e353 +# skip: [287b1defeb44398d02669d97ebdc347d650f274d] target/microblaze: Cache mem_index in DisasContext +git bisect skip 287b1defeb44398d02669d97ebdc347d650f274d +# skip: [7a1fb2ef40df508e90eb756a80d67e6435246cae] block/nvme: Extract nvme_poll_queue() +git bisect skip 7a1fb2ef40df508e90eb756a80d67e6435246cae +# good: [536e340f464d7c2ef55cca47c7535d9409bf03c7] target/microblaze: Convert msrclr, msrset to decodetree +git bisect good 536e340f464d7c2ef55cca47c7535d9409bf03c7 +# good: [227de21ed0759e275a469394af72c999d0134bb5] Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20200903' into staging +git bisect good 227de21ed0759e275a469394af72c999d0134bb5 +# bad: [b95ba83fc56ebfc4b6869f21db0c757c0c191104] Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.2-20200908' into staging +git bisect bad b95ba83fc56ebfc4b6869f21db0c757c0c191104 +# good: [789035f1239054331b335801a06bdbef026f02e1] oss-fuzz: fix rpath +git bisect good 789035f1239054331b335801a06bdbef026f02e1 +# good: [00942071a0eabeb3ebc3bd594296859587f8f3c8] Merge remote-tracking branch 'remotes/rth/tags/pull-mb-20200907-2' into staging +git bisect good 00942071a0eabeb3ebc3bd594296859587f8f3c8 +# bad: [554c2169e9251ca2829ab968bd9ba5641a5abe1d] ppc/spapr: Use start-powered-off CPUState property +git bisect bad 554c2169e9251ca2829ab968bd9ba5641a5abe1d +# good: [235d3b116213828f4206e2e4b199a32bffc96f35] spapr/xive: Modify kvm_cpu_is_enabled() interface +git bisect good 235d3b116213828f4206e2e4b199a32bffc96f35 +# bad: [90d282d0858cf5a38f3e8a7e201aeab2a0ccbe88] ppc/spapr_nvdimm: use g_autofree in spapr_nvdimm_validate_opts() +git bisect bad 90d282d0858cf5a38f3e8a7e201aeab2a0ccbe88 +# bad: [acbdb9956fe93f4669141f103cb543d3025775db] spapr/xive: Allocate IPIs independently from the other sources +git bisect bad acbdb9956fe93f4669141f103cb543d3025775db +# good: [fa94447a2cd6643609d5822d5b5f739dc8ad8a8c] spapr/xive: Use kvmppc_xive_source_reset() in post_load +git bisect good fa94447a2cd6643609d5822d5b5f739dc8ad8a8c +# first bad commit: [acbdb9956fe93f4669141f103cb543d3025775db] spapr/xive: Allocate IPIs independently from the other sources + + +Regards, +-Satheesh + +Fixed by reverting the series that caused the regression. + +https://git.qemu.org/?p=qemu.git;a=commit;h=6d24795ee7e3199d199d3c415312c93382ad1807 + +The optimization needs to be reworked later. + + + +Tested with latest upstream and found the issue is fixed, + + +# git log -1 +commit dd3d2340c4076d1735cd0f7cb61f4d8622b9562d (HEAD -> master, tag: v5.2.0-rc3, origin/master, origin/HEAD) +Author: Peter Maydell <email address hidden> +Date: Tue Nov 24 22:13:30 2020 +0000 + + Update version for v5.2.0-rc3 release + + Signed-off-by: Peter Maydell <email address hidden> + + +/home/sath/qemu/build/qemu-system-ppc64 -name vm1 -M pseries,vsmt=2 -accel kvm -m 4096 -smp 8,cores=8,threads=1 -nographic -nodefaults -serial mon:stdio -vga none -nographic -device virtio-scsi-pci -drive file=/home/sath/tests/data/avocado-vt/images/fdevel-ppc64le.qcow2,if=none,id=hd0,format=qcow2,cache=none -device scsi-hd,drive=hd0 + + +Fedora 33 (Thirty Three Prerelease) +Kernel 5.8.13-300.fc33.ppc64le on an ppc64le (hvc0) + +atest-guest login: root +Password: +Login incorrect + +atest-guest login: root +Password: +Last login: Wed Nov 18 09:03:24 on hvc0 +[root@atest-guest ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 8 +On-line CPU(s) list: 0-7 +Thread(s) per core: 1 +Core(s) per socket: 8 +Socket(s): 1 +NUMA node(s): 1 + + +Regards, +-Satheesh + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/unknown/1902470 b/results/classifier/118/unknown/1902470 new file mode 100644 index 00000000..36f631f1 --- /dev/null +++ b/results/classifier/118/unknown/1902470 @@ -0,0 +1,357 @@ +user-level: 0.875 +mistranslation: 0.845 +hypervisor: 0.834 +risc-v: 0.834 +graphic: 0.830 +debug: 0.828 +permissions: 0.827 +virtual: 0.826 +KVM: 0.826 +architecture: 0.816 +vnc: 0.816 +ppc: 0.816 +x86: 0.812 +peripherals: 0.809 +TCG: 0.807 +files: 0.803 +semantic: 0.801 +network: 0.797 +performance: 0.796 +arm: 0.796 +device: 0.795 +assembly: 0.793 +i386: 0.792 +register: 0.790 +socket: 0.787 +boot: 0.785 +VMM: 0.781 +kernel: 0.776 +PID: 0.765 + +migration with TLS-MultiFD is stuck when the dst-libvirtd service restarts + +hi, + +I found that the multi-channel TLS-handshake will be stuck when the dst-libvirtd restarts, both the src and dst sockets are blocked in recvmsg. In the meantime, live_migration thread is blocked in multifd_send_sync_main, so +migration cannot be cancelled though src-libvirt has delivered the QMP command. + +Is there any way to exit migration when the multi-channel TLS-handshake is stuck? Does setting TLS handshake timeout function take effect? + +The stack trace are as follows: + +=====src qemu-system-aar stack=====: +#0 0x0000ffff87d6f28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +#1 0x0000aaaae3817424 in qio_channel_socket_readv (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +#2 0x0000aaaae380f468 in qio_channel_readv_full (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +#3 0x0000aaaae380f9e8 in qio_channel_read (ioc=0xaaaae9e30a30, buf=0xaaaaea204e9b "\026\003\001\001L\001", buflen=5, errp=0x0) at ../io/channel.c:217 +#4 0x0000aaaae380e7d4 in qio_channel_tls_read_handler (buf=0xaaaaea204e9b "\026\003\001\001L\001", len=5, opaque=0xfffd38001190) at ../io/channel-tls.c:53 +#5 0x0000aaaae3801114 in qcrypto_tls_session_pull (opaque=0xaaaae99d5700, buf=0xaaaaea204e9b, len=5) at ../crypto/tlssession.c:89 +#6 0x0000ffff8822ed30 in _gnutls_stream_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:346 +#7 _gnutls_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:426 +#8 _gnutls_io_read_buffered (session=session@entry=0xaaaae983cd60, total=5, recv_type=recv_type@entry=4294967295, ms=0xffffdb58eaac) at buffers.c:581 +#9 0x0000ffff88224954 in recv_headers (ms=<optimized out>, record=0xffff883cd000 <email address hidden>, htype=65535, type=2284006288, + record_params=0xaaaae9e22a60, session=0xaaaae983cd60) at record.c:1163 +#10 _gnutls_recv_in_buffers (session=session@entry=0xaaaae983cd60, type=2284006288, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, + ms=<optimized out>, ms@entry=0) at record.c:1302 +#11 0x0000ffff88230568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaae983cd60, htype=htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, hsk=hsk@entry=0xffffdb58ec38, + optional=optional@entry=1) at buffers.c:1445 +#12 0x0000ffff88232b90 in _gnutls_recv_handshake (session=session@entry=0xaaaae983cd60, type=type@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, optional=optional@entry=1, + buf=buf@entry=0x0) at handshake.c:1534 +#13 0x0000ffff88235b40 in handshake_client (session=session@entry=0xaaaae983cd60) at handshake.c:2925 +#14 0x0000ffff88237824 in gnutls_handshake (session=0xaaaae983cd60) at handshake.c:2739 +#15 0x0000aaaae380213c in qcrypto_tls_session_handshake (session=0xaaaae99d5700, errp=0xffffdb58ee58) at ../crypto/tlssession.c:493 +#16 0x0000aaaae380ea40 in qio_channel_tls_handshake_task (ioc=0xfffd38001190, task=0xaaaaea61d4e0, context=0x0) at ../io/channel-tls.c:161 +#17 0x0000aaaae380ec60 in qio_channel_tls_handshake (ioc=0xfffd38001190, func=0xaaaae3394d20 <multifd_tls_outgoing_handshake>, opaque=0xaaaaea189c30, destroy=0x0, context=0x0) + at ../io/channel-tls.c:239 +#18 0x0000aaaae3394e78 in multifd_tls_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, errp=0xffffdb58ef28) at ../migration/multifd.c:782 +#19 0x0000aaaae3394f30 in multifd_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, error=0x0) at ../migration/multifd.c:804 +#20 0x0000aaaae33950b8 in multifd_new_send_channel_async (task=0xaaaaea6855a0, opaque=0xaaaaea189c30) at ../migration/multifd.c:858 +#21 0x0000aaaae3810cf8 in qio_task_complete (task=0xaaaaea6855a0) at ../io/task.c:197 +#22 0x0000aaaae381096c in qio_task_thread_result (opaque=0xaaaaea6855a0) at ../io/task.c:112 +#23 0x0000ffff88701df8 in ?? () from target:/usr/lib64/libglib-2.0.so.0 +#24 0x0000ffff88705a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +#25 0x0000aaaae3a5a29c in glib_pollfds_poll () at ../util/main-loop.c:221 +#26 0x0000aaaae3a5a324 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:244 +#27 0x0000aaaae3a5a444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +#28 0x0000aaaae3696b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +#29 0x0000aaaae30949e4 in main (argc=81, argv=0xffffdb58f2c8, envp=0xffffdb58f558) at ../softmmu/main.c:50 + +=====src live_migration stack=====: +#0 0x0000ffff87d6a5d8 in pthread_cond_wait () from target:/usr/lib64/libpthread.so.0 +#1 0x0000aaaae3a5f3ec in qemu_sem_wait (sem=0xaaaaea189d40) at ../util/qemu-thread-posix.c:328 +#2 0x0000aaaae3394838 in multifd_send_sync_main (f=0xaaaae983f0e0) at ../migration/multifd.c:638 +#3 0x0000aaaae37de310 in ram_save_setup (f=0xaaaae983f0e0, opaque=0xaaaae4198708 <ram_state>) at ../migration/ram.c:2588 +#4 0x0000aaaae31cf7ac in qemu_savevm_state_setup (f=0xaaaae983f0e0) at ../migration/savevm.c:1176 +#5 0x0000aaaae3248360 in migration_thread (opaque=0xaaaae9829f20) at ../migration/migration.c:3521 +#6 0x0000aaaae3a5f8fc in qemu_thread_start (args=0xaaaaea513ee0) at ../util/qemu-thread-posix.c:521 +#7 0x0000ffff87d647ac in ?? () from target:/usr/lib64/libpthread.so.0 +#8 0x0000ffff87cba6ec in ?? () from target:/usr/lib64/libc.so.6 + +=====dst qemu-system-aar stack=====: +#0 0x0000ffff7f17d28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +#1 0x0000aaaae263a424 in qio_channel_socket_readv (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +#2 0x0000aaaae2632468 in qio_channel_readv_full (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +#3 0x0000aaaae26329e8 in qio_channel_read (ioc=0xaaaaf998a800, + buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., buflen=5, errp=0x0) + at ../io/channel.c:217 +#4 0x0000aaaae26317d4 in qio_channel_tls_read_handler ( + buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., len=5, + opaque=0xaaaaf9c4c400) at ../io/channel-tls.c:53 +#5 0x0000aaaae2624114 in qcrypto_tls_session_pull (opaque=0xaaaafa4a3d90, buf=0xaaaafa926dbb, len=5) at ../crypto/tlssession.c:89 +#6 0x0000ffff7f63cd30 in _gnutls_stream_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:346 +#7 _gnutls_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:426 +#8 _gnutls_io_read_buffered (session=session@entry=0xaaaafa58b9d0, total=5, recv_type=recv_type@entry=4294967295, ms=0xfffff5d2317c) at buffers.c:581 +#9 0x0000ffff7f632954 in recv_headers (ms=<optimized out>, record=0x1ee2a9fa78, htype=65535, type=2137262992, record_params=0xaaaafa4b71a0, session=0xaaaafa58b9d0) at record.c:1163 +#10 _gnutls_recv_in_buffers (session=session@entry=0xaaaafa58b9d0, type=2137262992, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, + ms=<optimized out>, ms@entry=0) at record.c:1302 +#11 0x0000ffff7f63e568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaafa58b9d0, htype=htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, hsk=hsk@entry=0xfffff5d23308, + optional=optional@entry=0) at buffers.c:1445 +#12 0x0000ffff7f640b90 in _gnutls_recv_handshake (session=session@entry=0xaaaafa58b9d0, type=type@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, optional=optional@entry=0, buf=buf@entry=0x0) + at handshake.c:1534 +#13 0x0000ffff7f645f18 in handshake_server (session=<optimized out>) at handshake.c:3351 +#14 gnutls_handshake (session=0xaaaafa58b9d0) at handshake.c:2742 +#15 0x0000aaaae262513c in qcrypto_tls_session_handshake (session=0xaaaafa4a3d90, errp=0xfffff5d23478) at ../crypto/tlssession.c:493 +#16 0x0000aaaae2631a40 in qio_channel_tls_handshake_task (ioc=0xaaaaf9c4c400, task=0xaaaafa70e600, context=0x0) at ../io/channel-tls.c:161 +#17 0x0000aaaae2631c60 in qio_channel_tls_handshake (ioc=0xaaaaf9c4c400, func=0xaaaae20d4b58 <migration_tls_incoming_handshake>, opaque=0x0, destroy=0x0, context=0x0) + at ../io/channel-tls.c:239 +#18 0x0000aaaae20d4ca8 in migration_tls_channel_process_incoming (s=0xaaaaf9b2ef20, ioc=0xaaaaf998a800, errp=0xfffff5d23548) at ../migration/tls.c:103 +#19 0x0000aaaae20f9f7c in migration_channel_process_incoming (ioc=0xaaaaf998a800) at ../migration/channel.c:42 +#20 0x0000aaaae1f484a8 in socket_accept_incoming_migration (listener=0xffff64007a40, cioc=0xaaaaf998a800, opaque=0x0) at ../migration/socket.c:130 +#21 0x0000aaaae2638570 in qio_net_listener_channel_func (ioc=0xaaaafa410600, condition=G_IO_IN, opaque=0xffff64007a40) at ../io/net-listener.c:54 +#22 0x0000aaaae263ac4c in qio_channel_fd_source_dispatch (source=0xaaaafa81a380, callback=0xaaaae26384f8 <qio_net_listener_channel_func>, user_data=0xffff64007a40) + at ../io/channel-watch.c:84 +#23 0x0000ffff7fb13a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +#24 0x0000aaaae287d29c in glib_pollfds_poll () at ../util/main-loop.c:221 +#25 0x0000aaaae287d324 in os_host_main_loop_wait (timeout=571000000) at ../util/main-loop.c:244 +#26 0x0000aaaae287d444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +#27 0x0000aaaae24b9b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +#28 0x0000aaaae1eb79e4 in main (argc=83, argv=0xfffff5d238c8, envp=0xfffff5d23b68) at ../softmmu/main.c:50 + +* zhengchuan (<email address hidden>) wrote: +> Anyone who could help this would be appreciated since we have stuck for three days:( +> +> IIUC, the client (Src) has sent first hello message to sever(Dst), however due to something happened while restarted libvirtd, +> The messages is lost, and both of them are waiting which leading to hang forever, but I could find out how for now. + +If you need to un-break things, I suggest killing the destination might +free it; but I'm not sure. + +An interesting question is if we can make migration-cancel work in this +case. + +Dave + +> -----Original Message----- +> From: Qemu-devel [mailto:<email address hidden>] On Behalf Of Yan Jin +> Sent: 2020年11月2日 11:12 +> To: <email address hidden> +> Subject: [Bug 1902470] Re: migration with TLS-MultiFD is stuck when the dst-libvirtd service restarts +> +> ** Description changed: +> +> hi, +> +> I found that the multi-channel TLS-handshake will be stuck when the dst- +> libvirtd restarts, both the src and dst sockets are blocked in recvmsg. +> In the meantime, live_migration thread is blocked in +> multifd_send_sync_main, so migration cannot be cancelled though src- +> libvirt has delivered the QMP command. +> +> Is there any way to exit migration when the multi-channel TLS-handshake +> - is stuck? Does setting TLS handshake timeout function take effect? +> + is stuck? Does setting TLS-handshake timeout function take effect? +> +> The stack trace are as follows: +> +> =====src qemu-system-aar stack=====: +> #0 0x0000ffff87d6f28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +> #1 0x0000aaaae3817424 in qio_channel_socket_readv (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +> #2 0x0000aaaae380f468 in qio_channel_readv_full (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +> #3 0x0000aaaae380f9e8 in qio_channel_read (ioc=0xaaaae9e30a30, buf=0xaaaaea204e9b "\026\003\001\001L\001", buflen=5, errp=0x0) at ../io/channel.c:217 +> #4 0x0000aaaae380e7d4 in qio_channel_tls_read_handler (buf=0xaaaaea204e9b "\026\003\001\001L\001", len=5, opaque=0xfffd38001190) at ../io/channel-tls.c:53 +> #5 0x0000aaaae3801114 in qcrypto_tls_session_pull (opaque=0xaaaae99d5700, buf=0xaaaaea204e9b, len=5) at ../crypto/tlssession.c:89 +> #6 0x0000ffff8822ed30 in _gnutls_stream_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:346 +> #7 _gnutls_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:426 +> #8 _gnutls_io_read_buffered (session=session@entry=0xaaaae983cd60, total=5, recv_type=recv_type@entry=4294967295, ms=0xffffdb58eaac) at buffers.c:581 +> #9 0x0000ffff88224954 in recv_headers (ms=<optimized out>, record=0xffff883cd000 <email address hidden>, htype=65535, type=2284006288, record_params=0xaaaae9e22a60, session=0xaaaae983cd60) at record.c:1163 +> #10 _gnutls_recv_in_buffers (session=session@entry=0xaaaae983cd60, type=2284006288, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, ms=<optimized out>, ms@entry=0) at record.c:1302 +> #11 0x0000ffff88230568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaae983cd60, htype=htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, hsk=hsk@entry=0xffffdb58ec38, optional=optional@entry=1) at buffers.c:1445 +> #12 0x0000ffff88232b90 in _gnutls_recv_handshake (session=session@entry=0xaaaae983cd60, type=type@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, optional=optional@entry=1, buf=buf@entry=0x0) at handshake.c:1534 +> #13 0x0000ffff88235b40 in handshake_client (session=session@entry=0xaaaae983cd60) at handshake.c:2925 +> #14 0x0000ffff88237824 in gnutls_handshake (session=0xaaaae983cd60) at handshake.c:2739 +> #15 0x0000aaaae380213c in qcrypto_tls_session_handshake (session=0xaaaae99d5700, errp=0xffffdb58ee58) at ../crypto/tlssession.c:493 +> #16 0x0000aaaae380ea40 in qio_channel_tls_handshake_task (ioc=0xfffd38001190, task=0xaaaaea61d4e0, context=0x0) at ../io/channel-tls.c:161 +> #17 0x0000aaaae380ec60 in qio_channel_tls_handshake (ioc=0xfffd38001190, func=0xaaaae3394d20 <multifd_tls_outgoing_handshake>, opaque=0xaaaaea189c30, destroy=0x0, context=0x0) at ../io/channel-tls.c:239 +> #18 0x0000aaaae3394e78 in multifd_tls_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, errp=0xffffdb58ef28) at ../migration/multifd.c:782 +> #19 0x0000aaaae3394f30 in multifd_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, error=0x0) at ../migration/multifd.c:804 +> #20 0x0000aaaae33950b8 in multifd_new_send_channel_async (task=0xaaaaea6855a0, opaque=0xaaaaea189c30) at ../migration/multifd.c:858 +> #21 0x0000aaaae3810cf8 in qio_task_complete (task=0xaaaaea6855a0) at ../io/task.c:197 +> #22 0x0000aaaae381096c in qio_task_thread_result (opaque=0xaaaaea6855a0) at ../io/task.c:112 +> #23 0x0000ffff88701df8 in ?? () from target:/usr/lib64/libglib-2.0.so.0 +> #24 0x0000ffff88705a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +> #25 0x0000aaaae3a5a29c in glib_pollfds_poll () at ../util/main-loop.c:221 +> #26 0x0000aaaae3a5a324 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:244 +> #27 0x0000aaaae3a5a444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +> #28 0x0000aaaae3696b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +> #29 0x0000aaaae30949e4 in main (argc=81, argv=0xffffdb58f2c8, envp=0xffffdb58f558) at ../softmmu/main.c:50 +> +> =====src live_migration stack=====: +> #0 0x0000ffff87d6a5d8 in pthread_cond_wait () from target:/usr/lib64/libpthread.so.0 +> #1 0x0000aaaae3a5f3ec in qemu_sem_wait (sem=0xaaaaea189d40) at ../util/qemu-thread-posix.c:328 +> #2 0x0000aaaae3394838 in multifd_send_sync_main (f=0xaaaae983f0e0) at ../migration/multifd.c:638 +> #3 0x0000aaaae37de310 in ram_save_setup (f=0xaaaae983f0e0, opaque=0xaaaae4198708 <ram_state>) at ../migration/ram.c:2588 +> #4 0x0000aaaae31cf7ac in qemu_savevm_state_setup (f=0xaaaae983f0e0) at ../migration/savevm.c:1176 +> #5 0x0000aaaae3248360 in migration_thread (opaque=0xaaaae9829f20) at ../migration/migration.c:3521 +> #6 0x0000aaaae3a5f8fc in qemu_thread_start (args=0xaaaaea513ee0) at ../util/qemu-thread-posix.c:521 +> #7 0x0000ffff87d647ac in ?? () from target:/usr/lib64/libpthread.so.0 +> #8 0x0000ffff87cba6ec in ?? () from target:/usr/lib64/libc.so.6 +> +> =====dst qemu-system-aar stack=====: +> #0 0x0000ffff7f17d28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +> #1 0x0000aaaae263a424 in qio_channel_socket_readv (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +> #2 0x0000aaaae2632468 in qio_channel_readv_full (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +> #3 0x0000aaaae26329e8 in qio_channel_read (ioc=0xaaaaf998a800, buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., buflen=5, errp=0x0) at ../io/channel.c:217 +> #4 0x0000aaaae26317d4 in qio_channel_tls_read_handler (buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., len=5, opaque=0xaaaaf9c4c400) at ../io/channel-tls.c:53 +> #5 0x0000aaaae2624114 in qcrypto_tls_session_pull (opaque=0xaaaafa4a3d90, buf=0xaaaafa926dbb, len=5) at ../crypto/tlssession.c:89 +> #6 0x0000ffff7f63cd30 in _gnutls_stream_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:346 +> #7 _gnutls_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:426 +> #8 _gnutls_io_read_buffered (session=session@entry=0xaaaafa58b9d0, total=5, recv_type=recv_type@entry=4294967295, ms=0xfffff5d2317c) at buffers.c:581 +> #9 0x0000ffff7f632954 in recv_headers (ms=<optimized out>, record=0x1ee2a9fa78, htype=65535, type=2137262992, record_params=0xaaaafa4b71a0, session=0xaaaafa58b9d0) at record.c:1163 +> #10 _gnutls_recv_in_buffers (session=session@entry=0xaaaafa58b9d0, type=2137262992, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, ms=<optimized out>, ms@entry=0) at record.c:1302 +> #11 0x0000ffff7f63e568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaafa58b9d0, htype=htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, hsk=hsk@entry=0xfffff5d23308, optional=optional@entry=0) at buffers.c:1445 +> #12 0x0000ffff7f640b90 in _gnutls_recv_handshake (session=session@entry=0xaaaafa58b9d0, type=type@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, optional=optional@entry=0, buf=buf@entry=0x0) at handshake.c:1534 +> #13 0x0000ffff7f645f18 in handshake_server (session=<optimized out>) at handshake.c:3351 +> #14 gnutls_handshake (session=0xaaaafa58b9d0) at handshake.c:2742 +> #15 0x0000aaaae262513c in qcrypto_tls_session_handshake (session=0xaaaafa4a3d90, errp=0xfffff5d23478) at ../crypto/tlssession.c:493 +> #16 0x0000aaaae2631a40 in qio_channel_tls_handshake_task (ioc=0xaaaaf9c4c400, task=0xaaaafa70e600, context=0x0) at ../io/channel-tls.c:161 +> #17 0x0000aaaae2631c60 in qio_channel_tls_handshake (ioc=0xaaaaf9c4c400, func=0xaaaae20d4b58 <migration_tls_incoming_handshake>, opaque=0x0, destroy=0x0, context=0x0) at ../io/channel-tls.c:239 +> #18 0x0000aaaae20d4ca8 in migration_tls_channel_process_incoming (s=0xaaaaf9b2ef20, ioc=0xaaaaf998a800, errp=0xfffff5d23548) at ../migration/tls.c:103 +> #19 0x0000aaaae20f9f7c in migration_channel_process_incoming (ioc=0xaaaaf998a800) at ../migration/channel.c:42 +> #20 0x0000aaaae1f484a8 in socket_accept_incoming_migration (listener=0xffff64007a40, cioc=0xaaaaf998a800, opaque=0x0) at ../migration/socket.c:130 +> #21 0x0000aaaae2638570 in qio_net_listener_channel_func (ioc=0xaaaafa410600, condition=G_IO_IN, opaque=0xffff64007a40) at ../io/net-listener.c:54 +> #22 0x0000aaaae263ac4c in qio_channel_fd_source_dispatch (source=0xaaaafa81a380, callback=0xaaaae26384f8 <qio_net_listener_channel_func>, user_data=0xffff64007a40) at ../io/channel-watch.c:84 +> #23 0x0000ffff7fb13a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +> #24 0x0000aaaae287d29c in glib_pollfds_poll () at ../util/main-loop.c:221 +> #25 0x0000aaaae287d324 in os_host_main_loop_wait (timeout=571000000) at ../util/main-loop.c:244 +> #26 0x0000aaaae287d444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +> #27 0x0000aaaae24b9b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +> #28 0x0000aaaae1eb79e4 in main (argc=83, argv=0xfffff5d238c8, envp=0xfffff5d23b68) at ../softmmu/main.c:50 +> +> -- +> You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1902470 +> +> Title: +> migration with TLS-MultiFD is stuck when the dst-libvirtd service +> restarts +> +> Status in QEMU: +> New +> +> Bug description: +> hi, +> +> I found that the multi-channel TLS-handshake will be stuck when the +> dst-libvirtd restarts, both the src and dst sockets are blocked in +> recvmsg. In the meantime, live_migration thread is blocked in +> multifd_send_sync_main, so migration cannot be cancelled though src- +> libvirt has delivered the QMP command. +> +> Is there any way to exit migration when the multi-channel TLS- +> handshake is stuck? Does setting TLS-handshake timeout function take +> effect? +> +> The stack trace are as follows: +> +> =====src qemu-system-aar stack=====: +> #0 0x0000ffff87d6f28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +> #1 0x0000aaaae3817424 in qio_channel_socket_readv (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +> #2 0x0000aaaae380f468 in qio_channel_readv_full (ioc=0xaaaae9e30a30, iov=0xffffdb58e8a8, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +> #3 0x0000aaaae380f9e8 in qio_channel_read (ioc=0xaaaae9e30a30, buf=0xaaaaea204e9b "\026\003\001\001L\001", buflen=5, errp=0x0) at ../io/channel.c:217 +> #4 0x0000aaaae380e7d4 in qio_channel_tls_read_handler (buf=0xaaaaea204e9b "\026\003\001\001L\001", len=5, opaque=0xfffd38001190) at ../io/channel-tls.c:53 +> #5 0x0000aaaae3801114 in qcrypto_tls_session_pull (opaque=0xaaaae99d5700, buf=0xaaaaea204e9b, len=5) at ../crypto/tlssession.c:89 +> #6 0x0000ffff8822ed30 in _gnutls_stream_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:346 +> #7 _gnutls_read (ms=0xffffdb58eaac, pull_func=0xfffd38001870, size=5, bufel=<synthetic pointer>, session=0xaaaae983cd60) at buffers.c:426 +> #8 _gnutls_io_read_buffered (session=session@entry=0xaaaae983cd60, total=5, recv_type=recv_type@entry=4294967295, ms=0xffffdb58eaac) at buffers.c:581 +> #9 0x0000ffff88224954 in recv_headers (ms=<optimized out>, record=0xffff883cd000 <email address hidden>, htype=65535, type=2284006288, record_params=0xaaaae9e22a60, session=0xaaaae983cd60) at record.c:1163 +> #10 _gnutls_recv_in_buffers (session=session@entry=0xaaaae983cd60, type=2284006288, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, ms=<optimized out>, ms@entry=0) at record.c:1302 +> #11 0x0000ffff88230568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaae983cd60, htype=htype@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, hsk=hsk@entry=0xffffdb58ec38, optional=optional@entry=1) at buffers.c:1445 +> #12 0x0000ffff88232b90 in _gnutls_recv_handshake (session=session@entry=0xaaaae983cd60, type=type@entry=GNUTLS_HANDSHAKE_HELLO_RETRY_REQUEST, optional=optional@entry=1, buf=buf@entry=0x0) at handshake.c:1534 +> #13 0x0000ffff88235b40 in handshake_client (session=session@entry=0xaaaae983cd60) at handshake.c:2925 +> #14 0x0000ffff88237824 in gnutls_handshake (session=0xaaaae983cd60) at handshake.c:2739 +> #15 0x0000aaaae380213c in qcrypto_tls_session_handshake (session=0xaaaae99d5700, errp=0xffffdb58ee58) at ../crypto/tlssession.c:493 +> #16 0x0000aaaae380ea40 in qio_channel_tls_handshake_task (ioc=0xfffd38001190, task=0xaaaaea61d4e0, context=0x0) at ../io/channel-tls.c:161 +> #17 0x0000aaaae380ec60 in qio_channel_tls_handshake (ioc=0xfffd38001190, func=0xaaaae3394d20 <multifd_tls_outgoing_handshake>, opaque=0xaaaaea189c30, destroy=0x0, context=0x0) at ../io/channel-tls.c:239 +> #18 0x0000aaaae3394e78 in multifd_tls_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, errp=0xffffdb58ef28) at ../migration/multifd.c:782 +> #19 0x0000aaaae3394f30 in multifd_channel_connect (p=0xaaaaea189c30, ioc=0xaaaae9e30a30, error=0x0) at ../migration/multifd.c:804 +> #20 0x0000aaaae33950b8 in multifd_new_send_channel_async (task=0xaaaaea6855a0, opaque=0xaaaaea189c30) at ../migration/multifd.c:858 +> #21 0x0000aaaae3810cf8 in qio_task_complete (task=0xaaaaea6855a0) at ../io/task.c:197 +> #22 0x0000aaaae381096c in qio_task_thread_result (opaque=0xaaaaea6855a0) at ../io/task.c:112 +> #23 0x0000ffff88701df8 in ?? () from target:/usr/lib64/libglib-2.0.so.0 +> #24 0x0000ffff88705a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +> #25 0x0000aaaae3a5a29c in glib_pollfds_poll () at ../util/main-loop.c:221 +> #26 0x0000aaaae3a5a324 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:244 +> #27 0x0000aaaae3a5a444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +> #28 0x0000aaaae3696b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +> #29 0x0000aaaae30949e4 in main (argc=81, argv=0xffffdb58f2c8, envp=0xffffdb58f558) at ../softmmu/main.c:50 +> +> =====src live_migration stack=====: +> #0 0x0000ffff87d6a5d8 in pthread_cond_wait () from target:/usr/lib64/libpthread.so.0 +> #1 0x0000aaaae3a5f3ec in qemu_sem_wait (sem=0xaaaaea189d40) at ../util/qemu-thread-posix.c:328 +> #2 0x0000aaaae3394838 in multifd_send_sync_main (f=0xaaaae983f0e0) at ../migration/multifd.c:638 +> #3 0x0000aaaae37de310 in ram_save_setup (f=0xaaaae983f0e0, opaque=0xaaaae4198708 <ram_state>) at ../migration/ram.c:2588 +> #4 0x0000aaaae31cf7ac in qemu_savevm_state_setup (f=0xaaaae983f0e0) at ../migration/savevm.c:1176 +> #5 0x0000aaaae3248360 in migration_thread (opaque=0xaaaae9829f20) at ../migration/migration.c:3521 +> #6 0x0000aaaae3a5f8fc in qemu_thread_start (args=0xaaaaea513ee0) at ../util/qemu-thread-posix.c:521 +> #7 0x0000ffff87d647ac in ?? () from target:/usr/lib64/libpthread.so.0 +> #8 0x0000ffff87cba6ec in ?? () from target:/usr/lib64/libc.so.6 +> +> =====dst qemu-system-aar stack=====: +> #0 0x0000ffff7f17d28c in recvmsg () from target:/usr/lib64/libpthread.so.0 +> #1 0x0000aaaae263a424 in qio_channel_socket_readv (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel-socket.c:502 +> #2 0x0000aaaae2632468 in qio_channel_readv_full (ioc=0xaaaaf998a800, iov=0xfffff5d22f78, niov=1, fds=0x0, nfds=0x0, errp=0x0) at ../io/channel.c:66 +> #3 0x0000aaaae26329e8 in qio_channel_read (ioc=0xaaaaf998a800, buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., buflen=5, errp=0x0) at ../io/channel.c:217 +> #4 0x0000aaaae26317d4 in qio_channel_tls_read_handler (buf=0xaaaafa926dbb "q\024\335\365ȣ'\221,\\\357\246w\253\242ѠصI\247(N(K=\256\316DH\227QNf\371\"\271\017\226^\223\026\373\245z\255\227\025R.\244\205\254\002\031T\033\312:h\226\aݔ\204Ԫ\324\351K\341\365\247\032\354+\277\005O'*l\301cXx\340~?\346\b\324k\225\223D\276\252\376\257_0\036\223\022\006\212D|7h\257\226\300&n','\005zL\203M͆\023\213\237(o\272\025_\305s\372\362\351\002\367Ph\016\347\371E\n\030Y\340\002\r\362^&`\021\203}\353\324A\340ҳ(\207]\300l}h\026\037H\372\n=\"C\024\t\200\325\334&=\333>\212ƏE\214]_\372\264]"..., len=5, opaque=0xaaaaf9c4c400) at ../io/channel-tls.c:53 +> #5 0x0000aaaae2624114 in qcrypto_tls_session_pull (opaque=0xaaaafa4a3d90, buf=0xaaaafa926dbb, len=5) at ../crypto/tlssession.c:89 +> #6 0x0000ffff7f63cd30 in _gnutls_stream_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:346 +> #7 _gnutls_read (ms=0xfffff5d2317c, pull_func=0xaaaafa81a380, size=5, bufel=<synthetic pointer>, session=0xaaaafa58b9d0) at buffers.c:426 +> #8 _gnutls_io_read_buffered (session=session@entry=0xaaaafa58b9d0, total=5, recv_type=recv_type@entry=4294967295, ms=0xfffff5d2317c) at buffers.c:581 +> #9 0x0000ffff7f632954 in recv_headers (ms=<optimized out>, record=0x1ee2a9fa78, htype=65535, type=2137262992, record_params=0xaaaafa4b71a0, session=0xaaaafa58b9d0) at record.c:1163 +> #10 _gnutls_recv_in_buffers (session=session@entry=0xaaaafa58b9d0, type=2137262992, type@entry=GNUTLS_HANDSHAKE, htype=65535, htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, ms=<optimized out>, ms@entry=0) at record.c:1302 +> #11 0x0000ffff7f63e568 in _gnutls_handshake_io_recv_int (session=session@entry=0xaaaafa58b9d0, htype=htype@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, hsk=hsk@entry=0xfffff5d23308, optional=optional@entry=0) at buffers.c:1445 +> #12 0x0000ffff7f640b90 in _gnutls_recv_handshake (session=session@entry=0xaaaafa58b9d0, type=type@entry=GNUTLS_HANDSHAKE_CLIENT_HELLO, optional=optional@entry=0, buf=buf@entry=0x0) at handshake.c:1534 +> #13 0x0000ffff7f645f18 in handshake_server (session=<optimized out>) at handshake.c:3351 +> #14 gnutls_handshake (session=0xaaaafa58b9d0) at handshake.c:2742 +> #15 0x0000aaaae262513c in qcrypto_tls_session_handshake (session=0xaaaafa4a3d90, errp=0xfffff5d23478) at ../crypto/tlssession.c:493 +> #16 0x0000aaaae2631a40 in qio_channel_tls_handshake_task (ioc=0xaaaaf9c4c400, task=0xaaaafa70e600, context=0x0) at ../io/channel-tls.c:161 +> #17 0x0000aaaae2631c60 in qio_channel_tls_handshake (ioc=0xaaaaf9c4c400, func=0xaaaae20d4b58 <migration_tls_incoming_handshake>, opaque=0x0, destroy=0x0, context=0x0) at ../io/channel-tls.c:239 +> #18 0x0000aaaae20d4ca8 in migration_tls_channel_process_incoming (s=0xaaaaf9b2ef20, ioc=0xaaaaf998a800, errp=0xfffff5d23548) at ../migration/tls.c:103 +> #19 0x0000aaaae20f9f7c in migration_channel_process_incoming (ioc=0xaaaaf998a800) at ../migration/channel.c:42 +> #20 0x0000aaaae1f484a8 in socket_accept_incoming_migration (listener=0xffff64007a40, cioc=0xaaaaf998a800, opaque=0x0) at ../migration/socket.c:130 +> #21 0x0000aaaae2638570 in qio_net_listener_channel_func (ioc=0xaaaafa410600, condition=G_IO_IN, opaque=0xffff64007a40) at ../io/net-listener.c:54 +> #22 0x0000aaaae263ac4c in qio_channel_fd_source_dispatch (source=0xaaaafa81a380, callback=0xaaaae26384f8 <qio_net_listener_channel_func>, user_data=0xffff64007a40) at ../io/channel-watch.c:84 +> #23 0x0000ffff7fb13a7c in g_main_context_dispatch () from target:/usr/lib64/libglib-2.0.so.0 +> #24 0x0000aaaae287d29c in glib_pollfds_poll () at ../util/main-loop.c:221 +> #25 0x0000aaaae287d324 in os_host_main_loop_wait (timeout=571000000) at ../util/main-loop.c:244 +> #26 0x0000aaaae287d444 in main_loop_wait (nonblocking=0) at ../util/main-loop.c:520 +> #27 0x0000aaaae24b9b20 in qemu_main_loop () at ../softmmu/vl.c:1677 +> #28 0x0000aaaae1eb79e4 in main (argc=83, argv=0xfffff5d238c8, envp=0xfffff5d23b68) at ../softmmu/main.c:50 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1902470/+subscriptions +> +-- +Dr. David Alan Gilbert / <email address hidden> / Manchester, UK + + + +This looks to me like a significant implementation flaw in the QEMU code. Both src and dst QEMU appear to be running code from the main event loop, and they appear to be doing blocking I/O operations. This is very bad as we should never have anything running in the main event loop thread that is able to block on I/O. + +So to solve this something needs to be done to make sure the I/O is either non-blocking, or if it has to be blocking, then it needs to be offloaded to a background thread. + +this commit is sent and may fix this issue, waiting for review. +https://<email address hidden>/msg758017.html + + +this bug is fixed by commit(a1af605bd5ade1a6dd571f553a6746b97f3d6869), close the issue as fixed + diff --git a/results/classifier/118/unknown/1908513 b/results/classifier/118/unknown/1908513 new file mode 100644 index 00000000..46edff22 --- /dev/null +++ b/results/classifier/118/unknown/1908513 @@ -0,0 +1,98 @@ +hypervisor: 0.902 +KVM: 0.865 +ppc: 0.858 +vnc: 0.847 +user-level: 0.838 +TCG: 0.831 +i386: 0.831 +x86: 0.829 +peripherals: 0.818 +VMM: 0.817 +virtual: 0.796 +graphic: 0.784 +risc-v: 0.780 +performance: 0.777 +register: 0.775 +device: 0.759 +permissions: 0.758 +mistranslation: 0.756 +debug: 0.755 +semantic: 0.741 +assembly: 0.732 +files: 0.731 +architecture: 0.729 +boot: 0.727 +socket: 0.724 +kernel: 0.711 +PID: 0.709 +arm: 0.707 +network: 0.706 + +assertion failure in mptsas1068 emulator + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through mptsas1068 emulator. + +A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. + +This was found in version 5.2.0 (master) + + +qemu-system-i386: ../hw/scsi/mptsas.c:968: void mptsas_interrupt_status_write(MPTSASState *): Assertion +`s->intr_status & MPI_HIS_DOORBELL_INTERRUPT' failed. +[1] 16951 abort (core dumped) /home/cwmyung/prj/hyfuzz/src/qemu-5.2/build/qemu-system-i386 -m 512 -drive + +Program terminated with signal SIGABRT, Aborted. +#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. +[Current thread is 1 (Thread 0x7fc7d6023700 (LWP 23475))] +gdb-peda$ bt +#0 0x00007fc7efa13f47 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007fc7efa158b1 in __GI_abort () at abort.c:79 +#2 0x00007fc7efa0542a in __assert_fail_base (fmt=0x7fc7efb8ca38 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=assertion@entry=0x56439214d593 "s->intr_status & MPI_HIS_DOORBELL_INTERRUPT", file=file@entry=0x56439214d4a7 "../hw/scsi/mptsas.c", line=line@entry=0x3c8, function=function@entry=0x56439214d81c "void mptsas_interrupt_status_write(MPTSASState *)") at assert.c:92 +#3 0x00007fc7efa054a2 in __GI___assert_fail (assertion=0x56439214d593 "s->intr_status & MPI_HIS_DOORBELL_INTERRUPT", file=0x56439214d4a7 "../hw/scsi/mptsas.c", line=0x3c8, function=0x56439214d81c "void mptsas_interrupt_status_write(MPTSASState *)") at assert.c:101 +#4 0x0000564391a43963 in mptsas_interrupt_status_write (s=<optimized out>) at ../hw/scsi/mptsas.c:968 +#5 0x0000564391a43963 in mptsas_mmio_write (opaque=0x5643943dd5b0, addr=0x30, val=0x18000000, size=<optimized out>) at ../hw/scsi/mptsas.c:1052 +#6 0x0000564391e08798 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) + at ../softmmu/memory.c:491 +#7 0x0000564391e0858e in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=<optimized out>, attrs=...) at ../softmmu/memory.c:552 +#8 0x0000564391e0858e in memory_region_dispatch_write (mr=0x5643943ddea0, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#9 0x0000564391eff228 in io_writex (iotlbentry=<optimized out>, mmu_idx=<optimized out>, val=<optimized out>, addr=<optimized out>, retaddr=<optimized out>, op=<optimized out>, env=<optimized out>) + at ../accel/tcg/cputlb.c:1378 +#10 0x0000564391eff228 in store_helper (env=<optimized out>, addr=<optimized out>, val=<optimized out>, oi=<optimized out>, retaddr=<optimized out>, op=MO_32) at ../accel/tcg/cputlb.c:2397 +#11 0x0000564391eff228 in helper_le_stl_mmu (env=<optimized out>, addr=<optimized out>, val=0x2, oi=<optimized out>, retaddr=0x7fc78841b401) at ../accel/tcg/cputlb.c:2463 +#12 0x00007fc78841b401 in code_gen_buffer () +#13 0x0000564391dd0da0 in cpu_tb_exec (cpu=0x56439363e650, itb=<optimized out>) at ../accel/tcg/cpu-exec.c:178 +#14 0x0000564391dd19eb in cpu_loop_exec_tb (tb=<optimized out>, cpu=<optimized out>, last_tb=<optimized out>, tb_exit=<optimized out>) at ../accel/tcg/cpu-exec.c:658 +#15 0x0000564391dd19eb in cpu_exec (cpu=0x56439363e650) at ../accel/tcg/cpu-exec.c:771 +#16 0x0000564391e00b9f in tcg_cpu_exec (cpu=<optimized out>) at ../accel/tcg/tcg-cpus.c:243 +#17 0x0000564391e00b9f in tcg_cpu_thread_fn (arg=0x56439363e650) at ../accel/tcg/tcg-cpus.c:427 +#18 0x00005643920d8775 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521 +#19 0x00007fc7efdcd6db in start_thread (arg=0x7fc7d6023700) at pthread_create.c:463 + +To reproduce this issue, please run the QEMU with the following command line. + + +# To enable ASan option, please set configuration with the following command +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the following command line. +$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device mptsas1068,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img + +Please let me know if I can provide any further info. +Thank you. + +- Cheolwoo, Myung (Seoul National University) + + + +This still triggers with the current version from git master, marking as Confirmed + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/304 + + diff --git a/results/classifier/118/unknown/1911666 b/results/classifier/118/unknown/1911666 new file mode 100644 index 00000000..34be17f3 --- /dev/null +++ b/results/classifier/118/unknown/1911666 @@ -0,0 +1,108 @@ +user-level: 0.902 +VMM: 0.860 +register: 0.857 +hypervisor: 0.842 +mistranslation: 0.842 +x86: 0.841 +device: 0.838 +ppc: 0.834 +vnc: 0.829 +TCG: 0.827 +KVM: 0.821 +architecture: 0.815 +permissions: 0.814 +debug: 0.807 +assembly: 0.806 +i386: 0.794 +graphic: 0.790 +performance: 0.790 +virtual: 0.788 +semantic: 0.787 +peripherals: 0.786 +arm: 0.785 +kernel: 0.783 +PID: 0.772 +network: 0.760 +files: 0.752 +risc-v: 0.751 +boot: 0.727 +socket: 0.726 + +ZDI-CAN-10904: QEMU Plan 9 File System TOCTOU Privilege Escalation Vulnerability + +-- CVSS ----------------------------------------- + +7.5: AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H + +-- ABSTRACT ------------------------------------- + +Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: +QEMU - QEMU + +-- VULNERABILITY DETAILS ------------------------ + +Version tested:5.0.0-rc3 +Installer file:qemu-5.0.0-rc3.tar.xz +Platform tested:ubuntu 18.04 x64 desktop +Analysis Basically v9fs* functions called from guest kernel are executed under specific thread(I call it main thread later). But when it calls some file related system calls, qemu uses its own coroutine thread(worker thread). Then it returns(yield return) without waiting result of system call and start to execute next v9fs* function. + +In v9fsmarkfidsunreclaim() function, it stores fidlist member (head of singly linked list) to its stack. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L506 + +And if it uses coroutine, it restore fid_list from stack and restart whole loop. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L526 + +v9fsclunk() function calls clunkfid() which unlink fid from list, and free it. + + -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L2060-L2091 + +So if v9fsclunk() is called while v9fsmarkfidsunreclaim()'s coroutine is being executed, it restores "FREED" fidp from stack and use it. + +it can be reproduced with the qemu binary, which is given +it can also be reproduced with own ASAN build (5.0.0-rc3 and 4.2.0 are tested) + +../qemu-5.0.0-rc3/x86_64-softmmu/qemu-system-x86_64 -M pc -kernel ./bzImage -initrd ./rootfs.cpio -append "root=/dev/ram console=tty1 console=ttyS0 rdinit=/bin/sh" -nographic -enable-kvm -fsdev local,id=test_dev,path=/home/xxx/sandbox,security_model=none -device virtio-9p-pci,fsdev=test_dev,mount_tag=victim_tag + +$ ./do.sh +expected ASAN report is printed +the race is in coroutine, so the threads are the same one + +================================================================= + ==46645==ERROR: AddressSanitizer: heap-use-after-free on address 0x610000047948 at pc 0x5563d8c28f0f bp0 +READ of size 2 at 0x610000047948 thread T0 + + #0 0x5563d8c28f0e in v9fs_mark_fids_unreclaim hw/9pfs/9p.c:508 + #1 0x5563d8c3e9e3 in v9fs_remove hw/9pfs/9p.c:2988 + #2 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #3 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + + 0x610000047948 is located 8 bytes inside of 192-byte region [0x610000047940,0x610000047a00) freed by thread T0 here: + + #0 0x7fadafa5f7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) + #1 0x5563d8c27a60 in free_fid hw/9pfs/9p.c:371 + #2 0x5563d8c27fcc in put_fid hw/9pfs/9p.c:396 + #3 0x5563d8c37267 in v9fs_clunk hw/9pfs/9p.c:2085 + #4 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #5 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + +previously allocated by thread T0 here: + #0 0x7fadafa5fd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) + #1 0x7fadaf0c8b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10) + #2 0x5563d8c30ecc in v9fs_attach hw/9pfs/9p.c:1412 + #3 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 + #4 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) + + +This vulnerability was discovered by: + +Ryota Shiga(@Garyo) of Flatt Security working with Trend Micro Zero Day Initiative + +Requesting a CVE... + +'CVE-2021-20181' is assigned to this issue by Red Hat Inc. + +Fixed by commit 89fbea8737e ("9pfs: Fully restart unreclaim loop (CVE-2021-20181)"). + + diff --git a/results/classifier/118/unknown/1913510 b/results/classifier/118/unknown/1913510 new file mode 100644 index 00000000..c3410a4c --- /dev/null +++ b/results/classifier/118/unknown/1913510 @@ -0,0 +1,140 @@ +virtual: 0.803 +device: 0.796 +graphic: 0.786 +debug: 0.783 +permissions: 0.782 +register: 0.781 +user-level: 0.780 +peripherals: 0.777 +performance: 0.776 +architecture: 0.775 +assembly: 0.769 +semantic: 0.767 +arm: 0.763 +PID: 0.763 +files: 0.754 +socket: 0.735 +i386: 0.722 +boot: 0.722 +mistranslation: 0.715 +kernel: 0.714 +TCG: 0.713 +risc-v: 0.710 +KVM: 0.700 +hypervisor: 0.699 +x86: 0.690 +network: 0.688 +vnc: 0.677 +ppc: 0.673 +VMM: 0.671 + +[Fuzz] qemu-system-i386 virtio-mouse: Assertion in address_space_lduw_le_cached failed + +--[ Reproducer + +cat << EOF | ./build/qemu-system-i386 -machine q35,accel=qtest -nodefaults \ +-device virtio-mouse -display none -qtest stdio +outl 0xcf8 0x80000820 +outl 0xcfc 0xe0004000 +outl 0xcf8 0x80000804 +outb 0xcfc 0x02 +write 0xe000400c 0x4 0x003fe62e +write 0xe0004016 0x1 0x01 +write 0xe0004024 0x1 0x01 +write 0xe000401c 0x1 0x01 +write 0xe0007007 0x1 0x00 +write 0xe0004018 0x1 0x41 +write 0xe0007007 0x1 0x00 +EOF + + +--[ Output + +[I 1611805425.711054] OPENED +[R +0.040080] outl 0xcf8 0x80000820 +OK +[S +0.040117] OK +[R +0.040136] outl 0xcfc 0xe0004000 +OK +[S +0.040155] OK +[R +0.040165] outl 0xcf8 0x80000804 +OK +[S +0.040172] OK +[R +0.040184] outb 0xcfc 0x02 +OK +[S +0.040683] OK +[R +0.040702] write 0xe000400c 0x4 0x003fe62e +OK +[S +0.040735] OK +[R +0.040743] write 0xe0004016 0x1 0x01 +OK +[S +0.040748] OK +[R +0.040755] write 0xe0004024 0x1 0x01 +OK +[S +0.040760] OK +[R +0.040767] write 0xe000401c 0x1 0x01 +OK +[S +0.040785] OK +[R +0.040792] write 0xe0007007 0x1 0x00 +OK +[S +0.040810] OK +[R +0.040817] write 0xe0004018 0x1 0x41 +OK +[S +0.040822] OK +[R +0.040839] write 0xe0007007 0x1 0x00 +qemu-system-i386: /home/ubuntu/qemu/include/exec/memory_ldst_cached.h.inc:54: uint32_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. + + +-- [ Original ASAN report + +qemu-fuzz-i386: /home/ubuntu/qemu/include/exec/memory_ldst_cached.h.inc:54: uint32_t address_space_lduw_le_cached(MemoryRegionCache *, hwaddr, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +==3406167== ERROR: libFuzzer: deadly signal + #0 0x5644e4ae0f21 in __sanitizer_print_stack_trace (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2a47f21) + #1 0x5644e4a29fe8 in fuzzer::PrintStackTrace() (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2990fe8) + #2 0x5644e4a10023 in fuzzer::Fuzzer::CrashCallback() (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2977023) + #3 0x7f77e2a4b3bf (/lib/x86_64-linux-gnu/libpthread.so.0+0x153bf) + #4 0x7f77e285c18a in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618a) + #5 0x7f77e283b858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x25858) + #6 0x7f77e283b728 (/lib/x86_64-linux-gnu/libc.so.6+0x25728) + #7 0x7f77e284cf35 in __assert_fail (/lib/x86_64-linux-gnu/libc.so.6+0x36f35) + #8 0x5644e60051b2 in address_space_lduw_le_cached /home/ubuntu/qemu/include/exec/memory_ldst_cached.h.inc:54:5 + #9 0x5644e60051b2 in lduw_le_phys_cached /home/ubuntu/qemu/include/exec/memory_ldst_phys.h.inc:91:12 + #10 0x5644e60051b2 in virtio_lduw_phys_cached /home/ubuntu/qemu/include/hw/virtio/virtio-access.h:166:12 + #11 0x5644e5ff476d in vring_avail_ring /home/ubuntu/qemu/build/../hw/virtio/virtio.c:327:12 + #12 0x5644e5ff476d in vring_get_used_event /home/ubuntu/qemu/build/../hw/virtio/virtio.c:333:12 + #13 0x5644e5ff476d in virtio_split_should_notify /home/ubuntu/qemu/build/../hw/virtio/virtio.c:2473:35 + #14 0x5644e5ff476d in virtio_should_notify /home/ubuntu/qemu/build/../hw/virtio/virtio.c:2524:16 + #15 0x5644e5ff5556 in virtio_notify /home/ubuntu/qemu/build/../hw/virtio/virtio.c:2566:14 + #16 0x5644e5571d2a in virtio_input_handle_sts /home/ubuntu/qemu/build/../hw/input/virtio-input.c:100:5 + #17 0x5644e5ff20ec in virtio_queue_notify /home/ubuntu/qemu/build/../hw/virtio/virtio.c:2366:9 + #18 0x5644e60908fb in memory_region_write_accessor /home/ubuntu/qemu/build/../softmmu/memory.c:491:5 + #19 0x5644e6090363 in access_with_adjusted_size /home/ubuntu/qemu/build/../softmmu/memory.c:552:18 + #20 0x5644e608fbc0 in memory_region_dispatch_write /home/ubuntu/qemu/build/../softmmu/memory.c + #21 0x5644e5b97bc6 in flatview_write_continue /home/ubuntu/qemu/build/../softmmu/physmem.c:2759:23 + #22 0x5644e5b8d328 in flatview_write /home/ubuntu/qemu/build/../softmmu/physmem.c:2799:14 + #23 0x5644e5b8d328 in address_space_write /home/ubuntu/qemu/build/../softmmu/physmem.c:2891:18 + #24 0x5644e6018906 in qtest_process_command /home/ubuntu/qemu/build/../softmmu/qtest.c:539:13 + #25 0x5644e60159df in qtest_process_inbuf /home/ubuntu/qemu/build/../softmmu/qtest.c:797:9 + #26 0x5644e6015735 in qtest_server_inproc_recv /home/ubuntu/qemu/build/../softmmu/qtest.c:904:9 + #27 0x5644e667cf68 in qtest_sendf /home/ubuntu/qemu/build/../tests/qtest/libqtest.c:438:5 + #28 0x5644e667e54e in qtest_write /home/ubuntu/qemu/build/../tests/qtest/libqtest.c:1002:5 + #29 0x5644e667e54e in qtest_writeq /home/ubuntu/qemu/build/../tests/qtest/libqtest.c:1023:5 + #30 0x5644e4b1037e in __wrap_qtest_writeq /home/ubuntu/qemu/build/../tests/qtest/fuzz/qtest_wrappers.c:190:9 + #31 0x5644e4b1c33d in op_write /home/ubuntu/qemu/build/../tests/qtest/fuzz/generic_fuzz.c:479:13 + #32 0x5644e4b1a259 in generic_fuzz /home/ubuntu/qemu/build/../tests/qtest/fuzz/generic_fuzz.c:681:17 + #33 0x5644e4b0b333 in LLVMFuzzerTestOneInput /home/ubuntu/qemu/build/../tests/qtest/fuzz/fuzz.c:151:5 + #34 0x5644e4a11581 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2978581) + #35 0x5644e49fcc92 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2963c92) + #36 0x5644e4a02cfe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x2969cfe) + #37 0x5644e4a2a7c2 in main (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x29917c2) + #38 0x7f77e283d0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) + #39 0x5644e49d739d in _start (/home/ubuntu/qemu/build/qemu-fuzz-i386+0x293e39d) + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/302 + + diff --git a/results/classifier/118/unknown/1913914 b/results/classifier/118/unknown/1913914 new file mode 100644 index 00000000..b0810ece --- /dev/null +++ b/results/classifier/118/unknown/1913914 @@ -0,0 +1,90 @@ +hypervisor: 0.857 +register: 0.848 +virtual: 0.829 +peripherals: 0.827 +graphic: 0.822 +performance: 0.811 +x86: 0.802 +architecture: 0.778 +TCG: 0.777 +mistranslation: 0.773 +assembly: 0.767 +ppc: 0.765 +device: 0.765 +arm: 0.763 +debug: 0.755 +files: 0.754 +KVM: 0.753 +semantic: 0.752 +risc-v: 0.747 +kernel: 0.744 +permissions: 0.743 +i386: 0.734 +vnc: 0.726 +PID: 0.726 +boot: 0.716 +socket: 0.711 +user-level: 0.694 +VMM: 0.678 +network: 0.657 + +arm_gic: Abort in gic_clear_pending_sgi + +Reproducer: +cat << EOF | ./qemu-system-aarch64 \ +-machine virt,accel=qtest -qtest stdio +write 0x8000000 0x1 0x02 +write 0x8010000 0x1 0x03 +write 0x8010004 0x1 0x10 +write 0x8000f2f 0x1 0x0 +writel 0x8000f00 0x2065559 +write 0x8000d56 0x1 0x0 +readl 0x801000b +EOF + +Stacktrace: +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../qemu/hw/intc/arm_gic.c:173:28 in +../qemu/hw/intc/arm_gic.c:173:28: runtime error: load of misaligned address 0x6290000215c1 for type 'uint32_t' (aka 'unsigned int'), which requires 16 byte alignment +0x6290000215c1: note: pointer points here + 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 1c 00 00 80 60 00 00 00 00 00 00 00 + ^ +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../qemu/hw/intc/arm_gic.c:173:28 in +[R +0.117623] readl 0x8010015 +[R +0.117718] readl 0x801000b +qemu-fuzz-aarch64: ../qemu/hw/intc/arm_gic.c:580: uint32_t gic_clear_pending_sgi(GICState *, int, int): Assertion `s->sgi_pending[irq][cpu] != 0' failed. +==762== ERROR: libFuzzer: deadly signal + #0 0x563d4e2371f1 in __sanitizer_print_stack_trace (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x350d1f1) + #1 0x563d4e182348 in fuzzer::PrintStackTrace() (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x3458348) + #2 0x563d4e167493 in fuzzer::Fuzzer::CrashCallback() (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x343d493) + #3 0x7feabe05350f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1350f) + #4 0x7feabde8e080 in __libc_signal_restore_set /build/glibc-suXNNi/glibc-2.29/signal/../sysdeps/unix/sysv/linux/internal-signals.h:84:10 + #5 0x7feabde8e080 in raise /build/glibc-suXNNi/glibc-2.29/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 + #6 0x7feabde79534 in abort /build/glibc-suXNNi/glibc-2.29/stdlib/abort.c:79:7 + #7 0x7feabde7940e in __assert_fail_base /build/glibc-suXNNi/glibc-2.29/assert/assert.c:92:3 + #8 0x7feabde86b91 in __assert_fail /build/glibc-suXNNi/glibc-2.29/assert/assert.c:101:3 + #9 0x563d4eba2a3c in gic_clear_pending_sgi /home/alxndr/build-asan/../qemu/hw/intc/arm_gic.c:580:9 + #10 0x563d4eba2a3c in gic_acknowledge_irq /home/alxndr/build-asan/../qemu/hw/intc/arm_gic.c:630:19 + #11 0x563d4ebb4ca4 in gic_cpu_read /home/alxndr/build-asan/../qemu/hw/intc/arm_gic.c:1615:17 + #12 0x563d4ebab538 in gic_thiscpu_read /home/alxndr/build-asan/../qemu/hw/intc/arm_gic.c:1771:12 + #13 0x563d5029ec2d in memory_region_read_with_attrs_accessor /home/alxndr/build-asan/../qemu/softmmu/memory.c:464:9 + #14 0x563d502705f3 in access_with_adjusted_size /home/alxndr/build-asan/../qemu/softmmu/memory.c:552:18 + #15 0x563d5026eb44 in memory_region_dispatch_read1 /home/alxndr/build-asan/../qemu/softmmu/memory.c + #16 0x563d5026eb44 in memory_region_dispatch_read /home/alxndr/build-asan/../qemu/softmmu/memory.c:1449:9 + #17 0x563d5048c5bf in flatview_read_continue /home/alxndr/build-asan/../qemu/softmmu/physmem.c:2822:23 + #18 0x563d504a9a9b in address_space_read /home/alxndr/qemu/include/exec/memory.h:2484:26 + #19 0x563d504a9a9b in qtest_process_command /home/alxndr/build-asan/../qemu/softmmu/qtest.c:568:13 + #20 0x563d504a497f in qtest_process_inbuf /home/alxndr/build-asan/../qemu/softmmu/qtest.c:797:9 + #21 0x563d504a46d5 in qtest_server_inproc_recv /home/alxndr/build-asan/../qemu/softmmu/qtest.c:904:9 + #22 0x563d50ce5cc8 in qtest_sendf /home/alxndr/build-asan/../qemu/tests/qtest/libqtest.c:438:5 + #23 0x563d50ce73a3 in qtest_read /home/alxndr/build-asan/../qemu/tests/qtest/libqtest.c:1032:5 + #24 0x563d4e264499 in __wrap_qtest_readl /home/alxndr/build-asan/../qemu/tests/qtest/fuzz/qtest_wrappers.c:138:16 + #25 0x563d4e26ee5b in op_read /home/alxndr/build-asan/../qemu/tests/qtest/fuzz/generic_fuzz.c:432:13 + #26 0x563d4e26dc46 in generic_fuzz /home/alxndr/build-asan/../qemu/tests/qtest/fuzz/generic_fuzz.c:681:17 + #27 0x563d4e261283 in LLVMFuzzerTestOneInput /home/alxndr/build-asan/../qemu/tests/qtest/fuzz/fuzz.c:151:5 + #28 0x563d4e168b51 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x343eb51) + #29 0x563d4e1542c2 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x342a2c2) + #30 0x563d4e159d76 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x342fd76) + #31 0x563d4e182a32 in main (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x3458a32) + #32 0x7feabde7abba in __libc_start_main /build/glibc-suXNNi/glibc-2.29/csu/../csu/libc-start.c:308:16 + #33 0x563d4e12e989 in _start (/home/alxndr/build-asan/qemu-fuzz-aarch64+0x3404989) + diff --git a/results/classifier/118/unknown/1913919 b/results/classifier/118/unknown/1913919 new file mode 100644 index 00000000..db5f3eed --- /dev/null +++ b/results/classifier/118/unknown/1913919 @@ -0,0 +1,188 @@ +virtual: 0.928 +graphic: 0.902 +hypervisor: 0.890 +user-level: 0.883 +performance: 0.883 +semantic: 0.881 +register: 0.881 +mistranslation: 0.881 +architecture: 0.860 +peripherals: 0.859 +debug: 0.859 +arm: 0.858 +permissions: 0.858 +risc-v: 0.851 +files: 0.847 +device: 0.844 +assembly: 0.833 +TCG: 0.829 +boot: 0.827 +vnc: 0.824 +socket: 0.823 +x86: 0.819 +PID: 0.819 +kernel: 0.814 +KVM: 0.807 +ppc: 0.800 +i386: 0.799 +VMM: 0.796 +network: 0.785 + +Heap-buffer-overflow in sdhci_write_dataport + +Reproducer: +cat << EOF | ./qemu-system-aarch64 -qtest stdio \ +-machine raspi3b,accel=qtest -m 1G +write 0x3f30002c 0x1 0x25 +write 0x3f300004 0x1 0x01 +write 0x3f300006 0x1 0xc0 +write 0x3f30000c 0x1 0x22 +write 0x3f30000e 0x1 0x20 +write 0x3f30000f 0x1 0x0 +write 0x3f300000 0x1 0x48 +write 0x3f300003 0x1 0x0 +write 0x3f300005 0x1 0x14 +write 0x3f300007 0x1 0x10 +write 0x3f30000c 0x1 0x32 +write 0x3f30000f 0x1 0x0 +write 0x3f300001 0x1 0x00 +write 0x3f300002 0x1 0x30 +write 0x3f300003 0x1 0x3f +EOF + +Stacktrace: +==654080==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000017b80 at pc 0x562988348719 bp 0x7fffd26552d0 sp 0x7fffd26552c8 +WRITE of size 1 at 0x619000017b80 thread T0 + #0 0x562988348718 in sdhci_write_dataport /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:560:39 + #1 0x562988348718 in sdhci_write /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:1172:13 + #2 0x5629890591fe in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 + #3 0x562989058bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 + #4 0x562989058467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c + #5 0x5629893e8ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 + #6 0x5629893de71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 + #7 0x5629893de71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 + #8 0x562988334d9c in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:88:12 + #9 0x562988334d9c in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:127:12 + #10 0x562988334d9c in dma_memory_write /home/alxndr/Development/qemu/include/sysemu/dma.h:163:12 + #11 0x562988334d9c in sdhci_sdma_transfer_multi_blocks /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:617:13 + #12 0x56298834427f in sdhci_write /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:1129:17 + #13 0x5629890591fe in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 + #14 0x562989058bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 + #15 0x562989058467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c + #16 0x5629893e8ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 + #17 0x5629893de71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 + #18 0x5629893de71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 + #19 0x56298904ad35 in qtest_process_command /home/alxndr/Development/qemu/build/../softmmu/qtest.c:654:9 + #20 0x562989043b97 in qtest_process_inbuf /home/alxndr/Development/qemu/build/../softmmu/qtest.c:797:9 + #21 0x562989894286 in fd_chr_read /home/alxndr/Development/qemu/build/../chardev/char-fd.c:68:9 + #22 0x7f535645baae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) + #23 0x562989eef363 in glib_pollfds_poll /home/alxndr/Development/qemu/build/../util/main-loop.c:232:9 + #24 0x562989eef363 in os_host_main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:255:5 + #25 0x562989eef363 in main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:531:11 + #26 0x562988faa599 in qemu_main_loop /home/alxndr/Development/qemu/build/../softmmu/runstate.c:721:9 + #27 0x5629872371fd in main /home/alxndr/Development/qemu/build/../softmmu/main.c:50:5 + #28 0x7f5355f00cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 + #29 0x56298718abc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) + +0x619000017b80 is located 0 bytes to the right of 1024-byte region [0x619000017780,0x619000017b80) +allocated by thread T0 here: + #0 0x562987204db2 in calloc (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x33cadb2) + #1 0x7f5356461ae0 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57ae0) + #2 0x56298834a187 in sdhci_sysbus_realize /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:1469:5 + #3 0x56298987fe77 in device_set_realized /home/alxndr/Development/qemu/build/../hw/core/qdev.c:761:13 + #4 0x5629898153b5 in property_set_bool /home/alxndr/Development/qemu/build/../qom/object.c:2255:5 + +Can you still reproduce this issue with the latest git version of QEMU? ... for me, it does not crash anymore. + +There were a few patches some months ago that fixed the sdhci issues, +and OSS-Fuzz said that all of the heap-overflows that it has seen in +sdhci have been fixed. +-Alex + +On 210610 1544, Thomas Huth wrote: +> Can you still reproduce this issue with the latest git version of QEMU? +> ... for me, it does not crash anymore. +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1913919 +> +> Title: +> Heap-buffer-overflow in sdhci_write_dataport +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> Reproducer: +> cat << EOF | ./qemu-system-aarch64 -qtest stdio \ +> -machine raspi3b,accel=qtest -m 1G +> write 0x3f30002c 0x1 0x25 +> write 0x3f300004 0x1 0x01 +> write 0x3f300006 0x1 0xc0 +> write 0x3f30000c 0x1 0x22 +> write 0x3f30000e 0x1 0x20 +> write 0x3f30000f 0x1 0x0 +> write 0x3f300000 0x1 0x48 +> write 0x3f300003 0x1 0x0 +> write 0x3f300005 0x1 0x14 +> write 0x3f300007 0x1 0x10 +> write 0x3f30000c 0x1 0x32 +> write 0x3f30000f 0x1 0x0 +> write 0x3f300001 0x1 0x00 +> write 0x3f300002 0x1 0x30 +> write 0x3f300003 0x1 0x3f +> EOF +> +> Stacktrace: +> ==654080==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000017b80 at pc 0x562988348719 bp 0x7fffd26552d0 sp 0x7fffd26552c8 +> WRITE of size 1 at 0x619000017b80 thread T0 +> #0 0x562988348718 in sdhci_write_dataport /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:560:39 +> #1 0x562988348718 in sdhci_write /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:1172:13 +> #2 0x5629890591fe in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 +> #3 0x562989058bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 +> #4 0x562989058467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c +> #5 0x5629893e8ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 +> #6 0x5629893de71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 +> #7 0x5629893de71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 +> #8 0x562988334d9c in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:88:12 +> #9 0x562988334d9c in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:127:12 +> #10 0x562988334d9c in dma_memory_write /home/alxndr/Development/qemu/include/sysemu/dma.h:163:12 +> #11 0x562988334d9c in sdhci_sdma_transfer_multi_blocks /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:617:13 +> #12 0x56298834427f in sdhci_write /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:1129:17 +> #13 0x5629890591fe in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 +> #14 0x562989058bfb in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 +> #15 0x562989058467 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c +> #16 0x5629893e8ffb in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2759:23 +> #17 0x5629893de71b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2799:14 +> #18 0x5629893de71b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2891:18 +> #19 0x56298904ad35 in qtest_process_command /home/alxndr/Development/qemu/build/../softmmu/qtest.c:654:9 +> #20 0x562989043b97 in qtest_process_inbuf /home/alxndr/Development/qemu/build/../softmmu/qtest.c:797:9 +> #21 0x562989894286 in fd_chr_read /home/alxndr/Development/qemu/build/../chardev/char-fd.c:68:9 +> #22 0x7f535645baae in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51aae) +> #23 0x562989eef363 in glib_pollfds_poll /home/alxndr/Development/qemu/build/../util/main-loop.c:232:9 +> #24 0x562989eef363 in os_host_main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:255:5 +> #25 0x562989eef363 in main_loop_wait /home/alxndr/Development/qemu/build/../util/main-loop.c:531:11 +> #26 0x562988faa599 in qemu_main_loop /home/alxndr/Development/qemu/build/../softmmu/runstate.c:721:9 +> #27 0x5629872371fd in main /home/alxndr/Development/qemu/build/../softmmu/main.c:50:5 +> #28 0x7f5355f00cc9 in __libc_start_main csu/../csu/libc-start.c:308:16 +> #29 0x56298718abc9 in _start (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x3350bc9) +> +> 0x619000017b80 is located 0 bytes to the right of 1024-byte region [0x619000017780,0x619000017b80) +> allocated by thread T0 here: +> #0 0x562987204db2 in calloc (/home/alxndr/Development/qemu/build/qemu-system-aarch64+0x33cadb2) +> #1 0x7f5356461ae0 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57ae0) +> #2 0x56298834a187 in sdhci_sysbus_realize /home/alxndr/Development/qemu/build/../hw/sd/sdhci.c:1469:5 +> #3 0x56298987fe77 in device_set_realized /home/alxndr/Development/qemu/build/../hw/core/qdev.c:761:13 +> #4 0x5629898153b5 in property_set_bool /home/alxndr/Development/qemu/build/../qom/object.c:2255:5 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1913919/+subscriptions + + +Ok, thanks for confirmation, then let's close this ticket here. If you encounter such a problem again, please open a new ticket in the new gitlab issue tracker. + diff --git a/results/classifier/118/unknown/1914236 b/results/classifier/118/unknown/1914236 new file mode 100644 index 00000000..8caa9c20 --- /dev/null +++ b/results/classifier/118/unknown/1914236 @@ -0,0 +1,136 @@ +debug: 0.844 +user-level: 0.805 +ppc: 0.803 +peripherals: 0.788 +x86: 0.787 +permissions: 0.786 +virtual: 0.785 +risc-v: 0.779 +mistranslation: 0.774 +VMM: 0.772 +arm: 0.771 +i386: 0.769 +performance: 0.767 +KVM: 0.764 +vnc: 0.762 +network: 0.760 +TCG: 0.757 +architecture: 0.746 +device: 0.740 +graphic: 0.739 +semantic: 0.738 +hypervisor: 0.733 +register: 0.719 +assembly: 0.711 +PID: 0.696 +files: 0.679 +socket: 0.659 +kernel: 0.649 +boot: 0.646 + +QEMU: scsi: use-after-free in mptsas_process_scsi_io_request() of mptsas1068 emulator + +* Cheolwoo Myung of Seoul National University reported a use-after-free issue in the SCSI Megaraid + emulator of the QEMU. + +* It occurs while handling mptsas_process_scsi_io_request(), as it does not + check a list in s->pending. + +* This was found in version 5.2.0 (master) + +==31872==ERROR: AddressSanitizer: heap-use-after-free on address +0x60c000107568 at pc 0x564514950c7c bp 0x7fff524ef4b0 sp 0x7fff524ef4a0 WRITE of size 8 at 0x60c000107568 thread T0 +#0 0x564514950c7b in mptsas_process_scsi_io_request ../hw/scsi/mptsas.c:306 +#1 0x564514950c7b in mptsas_fetch_request ../hw/scsi/mptsas.c:775 +#2 0x564514950c7b in mptsas_fetch_requests ../hw/scsi/mptsas.c:790 +#3 0x56451585c25d in aio_bh_poll ../util/async.c:164 +#4 0x5645158d7e7d in aio_dispatch ../util/aio-posix.c:381 +#5 0x56451585be2d in aio_ctx_dispatch ../util/async.c:306 +#6 0x7f1cc8af4416 in g_main_context_dispatch +(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c416) +#7 0x56451583f059 in glib_pollfds_poll ../util/main-loop.c:221 +#8 0x56451583f059 in os_host_main_loop_wait ../util/main-loop.c:244 +#9 0x56451583f059 in main_loop_wait ../util/main-loop.c:520 +#10 0x56451536b181 in qemu_main_loop ../softmmu/vl.c:1537 +#11 0x5645143ddd3d in main ../softmmu/main.c:50 +#12 0x7f1cc2650b96 in __libc_start_main +(/lib/x86_64-linux-gnu/libc.so.6+0x21b96) +#13 0x5645143eece9 in _start +(/home/cwmyung/prj/hyfuzz/src/qemu-repro/build/qemu-system-i386+0x1d55ce9) + +0x60c000107568 is located 104 bytes inside of 120-byte region +[0x60c000107500,0x60c000107578) +freed by thread T0 here: +#0 0x7f1cca9777a8 in __interceptor_free +(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) +#1 0x56451495008b in mptsas_process_scsi_io_request ../hw/scsi/mptsas.c:358 +#2 0x56451495008b in mptsas_fetch_request ../hw/scsi/mptsas.c:775 +#3 0x56451495008b in mptsas_fetch_requests ../hw/scsi/mptsas.c:790 +#4 0x7fff524ef8bf (<unknown module>) + +previously allocated by thread T0 here: +#0 0x7f1cca977d28 in __interceptor_calloc +(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) +#1 0x7f1cc8af9b10 in g_malloc0 +(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10) +#2 0x7fff524ef8bf (<unknown module>) + +SUMMARY: AddressSanitizer: heap-use-after-free ../hw/scsi/mptsas.c:306 +in mptsas_process_scsi_io_request +Shadow bytes around the buggy address: +0x0c1880018e50: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd +0x0c1880018e60: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa +0x0c1880018e70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd +0x0c1880018e80: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd +0x0c1880018e90: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa +=>0x0c1880018ea0: fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fa +0x0c1880018eb0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 +0x0c1880018ec0: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa +0x0c1880018ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +0x0c1880018ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +0x0c1880018ef0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa +Shadow byte legend (one shadow byte represents 8 application bytes): +Addressable: 00 +Partially addressable: 01 02 03 04 05 06 07 +Heap left redzone: fa +Freed heap region: fd +Stack left redzone: f1 +Stack mid redzone: f2 +Stack right redzone: f3 +Stack after return: f5 +Stack use after scope: f8 +Global redzone: f9 +Global init order: f6 +Poisoned by user: f7 +Container overflow: fc +Array cookie: ac +Intra object redzone: bb +ASan internal: fe +Left alloca redzone: ca +Right alloca redzone: cb +==31872==ABORTING + + +To reproduce this issue, please run the QEMU with the following command +line. + + +# To enable ASan option, please set configuration with the following command +$ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers +$ make + +# To reproduce this issue, please run the QEMU process with the +following command line. +$ ./qemu-system-i386 -m 512 -drive +file=./hyfuzz.img,index=0,media=disk,format=raw -device +mptsas1068,id=scsi -device scsi-hd,drive=SysDisk -drive +id=SysDisk,if=none,file=./disk.img + +CVE-2021-3392 assigned by Red Hat In.c + +Upstream patch + -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00488.html + +Upstream commit: +https://git.qemu.org/?p=qemu.git;a=commit;h=3791642c8d60029adf9b00bcb4e34d7d8a1aea4d + diff --git a/results/classifier/118/unknown/1914638 b/results/classifier/118/unknown/1914638 new file mode 100644 index 00000000..d7811866 --- /dev/null +++ b/results/classifier/118/unknown/1914638 @@ -0,0 +1,616 @@ +peripherals: 0.877 +risc-v: 0.877 +register: 0.869 +VMM: 0.859 +mistranslation: 0.857 +vnc: 0.852 +TCG: 0.847 +user-level: 0.846 +ppc: 0.840 +KVM: 0.820 +i386: 0.820 +permissions: 0.816 +hypervisor: 0.811 +virtual: 0.801 +device: 0.799 +x86: 0.797 +PID: 0.793 +debug: 0.789 +assembly: 0.779 +semantic: 0.779 +performance: 0.773 +arm: 0.771 +socket: 0.767 +files: 0.760 +architecture: 0.759 +boot: 0.757 +graphic: 0.746 +kernel: 0.722 +network: 0.712 + +[OSS-Fuzz] Issue 30219: Global-buffer-overflow in mode_sense_page + +== Reproducer (build with --enable-sanitizers) == + +cat << EOF | ./qemu-system-i386 -machine q35 -nodefaults \ +-device megasas -device scsi-cd,drive=null0 \ +-blockdev driver=null-co,read-zeroes=on,node-name=null0 \ +-nographic -qtest stdio +outl 0xcf8 0x80000818 +outl 0xcfc 0xc000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x7 +write 0x0 0x1 0x03 +write 0x7 0x1 0x3f +write 0x10 0x1 0x03 +write 0x20 0x1 0x55 +write 0x21 0x1 0x10 +write 0x28 0x1 0x10 +write 0x30 0x1 0xff +write 0x31 0x1 0xff +write 0x32 0x1 0xff +write 0x33 0x1 0xff +write 0x34 0x1 0xff +write 0x35 0x1 0xff +write 0x36 0x1 0xff +write 0x37 0x1 0xff +write 0x3b 0x1 0x10 +write 0x43 0x1 0x10 +write 0x44 0x1 0x10 +write 0x4f 0x1 0x10 +write 0x53 0x1 0x10 +write 0x5b 0x1 0x10 +write 0x5f 0x1 0x10 +write 0x67 0x1 0x10 +write 0x6b 0x1 0x10 +write 0x73 0x1 0x10 +write 0x75 0x1 0x10 +write 0x7d 0x1 0x10 +write 0x83 0x1 0x10 +write 0x8b 0x1 0x10 +write 0x8f 0x1 0x10 +write 0x97 0x1 0x10 +write 0x9b 0x1 0x10 +write 0xa3 0x1 0x03 +write 0xa6 0x1 0x10 +write 0xae 0x1 0x10 +write 0xb3 0x1 0x10 +write 0xbb 0x1 0x10 +write 0xbf 0x1 0x10 +write 0xc7 0x1 0x10 +write 0xca 0x1 0x10 +write 0xd3 0x1 0x06 +write 0xd7 0x1 0x10 +write 0xdf 0x1 0x10 +write 0xe3 0x1 0x06 +write 0xeb 0x1 0x01 +write 0xef 0x1 0x10 +write 0xf7 0x1 0x10 +write 0xfb 0x1 0x10 +write 0x103 0x1 0x20 +write 0x107 0x1 0x10 +write 0x10f 0x1 0x10 +write 0x113 0x1 0x10 +write 0x11b 0x1 0x10 +write 0x11f 0x1 0x10 +write 0x127 0x1 0x10 +write 0x12b 0x1 0x10 +write 0x130 0x1 0x10 +write 0x137 0x1 0x10 +write 0x13f 0x1 0x40 +write 0x141 0x1 0x10 +write 0x14b 0x1 0x10 +write 0x14f 0x1 0x10 +write 0x157 0x1 0x10 +write 0x15b 0x1 0x10 +write 0x161 0x1 0x10 +write 0x167 0x1 0x03 +write 0x16f 0x1 0x06 +write 0x172 0x1 0x10 +write 0x17b 0x1 0x10 +write 0x17f 0x1 0x10 +write 0x187 0x1 0x10 +write 0x18b 0x1 0x10 +write 0x192 0x1 0x10 +write 0x197 0x1 0x06 +write 0x19f 0x1 0x20 +write 0x1a3 0x1 0x10 +write 0x1ab 0x1 0x40 +write 0x1af 0x1 0x01 +write 0x1b7 0x1 0x10 +write 0x1bb 0x1 0x20 +write 0x1c3 0x1 0x10 +write 0x1c7 0x1 0x20 +write 0x1cc 0x1 0x10 +write 0x1d3 0x1 0x10 +write 0x1db 0x1 0x10 +write 0x1df 0x1 0x10 +write 0x1e7 0x1 0x10 +write 0x1eb 0x1 0x10 +write 0x1f3 0x1 0x10 +write 0x1f4 0x1 0x10 +write 0x1fd 0x1 0x10 +write 0x203 0x1 0x40 +write 0x20b 0x1 0x10 +write 0x20f 0x1 0x10 +write 0x217 0x1 0x10 +write 0x21b 0x1 0x10 +write 0x223 0x1 0x10 +write 0x225 0x1 0x10 +write 0x22e 0x1 0x10 +write 0x233 0x1 0x06 +write 0x23b 0x1 0x10 +write 0x23f 0x1 0x10 +write 0x247 0x1 0x10 +write 0x24b 0x1 0x10 +write 0x252 0x1 0x10 +write 0x256 0x1 0x10 +write 0x25f 0x1 0x10 +write 0x263 0x1 0x20 +write 0x26b 0x1 0x06 +write 0x26f 0x1 0x40 +write 0x277 0x1 0x10 +write 0x27b 0x1 0x10 +write 0x283 0x1 0x10 +write 0x287 0x1 0x10 +write 0x28f 0x1 0x10 +write 0x290 0x1 0x10 +write 0x29b 0x1 0x10 +write 0x29f 0x1 0x10 +write 0x2a7 0x1 0x10 +write 0x2ab 0x1 0x10 +write 0x2b3 0x1 0x10 +write 0x2b7 0x1 0x10 +write 0x2bf 0x1 0x10 +write 0x2c1 0x1 0x10 +write 0x2c9 0x1 0x10 +write 0x2cf 0x1 0x10 +write 0x2d7 0x1 0x10 +write 0x2db 0x1 0x10 +write 0x2e3 0x1 0x10 +write 0x2e7 0x1 0x10 +write 0x2ef 0x1 0x03 +write 0x2f2 0x1 0x10 +write 0x2fa 0x1 0x10 +write 0x2ff 0x1 0x10 +write 0x307 0x1 0x10 +write 0x30b 0x1 0x10 +write 0x313 0x1 0x10 +write 0x316 0x1 0x10 +write 0x31f 0x1 0x06 +write 0x323 0x1 0x10 +outb 0xc040 0x0 +EOF + +=== Stack Trace === +==1025760==ERROR: AddressSanitizer: global-buffer-overflow on address 0x558f557253fc at pc 0x558f549ab376 bp +0x7ffd436e9770 sp 0x7ffd436e9768 +READ of size 4 at 0x558f557253fc thread T0 +SCARINESS: 17 (4-byte-read-global-buffer-overflow) +#0 0x558f549ab375 in mode_sense_page /src/qemu/hw/scsi/scsi-disk.c:1104:10 +#1 0x558f549afd86 in scsi_disk_check_mode_select /src/qemu/hw/scsi/scsi-disk.c:1447:11 +#2 0x558f549af9a6 in mode_select_pages /src/qemu/hw/scsi/scsi-disk.c:1515:17 +#3 0x558f549ae593 in scsi_disk_emulate_mode_select /src/qemu/hw/scsi/scsi-disk.c:1570:13 +#4 0x558f549a56e9 in scsi_disk_emulate_write_data /src/qemu/hw/scsi/scsi-disk.c:1861:9 +#5 0x558f548b9b49 in scsi_req_continue /src/qemu/hw/scsi/scsi-bus.c:0 +#6 0x558f548b9fc4 in scsi_req_data /src/qemu/hw/scsi/scsi-bus.c:1427:5 +#7 0x558f549a5554 in scsi_disk_emulate_write_data /src/qemu/hw/scsi/scsi-disk.c:1853:9 +#8 0x558f548b9b49 in scsi_req_continue /src/qemu/hw/scsi/scsi-bus.c:0 +#9 0x558f54ac7cf6 in megasas_enqueue_req /src/qemu/hw/scsi/megasas.c:1660:9 +#10 0x558f54ab6e09 in megasas_handle_scsi /src/qemu/hw/scsi/megasas.c:1735:5 +#11 0x558f54ab3083 in megasas_handle_frame /src/qemu/hw/scsi/megasas.c:1974:24 +#12 0x558f54ab1c8b in megasas_mmio_write /src/qemu/hw/scsi/megasas.c:2131:9 +#13 0x558f54acc784 in megasas_port_write /src/qemu/hw/scsi/megasas.c:2182:5 +#14 0x558f54f78d57 in memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +#15 0x558f54f78be2 in access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +#16 0x558f54f78441 in memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +#17 0x558f550d5627 in flatview_write_continue /src/qemu/softmmu/physmem.c:2763:23 +#18 0x558f550d02ac in flatview_write /src/qemu/softmmu/physmem.c:2803:14 +#19 0x558f550d00c7 in address_space_write /src/qemu/softmmu/physmem.c:2895:18 +#20 0x558f5506c4ff in cpu_outb /src/qemu/softmmu/ioport.c:60:5 + ++CC Paolo and Fam + +scsi-disk.c:1092 static const int mode_sense_valid[0x3f] = +... +scsi-disk.c:1488 page = p[0] & 0x3f; + +OSS-Fuzz found this same crash for virtio-scsi, however, since the +reproducer involved a double-fetch, I don't have a simple QTest +reproducer + +On 210204 1728, Alexander Bulekov wrote: +> Public bug reported: +> +> == Reproducer (build with --enable-sanitizers) == +> +> cat << EOF | ./qemu-system-i386 -machine q35 -nodefaults \ +> -device megasas -device scsi-cd,drive=null0 \ +> -blockdev driver=null-co,read-zeroes=on,node-name=null0 \ +> -nographic -qtest stdio +> outl 0xcf8 0x80000818 +> outl 0xcfc 0xc000 +> outl 0xcf8 0x80000804 +> outw 0xcfc 0x7 +> write 0x0 0x1 0x03 +> write 0x7 0x1 0x3f +> write 0x10 0x1 0x03 +> write 0x20 0x1 0x55 +> write 0x21 0x1 0x10 +> write 0x28 0x1 0x10 +> write 0x30 0x1 0xff +> write 0x31 0x1 0xff +> write 0x32 0x1 0xff +> write 0x33 0x1 0xff +> write 0x34 0x1 0xff +> write 0x35 0x1 0xff +> write 0x36 0x1 0xff +> write 0x37 0x1 0xff +> write 0x3b 0x1 0x10 +> write 0x43 0x1 0x10 +> write 0x44 0x1 0x10 +> write 0x4f 0x1 0x10 +> write 0x53 0x1 0x10 +> write 0x5b 0x1 0x10 +> write 0x5f 0x1 0x10 +> write 0x67 0x1 0x10 +> write 0x6b 0x1 0x10 +> write 0x73 0x1 0x10 +> write 0x75 0x1 0x10 +> write 0x7d 0x1 0x10 +> write 0x83 0x1 0x10 +> write 0x8b 0x1 0x10 +> write 0x8f 0x1 0x10 +> write 0x97 0x1 0x10 +> write 0x9b 0x1 0x10 +> write 0xa3 0x1 0x03 +> write 0xa6 0x1 0x10 +> write 0xae 0x1 0x10 +> write 0xb3 0x1 0x10 +> write 0xbb 0x1 0x10 +> write 0xbf 0x1 0x10 +> write 0xc7 0x1 0x10 +> write 0xca 0x1 0x10 +> write 0xd3 0x1 0x06 +> write 0xd7 0x1 0x10 +> write 0xdf 0x1 0x10 +> write 0xe3 0x1 0x06 +> write 0xeb 0x1 0x01 +> write 0xef 0x1 0x10 +> write 0xf7 0x1 0x10 +> write 0xfb 0x1 0x10 +> write 0x103 0x1 0x20 +> write 0x107 0x1 0x10 +> write 0x10f 0x1 0x10 +> write 0x113 0x1 0x10 +> write 0x11b 0x1 0x10 +> write 0x11f 0x1 0x10 +> write 0x127 0x1 0x10 +> write 0x12b 0x1 0x10 +> write 0x130 0x1 0x10 +> write 0x137 0x1 0x10 +> write 0x13f 0x1 0x40 +> write 0x141 0x1 0x10 +> write 0x14b 0x1 0x10 +> write 0x14f 0x1 0x10 +> write 0x157 0x1 0x10 +> write 0x15b 0x1 0x10 +> write 0x161 0x1 0x10 +> write 0x167 0x1 0x03 +> write 0x16f 0x1 0x06 +> write 0x172 0x1 0x10 +> write 0x17b 0x1 0x10 +> write 0x17f 0x1 0x10 +> write 0x187 0x1 0x10 +> write 0x18b 0x1 0x10 +> write 0x192 0x1 0x10 +> write 0x197 0x1 0x06 +> write 0x19f 0x1 0x20 +> write 0x1a3 0x1 0x10 +> write 0x1ab 0x1 0x40 +> write 0x1af 0x1 0x01 +> write 0x1b7 0x1 0x10 +> write 0x1bb 0x1 0x20 +> write 0x1c3 0x1 0x10 +> write 0x1c7 0x1 0x20 +> write 0x1cc 0x1 0x10 +> write 0x1d3 0x1 0x10 +> write 0x1db 0x1 0x10 +> write 0x1df 0x1 0x10 +> write 0x1e7 0x1 0x10 +> write 0x1eb 0x1 0x10 +> write 0x1f3 0x1 0x10 +> write 0x1f4 0x1 0x10 +> write 0x1fd 0x1 0x10 +> write 0x203 0x1 0x40 +> write 0x20b 0x1 0x10 +> write 0x20f 0x1 0x10 +> write 0x217 0x1 0x10 +> write 0x21b 0x1 0x10 +> write 0x223 0x1 0x10 +> write 0x225 0x1 0x10 +> write 0x22e 0x1 0x10 +> write 0x233 0x1 0x06 +> write 0x23b 0x1 0x10 +> write 0x23f 0x1 0x10 +> write 0x247 0x1 0x10 +> write 0x24b 0x1 0x10 +> write 0x252 0x1 0x10 +> write 0x256 0x1 0x10 +> write 0x25f 0x1 0x10 +> write 0x263 0x1 0x20 +> write 0x26b 0x1 0x06 +> write 0x26f 0x1 0x40 +> write 0x277 0x1 0x10 +> write 0x27b 0x1 0x10 +> write 0x283 0x1 0x10 +> write 0x287 0x1 0x10 +> write 0x28f 0x1 0x10 +> write 0x290 0x1 0x10 +> write 0x29b 0x1 0x10 +> write 0x29f 0x1 0x10 +> write 0x2a7 0x1 0x10 +> write 0x2ab 0x1 0x10 +> write 0x2b3 0x1 0x10 +> write 0x2b7 0x1 0x10 +> write 0x2bf 0x1 0x10 +> write 0x2c1 0x1 0x10 +> write 0x2c9 0x1 0x10 +> write 0x2cf 0x1 0x10 +> write 0x2d7 0x1 0x10 +> write 0x2db 0x1 0x10 +> write 0x2e3 0x1 0x10 +> write 0x2e7 0x1 0x10 +> write 0x2ef 0x1 0x03 +> write 0x2f2 0x1 0x10 +> write 0x2fa 0x1 0x10 +> write 0x2ff 0x1 0x10 +> write 0x307 0x1 0x10 +> write 0x30b 0x1 0x10 +> write 0x313 0x1 0x10 +> write 0x316 0x1 0x10 +> write 0x31f 0x1 0x06 +> write 0x323 0x1 0x10 +> outb 0xc040 0x0 +> EOF +> +> === Stack Trace === +> ==1025760==ERROR: AddressSanitizer: global-buffer-overflow on address 0x558f557253fc at pc 0x558f549ab376 bp +> 0x7ffd436e9770 sp 0x7ffd436e9768 +> READ of size 4 at 0x558f557253fc thread T0 +> SCARINESS: 17 (4-byte-read-global-buffer-overflow) +> #0 0x558f549ab375 in mode_sense_page /src/qemu/hw/scsi/scsi-disk.c:1104:10 +> #1 0x558f549afd86 in scsi_disk_check_mode_select /src/qemu/hw/scsi/scsi-disk.c:1447:11 +> #2 0x558f549af9a6 in mode_select_pages /src/qemu/hw/scsi/scsi-disk.c:1515:17 +> #3 0x558f549ae593 in scsi_disk_emulate_mode_select /src/qemu/hw/scsi/scsi-disk.c:1570:13 +> #4 0x558f549a56e9 in scsi_disk_emulate_write_data /src/qemu/hw/scsi/scsi-disk.c:1861:9 +> #5 0x558f548b9b49 in scsi_req_continue /src/qemu/hw/scsi/scsi-bus.c:0 +> #6 0x558f548b9fc4 in scsi_req_data /src/qemu/hw/scsi/scsi-bus.c:1427:5 +> #7 0x558f549a5554 in scsi_disk_emulate_write_data /src/qemu/hw/scsi/scsi-disk.c:1853:9 +> #8 0x558f548b9b49 in scsi_req_continue /src/qemu/hw/scsi/scsi-bus.c:0 +> #9 0x558f54ac7cf6 in megasas_enqueue_req /src/qemu/hw/scsi/megasas.c:1660:9 +> #10 0x558f54ab6e09 in megasas_handle_scsi /src/qemu/hw/scsi/megasas.c:1735:5 +> #11 0x558f54ab3083 in megasas_handle_frame /src/qemu/hw/scsi/megasas.c:1974:24 +> #12 0x558f54ab1c8b in megasas_mmio_write /src/qemu/hw/scsi/megasas.c:2131:9 +> #13 0x558f54acc784 in megasas_port_write /src/qemu/hw/scsi/megasas.c:2182:5 +> #14 0x558f54f78d57 in memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +> #15 0x558f54f78be2 in access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +> #16 0x558f54f78441 in memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +> #17 0x558f550d5627 in flatview_write_continue /src/qemu/softmmu/physmem.c:2763:23 +> #18 0x558f550d02ac in flatview_write /src/qemu/softmmu/physmem.c:2803:14 +> #19 0x558f550d00c7 in address_space_write /src/qemu/softmmu/physmem.c:2895:18 +> #20 0x558f5506c4ff in cpu_outb /src/qemu/softmmu/ioport.c:60:5 +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1914638 +> +> Title: +> [OSS-Fuzz] Issue 30219: Global-buffer-overflow in mode_sense_page +> +> Status in QEMU: +> New +> +> Bug description: +> == Reproducer (build with --enable-sanitizers) == +> +> cat << EOF | ./qemu-system-i386 -machine q35 -nodefaults \ +> -device megasas -device scsi-cd,drive=null0 \ +> -blockdev driver=null-co,read-zeroes=on,node-name=null0 \ +> -nographic -qtest stdio +> outl 0xcf8 0x80000818 +> outl 0xcfc 0xc000 +> outl 0xcf8 0x80000804 +> outw 0xcfc 0x7 +> write 0x0 0x1 0x03 +> write 0x7 0x1 0x3f +> write 0x10 0x1 0x03 +> write 0x20 0x1 0x55 +> write 0x21 0x1 0x10 +> write 0x28 0x1 0x10 +> write 0x30 0x1 0xff +> write 0x31 0x1 0xff +> write 0x32 0x1 0xff +> write 0x33 0x1 0xff +> write 0x34 0x1 0xff +> write 0x35 0x1 0xff +> write 0x36 0x1 0xff +> write 0x37 0x1 0xff +> write 0x3b 0x1 0x10 +> write 0x43 0x1 0x10 +> write 0x44 0x1 0x10 +> write 0x4f 0x1 0x10 +> write 0x53 0x1 0x10 +> write 0x5b 0x1 0x10 +> write 0x5f 0x1 0x10 +> write 0x67 0x1 0x10 +> write 0x6b 0x1 0x10 +> write 0x73 0x1 0x10 +> write 0x75 0x1 0x10 +> write 0x7d 0x1 0x10 +> write 0x83 0x1 0x10 +> write 0x8b 0x1 0x10 +> write 0x8f 0x1 0x10 +> write 0x97 0x1 0x10 +> write 0x9b 0x1 0x10 +> write 0xa3 0x1 0x03 +> write 0xa6 0x1 0x10 +> write 0xae 0x1 0x10 +> write 0xb3 0x1 0x10 +> write 0xbb 0x1 0x10 +> write 0xbf 0x1 0x10 +> write 0xc7 0x1 0x10 +> write 0xca 0x1 0x10 +> write 0xd3 0x1 0x06 +> write 0xd7 0x1 0x10 +> write 0xdf 0x1 0x10 +> write 0xe3 0x1 0x06 +> write 0xeb 0x1 0x01 +> write 0xef 0x1 0x10 +> write 0xf7 0x1 0x10 +> write 0xfb 0x1 0x10 +> write 0x103 0x1 0x20 +> write 0x107 0x1 0x10 +> write 0x10f 0x1 0x10 +> write 0x113 0x1 0x10 +> write 0x11b 0x1 0x10 +> write 0x11f 0x1 0x10 +> write 0x127 0x1 0x10 +> write 0x12b 0x1 0x10 +> write 0x130 0x1 0x10 +> write 0x137 0x1 0x10 +> write 0x13f 0x1 0x40 +> write 0x141 0x1 0x10 +> write 0x14b 0x1 0x10 +> write 0x14f 0x1 0x10 +> write 0x157 0x1 0x10 +> write 0x15b 0x1 0x10 +> write 0x161 0x1 0x10 +> write 0x167 0x1 0x03 +> write 0x16f 0x1 0x06 +> write 0x172 0x1 0x10 +> write 0x17b 0x1 0x10 +> write 0x17f 0x1 0x10 +> write 0x187 0x1 0x10 +> write 0x18b 0x1 0x10 +> write 0x192 0x1 0x10 +> write 0x197 0x1 0x06 +> write 0x19f 0x1 0x20 +> write 0x1a3 0x1 0x10 +> write 0x1ab 0x1 0x40 +> write 0x1af 0x1 0x01 +> write 0x1b7 0x1 0x10 +> write 0x1bb 0x1 0x20 +> write 0x1c3 0x1 0x10 +> write 0x1c7 0x1 0x20 +> write 0x1cc 0x1 0x10 +> write 0x1d3 0x1 0x10 +> write 0x1db 0x1 0x10 +> write 0x1df 0x1 0x10 +> write 0x1e7 0x1 0x10 +> write 0x1eb 0x1 0x10 +> write 0x1f3 0x1 0x10 +> write 0x1f4 0x1 0x10 +> write 0x1fd 0x1 0x10 +> write 0x203 0x1 0x40 +> write 0x20b 0x1 0x10 +> write 0x20f 0x1 0x10 +> write 0x217 0x1 0x10 +> write 0x21b 0x1 0x10 +> write 0x223 0x1 0x10 +> write 0x225 0x1 0x10 +> write 0x22e 0x1 0x10 +> write 0x233 0x1 0x06 +> write 0x23b 0x1 0x10 +> write 0x23f 0x1 0x10 +> write 0x247 0x1 0x10 +> write 0x24b 0x1 0x10 +> write 0x252 0x1 0x10 +> write 0x256 0x1 0x10 +> write 0x25f 0x1 0x10 +> write 0x263 0x1 0x20 +> write 0x26b 0x1 0x06 +> write 0x26f 0x1 0x40 +> write 0x277 0x1 0x10 +> write 0x27b 0x1 0x10 +> write 0x283 0x1 0x10 +> write 0x287 0x1 0x10 +> write 0x28f 0x1 0x10 +> write 0x290 0x1 0x10 +> write 0x29b 0x1 0x10 +> write 0x29f 0x1 0x10 +> write 0x2a7 0x1 0x10 +> write 0x2ab 0x1 0x10 +> write 0x2b3 0x1 0x10 +> write 0x2b7 0x1 0x10 +> write 0x2bf 0x1 0x10 +> write 0x2c1 0x1 0x10 +> write 0x2c9 0x1 0x10 +> write 0x2cf 0x1 0x10 +> write 0x2d7 0x1 0x10 +> write 0x2db 0x1 0x10 +> write 0x2e3 0x1 0x10 +> write 0x2e7 0x1 0x10 +> write 0x2ef 0x1 0x03 +> write 0x2f2 0x1 0x10 +> write 0x2fa 0x1 0x10 +> write 0x2ff 0x1 0x10 +> write 0x307 0x1 0x10 +> write 0x30b 0x1 0x10 +> write 0x313 0x1 0x10 +> write 0x316 0x1 0x10 +> write 0x31f 0x1 0x06 +> write 0x323 0x1 0x10 +> outb 0xc040 0x0 +> EOF +> +> === Stack Trace === +> ==1025760==ERROR: AddressSanitizer: global-buffer-overflow on address 0x558f557253fc at pc 0x558f549ab376 bp +> 0x7ffd436e9770 sp 0x7ffd436e9768 +> READ of size 4 at 0x558f557253fc thread T0 +> SCARINESS: 17 (4-byte-read-global-buffer-overflow) +> #0 0x558f549ab375 in mode_sense_page /src/qemu/hw/scsi/scsi-disk.c:1104:10 +> #1 0x558f549afd86 in scsi_disk_check_mode_select /src/qemu/hw/scsi/scsi-disk.c:1447:11 +> #2 0x558f549af9a6 in mode_select_pages /src/qemu/hw/scsi/scsi-disk.c:1515:17 +> #3 0x558f549ae593 in scsi_disk_emulate_mode_select /src/qemu/hw/scsi/scsi-disk.c:1570:13 +> #4 0x558f549a56e9 in scsi_disk_emulate_write_data /src/qemu/hw/scsi/scsi-disk.c:1861:9 +> #5 0x558f548b9b49 in scsi_req_continue /src/qemu/hw/scsi/scsi-bus.c:0 +> #6 0x558f548b9fc4 in scsi_req_data /src/qemu/hw/scsi/scsi-bus.c:1427:5 +> #7 0x558f549a5554 in scsi_disk_emulate_write_data /src/qemu/hw/scsi/scsi-disk.c:1853:9 +> #8 0x558f548b9b49 in scsi_req_continue /src/qemu/hw/scsi/scsi-bus.c:0 +> #9 0x558f54ac7cf6 in megasas_enqueue_req /src/qemu/hw/scsi/megasas.c:1660:9 +> #10 0x558f54ab6e09 in megasas_handle_scsi /src/qemu/hw/scsi/megasas.c:1735:5 +> #11 0x558f54ab3083 in megasas_handle_frame /src/qemu/hw/scsi/megasas.c:1974:24 +> #12 0x558f54ab1c8b in megasas_mmio_write /src/qemu/hw/scsi/megasas.c:2131:9 +> #13 0x558f54acc784 in megasas_port_write /src/qemu/hw/scsi/megasas.c:2182:5 +> #14 0x558f54f78d57 in memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 +> #15 0x558f54f78be2 in access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 +> #16 0x558f54f78441 in memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 +> #17 0x558f550d5627 in flatview_write_continue /src/qemu/softmmu/physmem.c:2763:23 +> #18 0x558f550d02ac in flatview_write /src/qemu/softmmu/physmem.c:2803:14 +> #19 0x558f550d00c7 in address_space_write /src/qemu/softmmu/physmem.c:2895:18 +> #20 0x558f5506c4ff in cpu_outb /src/qemu/softmmu/ioport.c:60:5 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1914638/+subscriptions +> + + +Proposed fix: +https://<email address hidden>/msg779652.html + +What happened to your patch, Philippe? Did it get stalled? + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/546 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/118/unknown/1915535 b/results/classifier/118/unknown/1915535 new file mode 100644 index 00000000..2e3f3e6b --- /dev/null +++ b/results/classifier/118/unknown/1915535 @@ -0,0 +1,113 @@ +permissions: 0.837 +TCG: 0.819 +arm: 0.818 +x86: 0.811 +peripherals: 0.804 +network: 0.804 +device: 0.803 +register: 0.801 +debug: 0.801 +ppc: 0.801 +virtual: 0.793 +semantic: 0.787 +PID: 0.784 +graphic: 0.784 +files: 0.780 +VMM: 0.771 +mistranslation: 0.770 +hypervisor: 0.768 +socket: 0.768 +vnc: 0.765 +boot: 0.764 +architecture: 0.763 +risc-v: 0.761 +performance: 0.758 +i386: 0.755 +KVM: 0.755 +assembly: 0.749 +user-level: 0.749 +kernel: 0.742 + +Assertion `child->perm & BLK_PERM_WRITE' failed in bdrv_co_write_req_prepare through atapi + +Maybe this is a duplicate of https://bugs.launchpad.net/qemu/+bug/1906693 ... +In any case, ATAPI is probably a lot more common than megasas, so this might be a more useful reproducer + +==Reproducer== + +cat << EOF | ./qemu-system-i386 -display none \ +-m 512M -machine q35 -nodefaults \ +-drive file=null-co://,if=none,format=raw,id=disk0 \ +-device ide-cd,drive=disk0 -machine accel=qtest -qtest stdio +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x06 +write 0xe0000398 0x1 0x01 +write 0x63 0x1 0x06 +write 0x68 0x1 0x06 +write 0x69 0x1 0xf8 +write 0x6a 0x1 0xff +write 0xfff806 0x1 0x27 +write 0xfff807 0x1 0x80 +write 0xfff808 0x1 0x61 +write 0x1005734 0x1 0x3f +write 0x1005774 0x1 0x20 +write 0x1005784 0x1 0x34 +write 0x10057a4 0x1 0x27 +write 0x10057b4 0x1 0x3f +write 0x10057c3 0x1 0xce +write 0x10057d4 0x1 0x1a +write 0x10057e3 0x1 0xff +write 0x10057e4 0x1 0x3f +write 0x10057f4 0x1 0x38 +write 0x1005814 0x1 0x3e +write 0x1005823 0x1 0x60 +write 0x1005824 0x1 0x2d +write 0x1005833 0x1 0x74 +write 0x1005834 0x1 0x01 +write 0x1005863 0x1 0xff +write 0x1005883 0x1 0x5a +write 0x1005884 0x1 0x06 +write 0xe00003b8 0x1 0x08 +EOF + + +==Stack Trace== +i386: ahci: PRDT length for NCQ command (0x0) is smaller than the requested size (0x5a00) +qemu-fuzz-i386-target-generic-fuzz-ahci-atapi: ../block/io.c:1982: int +bdrv_co_write_req_prepare(BdrvChild *, int64_t, int64_t, BdrvTrackedRequest +*, int): Assertion `child->perm & BLK_PERM_WRITE' failed. +==279048== ERROR: libFuzzer: deadly signal +#0 0x560c92718f50 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/ubsan/ubsan_diag_standalone.cpp:33:3 +#1 0x560c926c2f98 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 +#2 0x560c926a7fd3 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 +#3 0x7ff7d707038f in libpthread.so.0 +#4 0x7ff7d66a8437 in raise +#5 0x7ff7d66aa039 in abort +#6 0x7ff7d66a0be6 in libc.so.6 +#7 0x7ff7d66a0c91 in __assert_fail +#8 0x560c92f4fc79 in bdrv_co_write_req_prepare /src/qemu/block/io.c:1982:13 +#9 0x560c92f4c974 in bdrv_aligned_pwritev /src/qemu/block/io.c:2065:11 +#10 0x560c92f4b937 in bdrv_co_pwritev_part /src/qemu/block/io.c:2270:11 +#11 0x560c92f392e7 in blk_do_pwritev_part /src/qemu/block/block-backend.c:1260:11 +#12 0x560c92f39a55 in blk_aio_write_entry /src/qemu/block/block-backend.c:1476:17 +#13 0x560c930d19d5 in coroutine_trampoline /src/qemu/util/coroutine-ucontext.c:173:9 +#14 0x7ff7d66bd5df in libc.so.6 + +OSS-Fuzz link: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30857 + +Not a duplicate of the other bug. Confirmed on development head beyond 6.0. + +Please migrate this bug to gitlab and assign me. + +--js + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/342 + + diff --git a/results/classifier/118/unknown/1916501 b/results/classifier/118/unknown/1916501 new file mode 100644 index 00000000..a55b457c --- /dev/null +++ b/results/classifier/118/unknown/1916501 @@ -0,0 +1,133 @@ +mistranslation: 0.896 +user-level: 0.890 +graphic: 0.878 +semantic: 0.856 +virtual: 0.850 +permissions: 0.849 +debug: 0.849 +risc-v: 0.847 +performance: 0.842 +register: 0.835 +vnc: 0.832 +assembly: 0.831 +hypervisor: 0.827 +KVM: 0.823 +architecture: 0.823 +socket: 0.820 +PID: 0.820 +arm: 0.815 +network: 0.807 +peripherals: 0.799 +TCG: 0.797 +x86: 0.791 +kernel: 0.785 +ppc: 0.782 +VMM: 0.771 +device: 0.761 +i386: 0.760 +boot: 0.758 +files: 0.712 + +qemu-img convert segfaults with specific URL + +Using what is currently the latest git: (commit 00d8ba9e0d62ea1c7459c25aeabf9c8bb7659462, Date: Sun Feb 21 19:52:58 2021 +0000) + +$ ./build/qemu-img convert -f qcow2 -O raw https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img out.img +Segmentation fault (core dumped) + + +Backtrace for convenience: +qemu: qemu_mutex_lock_impl: Invalid argument + +Thread 1 "qemu-img" received signal SIGABRT, Aborted. +0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff77c59d5 in raise () from /lib64/libc.so.6 +#1 0x00007ffff77ae8a4 in abort () from /lib64/libc.so.6 +#2 0x00005555556705b2 in error_exit (err=<optimized out>, msg=msg@entry=0x5555556b69a0 <__func__.31> "qemu_mutex_lock_impl") at ../util/qemu-thread-posix.c:37 +#3 0x0000555555670945 in qemu_mutex_lock_impl (mutex=0x555555ae3758, file=0x5555556827a2 "../block/curl.c", line=406) at ../util/qemu-thread-posix.c:81 +#4 0x000055555559a05b in curl_multi_do (arg=0x555555aad2a0) at ../block/curl.c:406 +#5 0x000055555566193a in aio_dispatch_handler (ctx=ctx@entry=0x555555737790, node=0x555555b14150) at ../util/aio-posix.c:329 +#6 0x0000555555662072 in aio_dispatch_handlers (ctx=0x555555737790) at ../util/aio-posix.c:372 +#7 aio_dispatch (ctx=0x555555737790) at ../util/aio-posix.c:382 +#8 0x000055555564442e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:306 +#9 0x00007ffff7cfda9f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 +#10 0x000055555566f2c8 in glib_pollfds_poll () at ../util/main-loop.c:232 +#11 os_host_main_loop_wait (timeout=4397000000) at ../util/main-loop.c:255 +#12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:531 +#13 0x0000555555581edd in convert_do_copy (s=0x7fffffffd3a0) at ../qemu-img.c:2139 +#14 img_convert (argc=<optimized out>, argv=<optimized out>) at ../qemu-img.c:2738 +#15 0x00005555555783b1 in main (argc=7, argv=<optimized out>) at ../qemu-img.c:5536 + +I can reproduce this, and I can reproduce it back to 5.0 (haven’t tried any release before that). I couldn’t find a definite reason for why it breaks (curl_clean_state() is called because curl reports CURLMSG_DONE, freeing a socket, but then curl_multi_do() is called again for that socket, resulting in a use-after-free – but I don’t know why curl_multi_do() is invoked after CURLMSG_DONE). + +Because I remembered a similar situation where the curl driver suddenly failed (and then failed for every qemu release until that point), and where it turned out a change in libcurl broke our driver, I tried bisecting libcurl, but it turned out that when I build it myself and use it via LD_PRELOAD, I don’t get a crash. I’ve tried building it with different options and in different versions, but consistently I see that using the system libcurl results in a crash, and using one I built myself does not. (Tested on Fedora and Arch.) + +That isn’t to say the bug isn’t in our curl driver, but to find out where it is exactly, it seems necessary to find out what the difference between the system libcurl and the one I built is... So far, I have no idea. :/ + +Guys, when I run with valgrind, I always get this when segfault occurs: + +==74885== Invalid read of size 8 +==74885== at 0x1DC87D: curl_multi_do (curl.c:410) +==74885== by 0x23B949: aio_dispatch_handler (aio-posix.c:329) +==74885== by 0x23C0A1: aio_dispatch_handlers (aio-posix.c:372) +==74885== by 0x23C0A1: aio_dispatch (aio-posix.c:382) +==74885== by 0x22DEE1: aio_ctx_dispatch (async.c:306) +==74885== by 0x4A854DA: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x236097: glib_pollfds_poll (main-loop.c:232) +==74885== by 0x236097: os_host_main_loop_wait (main-loop.c:255) +==74885== by 0x236097: main_loop_wait (main-loop.c:531) +==74885== by 0x13E30C: convert_do_copy (qemu-img.c:2139) +==74885== by 0x13E30C: img_convert (qemu-img.c:2738) +==74885== by 0x134660: main (qemu-img.c:5536) +==74885== Address 0xf9779b8 is 8 bytes inside a block of size 32 free'd +==74885== at 0x483DA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) +==74885== by 0x1DC5BC: curl_clean_state (curl.c:529) +==74885== by 0x1DC5BC: curl_clean_state (curl.c:515) +==74885== by 0x1DC7E4: curl_multi_check_completion (curl.c:385) +==74885== by 0x1DC8D4: curl_multi_do (curl.c:414) +==74885== by 0x23B949: aio_dispatch_handler (aio-posix.c:329) +==74885== by 0x23C0A1: aio_dispatch_handlers (aio-posix.c:372) +==74885== by 0x23C0A1: aio_dispatch (aio-posix.c:382) +==74885== by 0x22DEE1: aio_ctx_dispatch (async.c:306) +==74885== by 0x4A854DA: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x236097: glib_pollfds_poll (main-loop.c:232) +==74885== by 0x236097: os_host_main_loop_wait (main-loop.c:255) +==74885== by 0x236097: main_loop_wait (main-loop.c:531) +==74885== by 0x13E30C: convert_do_copy (qemu-img.c:2139) +==74885== by 0x13E30C: img_convert (qemu-img.c:2738) +==74885== by 0x134660: main (qemu-img.c:5536) +==74885== Block was alloc'd at +==74885== at 0x483ED99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) +==74885== by 0x4A8B5A0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x1DBDC9: curl_sock_cb (curl.c:156) +==74885== by 0x55402C1: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0) +==74885== by 0x5543D33: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0) +==74885== by 0x5543E77: curl_multi_socket_action (in /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.6.0) +==74885== by 0x1DC8C7: curl_multi_do_locked (curl.c:403) +==74885== by 0x1DC8C7: curl_multi_do (curl.c:413) +==74885== by 0x23B949: aio_dispatch_handler (aio-posix.c:329) +==74885== by 0x23C0A1: aio_dispatch_handlers (aio-posix.c:372) +==74885== by 0x23C0A1: aio_dispatch (aio-posix.c:382) +==74885== by 0x22DEE1: aio_ctx_dispatch (async.c:306) +==74885== by 0x4A854DA: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.1) +==74885== by 0x236097: glib_pollfds_poll (main-loop.c:232) +==74885== by 0x236097: os_host_main_loop_wait (main-loop.c:255) +==74885== by 0x236097: main_loop_wait (main-loop.c:531) + +It seems that sockets are being free'd in a non-expecting situation. + +Yes, as I wrote in comment 1, curl reports CURLMSG_DONE, the socket is freed, but then curl_multi_do() is called again for that socket (despite the CURLMSG_DONE). + +I suspect that qemu has interpreted the curl interface differently than curl itself (i.e., qemu has probably understood something wrong), which led to some change in curl breaking qemu’s curl module. (Because I can’t find an old qemu version that doesn’t break, and so can’t find a change in qemu that broke it.) + +So if indeed a change to the curl library is what causes this segfault, or at least made the underlying issue visible, I’d like to know which change that is, so we can try to infer what qemu does wrong. But I can’t find that change, because if I compile libcurl myself, I don’t get a segfault (nor valgrind errors in curl). + +Perhaps there’s something special about the server serving the image (although it just looks like AWS to me), i.e. it was always broken and we’ve just never seen it with other servers. If so, debugging will be more difficult because we’d really need to take a detailed look into all our curl driver does. + +I think I’ve come to kind of understood what might be wrong: qemu frees CURLSocket objects when “their” transfer is done, but libcurl’s documentation actually doesn’t note any long-lasting relationship between a socket and some transfer (i.e., a CURL object), so we probably shouldn’t free CURLSocket objects just because some transfer is done. Instead, we should only do so once libcurl explicitly tells us to remove the socket. + +I’ve sent a two-patch series to that effect: https://lists.nongnu.org/archive/html/qemu-block/2021-03/msg00515.html – it seems to help. + +https://gitlab.com/qemu-project/qemu/-/commit/0f418a207696b37f05d + diff --git a/results/classifier/118/unknown/1917082 b/results/classifier/118/unknown/1917082 new file mode 100644 index 00000000..c66ec260 --- /dev/null +++ b/results/classifier/118/unknown/1917082 @@ -0,0 +1,170 @@ +arm: 0.884 +register: 0.882 +device: 0.873 +graphic: 0.866 +mistranslation: 0.842 +peripherals: 0.841 +debug: 0.839 +permissions: 0.823 +assembly: 0.819 +virtual: 0.815 +user-level: 0.814 +performance: 0.812 +architecture: 0.812 +PID: 0.811 +KVM: 0.810 +socket: 0.810 +boot: 0.806 +hypervisor: 0.805 +vnc: 0.799 +i386: 0.795 +TCG: 0.790 +semantic: 0.789 +kernel: 0.788 +files: 0.788 +VMM: 0.784 +x86: 0.784 +network: 0.755 +ppc: 0.745 +risc-v: 0.723 + +[OSS-Fuzz] Issue 27574 e1000: Loopback-related stack-overflow + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ +512M -M q35 -nodefaults -device e1000,netdev=net0 -netdev user,id=net0 \ +-qtest /dev/null -qtest stdio +outl 0xcf8 0x80000813 +outl 0xcfc 0xfe +outl 0xcf8 0x80000803 +outw 0xcfc 0x0600 +write 0xfe000102 0x1 0x0a +writel 0xfe000020 0x420ff00 +write 0xfe00280a 0x2 0x0828 +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +clock_step +write 0xfe00281b 0x1 0x08 +write 0xf9b 0x1 0x01 +write 0x2170 0x1 0x14 +write 0x2171 0x1 0x38 +write 0x2173 0x1 0xfe +write 0xfe000402 0x1 0x02 +write 0xfe00380a 0x2 0x0210 +write 0xfe003818 0x1 0xfa +EOF + +=== Stack-trace === +==288216==ERROR: AddressSanitizer: stack-overflow on address 0x7fff51c96f48 (pc 0x56247061af36 bp 0x7fff51c97790 sp 0x7fff51c96f50 T0) +#0 0x56247061af36 in __asan_memcpy (/home/alxndr/Development/qemu/build/qemu-system-i386+0x2baff36) +#1 0x5624718eb70d in flatview_read_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2846:13 +#2 0x5624718ecd1b in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2879:12 +#3 0x5624718ecd1b in address_space_read_full /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2892:18 +#4 0x562470bcb75b in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:88:12 +#5 0x562470bcb75b in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:127:12 +#6 0x562470bcb75b in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:803:12 +#7 0x562470bcb75b in pci_dma_read /home/alxndr/Development/qemu/include/hw/pci/pci.h:821:12 +#8 0x562470bcb75b in e1000_receive_iov /home/alxndr/Development/qemu/build/../hw/net/e1000.c:954:9 +#9 0x562470bca465 in e1000_receive /home/alxndr/Development/qemu/build/../hw/net/e1000.c:1025:12 +#10 0x562470bc9671 in e1000_send_packet /home/alxndr/Development/qemu/build/../hw/net/e1000.c:549:9 +#11 0x562470bc7dd8 in xmit_seg /home/alxndr/Development/qemu/build/../hw/net/e1000.c +#12 0x562470bc4dfe in process_tx_desc /home/alxndr/Development/qemu/build/../hw/net/e1000.c:701:9 +#13 0x562470bc4dfe in start_xmit /home/alxndr/Development/qemu/build/../hw/net/e1000.c:756:9 +#14 0x562470bc4dfe in set_tctl /home/alxndr/Development/qemu/build/../hw/net/e1000.c:1127:5 +#15 0x5624719ef2f6 in memory_region_write_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:491:5 +#16 0x5624719eed63 in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 +#17 0x5624719ee5c0 in memory_region_dispatch_write /home/alxndr/Development/qemu/build/../softmmu/memory.c +#18 0x5624718f7776 in flatview_write_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2776:23 +#19 0x5624718ed13b in flatview_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2816:14 +#20 0x5624718ed13b in address_space_write /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2908:18 +#21 0x562470bcba6b in dma_memory_rw_relaxed /home/alxndr/Development/qemu/include/sysemu/dma.h:88:12 +#22 0x562470bcba6b in dma_memory_rw /home/alxndr/Development/qemu/include/sysemu/dma.h:127:12 +#23 0x562470bcba6b in pci_dma_rw /home/alxndr/Development/qemu/include/hw/pci/pci.h:803:12 +#24 0x562470bcba6b in pci_dma_write /home/alxndr/Development/qemu/include/hw/pci/pci.h:839:12 +#25 0x562470bcba6b in e1000_receive_iov /home/alxndr/Development/qemu/build/../hw/net/e1000.c:967:21 +#26 0x562470bca465 in e1000_receive /home/alxndr/Development/qemu/build/../hw/net/e1000.c:1025:12 +#27 0x562470bc9671 in e1000_send_packet /home/alxndr/Development/qemu/build/../hw/net/e1000.c:549:9 +... + +Still reproducible with the current qemu version from git (commit +7fe7fae8b48e3f9c647fd685) + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/547 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/118/unknown/1917161 b/results/classifier/118/unknown/1917161 new file mode 100644 index 00000000..52a3d94d --- /dev/null +++ b/results/classifier/118/unknown/1917161 @@ -0,0 +1,124 @@ +user-level: 0.826 +files: 0.817 +virtual: 0.810 +risc-v: 0.804 +TCG: 0.801 +register: 0.796 +debug: 0.794 +mistranslation: 0.794 +permissions: 0.794 +device: 0.792 +network: 0.787 +performance: 0.786 +i386: 0.786 +semantic: 0.784 +boot: 0.784 +socket: 0.784 +vnc: 0.783 +PID: 0.783 +hypervisor: 0.782 +graphic: 0.782 +assembly: 0.780 +ppc: 0.780 +architecture: 0.778 +x86: 0.776 +arm: 0.774 +peripherals: 0.773 +kernel: 0.773 +VMM: 0.770 +KVM: 0.763 + +Parameter 'type' expects a netdev backend type + +When using QEMU on an M1 Mac with Mac OS 11.1, I see this error message when trying to enable networking for a guest: + +Parameter 'type' expects a netdev backend type + +Example command: +qemu-system-i386 -m 700 -hda <Windows XP HD file> -netdev user,id=n0 -device rtl8139,netdev=n0 + +What should happen is networking should work when issuing the above command. What actually happens is QEMU exits immediately. + +What output do you get when you run: + + qemu-system-i386 -netdev help + +It's likely that your binary has been compiled without "user" networking (aka. "slirp") support. If so, please use a binary that has "slirp" enabled instead. + +I did try './configure --target-list=i386-softmmu --enable-slirp' but it failed with this error message: + +Run-time dependency slirp found: NO (tried pkgconfig) + +../meson.build:1498:4: ERROR: Dependency "slirp" not found, tried pkgconfig + +I thought slirp came with QEMU. I do see a slirp folder packaged with QEMU. + +Yes, QEMU should come with the libslirp sources. Are you using git? Then maybe something went wrong with the checkout of the submodule. Is there something in your "slirp" folder? What do you get when you run "git submodule" ? + +I see 14 files in the src folder in the slirp folder. +I am using git. +This is what I see when I run git submodule: + +objc[1854]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x203eaf8f0) and ?? (0x1147702b8). One of the two will be used. Which one is undefined. +objc[1854]: Class AMSupportURLSession is implemented in both ?? (0x203eaf940) and ?? (0x114770308). One of the two will be used. Which one is undefined. + f8b1b833015a4ae47110ed068e0deb7106ced66d capstone (4.0.1-548-gf8b1b833) + 85e5d839847af54efab170f2b1331b2a6421e647 dtc (v1.6.0-4-g85e5d83) + 776acd2a805c9b42b4f0375150977df42130317f meson (0.55.3) +-90c488d5f4a407342247b9ea869df1c2d9c8e266 roms/QemuMacDrivers +-e18ddad8516ff2cfe36ec130200318f7251aa78c roms/SLOF +-06dc822d045c2bb42e497487935485302486e151 roms/edk2 +-4bd064de239dab2426b31c9789a1f4d78087dc63 roms/ipxe +-7f28286f5cb1ca682e3ba0a8706d8884f12bc49e roms/openbios +-a98258d0b537a295f517bbc8d813007336731fa9 roms/opensbi +-a5300c4949b8d4de2d34bedfaed66793f48ec948 roms/qboot +-bf0e13698872450164fa7040da36a95d2d4b326f roms/qemu-palcode +-155821a1990b6de78dde5f98fa5ab90e802021e0 roms/seabios +-73b740f77190643b2ada5ee97a9a108c6ef2a37b roms/seabios-hppa +-cbaee52287e5f32373181cff50a00b6c4ac9015a roms/sgabios +-3a6fdede6ce117facec0108afe716cf5d0472c3f roms/skiboot +-d3689267f92c5956e09cc7d1baa4700141662bff roms/u-boot +-60b3916f33e617a815973c5a6df77055b2e3a588 roms/u-boot-sam460ex +-0c37a43527f0ee2b9584e7fb2fdc805e902635ac roms/vbootrom + 8f43a99191afb47ca3f3c6972f6306209f367ece slirp (v4.2.0-26-g8f43a99) + b64af41c3276f97f0e181920400ee056b9c88037 tests/fp/berkeley-softfloat-3 (heads/master) + 5a59dcec19327396a011a17fd924aed4fec416b3 tests/fp/berkeley-testfloat-3 (remotes/origin/HEAD) + 6119e6e19a050df847418de7babe5166779955e4 ui/keycodemapdb (remotes/origin/HEAD) + + +> On Mar 2, 2021, at 1:37 AM, Thomas Huth <email address hidden> wrote: +> +> Yes, QEMU should come with the libslirp sources. Are you using git? Then +> maybe something went wrong with the checkout of the submodule. Is there +> something in your "slirp" folder? What do you get when you run "git +> submodule" ? +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1917161 +> +> Title: +> Parameter 'type' expects a netdev backend type +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> When using QEMU on an M1 Mac with Mac OS 11.1, I see this error +> message when trying to enable networking for a guest: +> +> Parameter 'type' expects a netdev backend type +> +> Example command: +> qemu-system-i386 -m 700 -hda <Windows XP HD file> -netdev user,id=n0 -device rtl8139,netdev=n0 +> +> What should happen is networking should work when issuing the above +> command. What actually happens is QEMU exits immediately. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1917161/+subscriptions + + + +I looks like the solution to my problem was to delete the slirp folder, then do a 'git pull', then make QEMU again. Networking is working again. + diff --git a/results/classifier/118/unknown/1918917 b/results/classifier/118/unknown/1918917 new file mode 100644 index 00000000..f2950fd7 --- /dev/null +++ b/results/classifier/118/unknown/1918917 @@ -0,0 +1,173 @@ +register: 0.874 +permissions: 0.874 +virtual: 0.853 +PID: 0.853 +architecture: 0.851 +debug: 0.851 +performance: 0.848 +semantic: 0.847 +device: 0.845 +user-level: 0.844 +arm: 0.843 +TCG: 0.841 +kernel: 0.839 +assembly: 0.834 +mistranslation: 0.832 +graphic: 0.824 +socket: 0.822 +files: 0.818 +peripherals: 0.818 +ppc: 0.813 +boot: 0.810 +VMM: 0.777 +KVM: 0.776 +vnc: 0.774 +network: 0.752 +hypervisor: 0.729 +x86: 0.720 +risc-v: 0.716 +i386: 0.679 + +synchronous abort on accessing unused I/O ports on aarch64 + +version: QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-6) +command line: qemu-system-aarch64 \ + -machine virt,virtualization=on,graphics=on,usb=on -cpu cortex-a57 -smp 2 -m 2G \ + -device virtio-blk-device,drive=hd0 \ + -drive if=none,format=raw,id=hd0,file=buildroot \ + -kernel arch/arm64/boot/Image \ + -nographic \ + -device virtio-rng-pci \ + -net user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic,model=virtio-net-pci \ + -append "root=/dev/vda earlyprintk=serial console=ttyAMA0 earlycon" + +I am observing "synchronous external abort" when kernel tries to access unused I/O ports (see below), while hardware/qemu should return 0xffffffff in this case. + +This is factored out of this LKML thread where Arnd describes it in more details: +https://lore.kernel<email address hidden>/ + +Internal error: synchronous external abort: 96000050 [#1] PREEMPT SMP +Dumping ftrace buffer: + (ftrace buffer empty) +Modules linked in: +CPU: 0 PID: 11231 Comm: syz-executor.1 Not tainted 5.12.0-rc2-syzkaller-00302-g28806e4d9b97 #0 +Hardware name: linux,dummy-virt (DT) +pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--) +pc : __raw_writeb arch/arm64/include/asm/io.h:27 [inline] +pc : _outb include/asm-generic/io.h:501 [inline] +pc : logic_outb+0x3c/0x114 lib/logic_pio.c:302 +lr : io_serial_out+0x80/0xc0 drivers/tty/serial/8250/8250_port.c:453 +sp : ffff000015f0f980 +x29: ffff000015f0f980 x28: ffff80001de0005d +x27: ffff80001601df00 x26: ffff000015f0fc90 +x25: ffff80001de00000 x24: ffff80001de00000 +x23: ffff00000e27f600 x22: 0000000000000000 +x21: 0000000000000002 x20: 0000000000000002 +x19: fffffbfffe800001 x18: ffff00006a678b48 +x17: 0000000000000000 x16: 0000000000000000 +x15: ffff8000197be810 x14: 1fffe00002be1f0e +x13: 1fffe00002be1e90 x12: ffff600002be1f39 +x11: 1fffe00002be1f38 x10: ffff600002be1f38 +x9 : dfff800000000000 x8 : 0000000000000003 +x7 : 0000000000000001 x6 : 0000000000000004 +x5 : ffff000015f0f9c0 x4 : dfff800000000000 +x3 : 0000000000000001 x2 : 1ffff00003494e6b +x1 : fffffbfffe800000 x0 : 0000000000ffbffe +Call trace: + _outb include/asm-generic/io.h:501 [inline] + logic_outb+0x3c/0x114 lib/logic_pio.c:302 + io_serial_out+0x80/0xc0 drivers/tty/serial/8250/8250_port.c:453 + serial_out drivers/tty/serial/8250/8250.h:118 [inline] + serial8250_set_THRI drivers/tty/serial/8250/8250.h:138 [inline] + __start_tx drivers/tty/serial/8250/8250_port.c:1566 [inline] + serial8250_start_tx+0x338/0x6c0 drivers/tty/serial/8250/8250_port.c:1666 + __uart_start.isra.0+0x10c/0x154 drivers/tty/serial/serial_core.c:127 + uart_start+0xe0/0x210 drivers/tty/serial/serial_core.c:137 + uart_flush_chars+0x10/0x20 drivers/tty/serial/serial_core.c:573 + __receive_buf drivers/tty/n_tty.c:1646 [inline] + n_tty_receive_buf_common+0x588/0x22c0 drivers/tty/n_tty.c:1739 + n_tty_receive_buf+0x14/0x20 drivers/tty/n_tty.c:1768 + tiocsti drivers/tty/tty_io.c:2317 [inline] + tty_ioctl+0xed0/0x1aec drivers/tty/tty_io.c:2718 + vfs_ioctl fs/ioctl.c:48 [inline] + __do_sys_ioctl fs/ioctl.c:753 [inline] + __se_sys_ioctl fs/ioctl.c:739 [inline] + __arm64_sys_ioctl+0x120/0x18c fs/ioctl.c:739 + __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] + invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] + el0_svc_common.constprop.0+0xf0/0x2c0 arch/arm64/kernel/syscall.c:129 + do_el0_svc+0xa4/0xd0 arch/arm64/kernel/syscall.c:168 + el0_svc+0x24/0x34 arch/arm64/kernel/entry-common.c:416 + el0_sync_handler+0x1a4/0x1b0 arch/arm64/kernel/entry-common.c:432 + el0_sync+0x170/0x180 arch/arm64/kernel/entry.S:699 +Code: d2bfd001 f2df7fe1 f2ffffe1 8b010273 (39000274) +---[ end trace 79cb47219936c254 ]--- + +My best guess is that the PCI I/O port handling in qemu only returns data for ports that are connected to an actual device. + +In this case, the kernel attempts to access a 8250 serial port at an address where none exists. While this is also a bug in the kernel, a real PCI implementation would not cause an external abort but simply return 'all-ones' (0xff, 0xffff, 0xffffffff) for a read request and ignore writes. This is something that the kernel relies on for probing unknown ISA style devices. + +Am I missing it, or does the kernel's logging for data aborts not print the FAR_EL1 value ? + + +That seems correct, and could probably be improved. In this case, I know that _outb() only writes within the PCI PIO virtual address between fffffbfffe800000 and fffffbffff800000, which according to the boot log (https://gist.githubusercontent.com/dvyukov/084890d9b4aa7cd54f468e652a9b5881/raw/54c12248ff6a4885ba6c530d56b3adad59bc6187/gistfile1.txt) was mapped to qemu's PCI IO space, using DEVICE_nGnRnE attributes (PIO space unlike any other MMIO in the kernel uses 'nE'): + +[ 3.973419][ T1] pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges: +[ 3.974309][ T1] pci-host-generic 4010000000.pcie: IO 0x003eff0000..0x003effffff -> 0x0000000000 +[ 3.975021][ T1] pci-host-generic 4010000000.pcie: MEM 0x0010000000..0x003efeffff -> 0x0010000000 + +So physical address 0x003eff0000 corresponds to virtual address fffffbfffe800000, which corresponds to logical PIO port number 0. The serial port in the kernel was probed at port number 0, so the driver attempts to write to the 8250 compatible UART_IER at address fffffbfffe800001, which is in register x19. + +Is there a test case (all necessary images/files/QEMU command line) I can repro this with ? + + +The image is (gunzip it after download): +https://storage.googleapis.com/syzkaller/images/buildroot-arm64-2020.11.gz + +Kernel: +https://storage.googleapis.com/syzkaller/temp/arm64-Image + +qemu command line: + +qemu-system-aarch64 \ + -machine virt,virtualization=on,graphics=on,usb=on -cpu cortex-a57 -smp 2 -m 2G \ + -device virtio-blk-device,drive=hd0 \ + -drive if=none,format=raw,id=hd0,file=buildroot-arm64-2020.11 \ + -kernel arm64-Image \ + -nographic \ + -device virtio-rng-pci \ + -net user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic,model=virtio-net-pci \ + -append "root=/dev/vda earlyprintk=serial console=ttyAMA0 earlycon" + +Reproducer: + +#include <stdlib.h> +#include <string.h> +#include <sys/syscall.h> +#include <sys/types.h> +#include <unistd.h> + +int main(void) +{ + int fd = syscall(__NR_openat, 0xffffffffffffff9cul, "/dev/ttyS3", 0ul, 0ul); + char ch = 0; + syscall(__NR_ioctl, fd, 0x5412, &ch); // TIOCSTI + return 0; +} + +Build with: +arch64-linux-gnu-gcc prog.c -static + +scp to the VM and run. The image has password-less root ssh. + +Uploaded the binary reproducer as: +https://storage.googleapis.com/syzkaller/temp/arm64-tty-crash + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/317 + + diff --git a/results/classifier/118/unknown/1920013 b/results/classifier/118/unknown/1920013 new file mode 100644 index 00000000..d043ff7c --- /dev/null +++ b/results/classifier/118/unknown/1920013 @@ -0,0 +1,167 @@ +graphic: 0.866 +user-level: 0.858 +permissions: 0.842 +peripherals: 0.842 +mistranslation: 0.842 +risc-v: 0.812 +debug: 0.809 +arm: 0.802 +hypervisor: 0.797 +virtual: 0.796 +semantic: 0.794 +KVM: 0.793 +TCG: 0.791 +register: 0.790 +x86: 0.789 +vnc: 0.787 +architecture: 0.783 +socket: 0.780 +performance: 0.765 +ppc: 0.762 +network: 0.762 +VMM: 0.754 +device: 0.752 +boot: 0.750 +assembly: 0.721 +PID: 0.712 +kernel: 0.708 +i386: 0.699 +files: 0.694 + +Unable to pass-through PCIe devices from a ppc64le host to an x86_64 guest + +Attempting to pass through a PCIe device from a ppc64le host to an x86_64 guest with QEMU v5.2.0-3031-g571d413b5d (built from git master) fails with the following error: + + include/exec/memory.h:43:IOMMU_MEMORY_REGION: Object 0x10438eb00 is not an instance of type qemu:iommu-memory-region + +To reproduce this issue, simply run the following command on a POWER9 system: + + qemu-system-x86_64 -machine q35 -device vfio-pci,host=$DBSF + +Where $DBSF is a domain:bus:slot.function PCIe device address. + +This also fails with QEMU 3.1.0 (from Debian Buster), so I assume this has never worked. Helpfully, the error message it prints seems to indicate where the problem is: + + hw/vfio/spapr.c:147:vfio_spapr_create_window: Object 0x164473510 is not an instance of type qemu:iommu-memory-region + +My kernel (Linux v5.8.0 plus some small unrelated patches) is built with the page size set to 4k, so this issue shouldn't be due to a page size mismatch. And as I stated earlier, my host arch is ppc64le, so it shouldn't be an endianness issue, either. + +I assume this should be possible (in theory) since I've seen reports of others getting PCIe passthrough working with aarch64 guests on x86_64 hosts, but of course that (passthrough to weird guest arch on x86) is somewhat the opposite of what I'm trying to do (passthrough to x86 on weird host arch) so I don't know for sure. If it is possible, I'm willing to develop a fix myself, but I'm almost completely unfamiliar with QEMU's internals so if anyone has any advice on where to start I'd greatly appreciate it. + +I've done some more investigating, and have produced a backtrace of the error: + + #0 0x00003ffff6b63228 in __libc_signal_restore_set (set=0x3fffffffcec8) at ../sysdeps/unix/sysv/linux/internal-signals.h:84 + #1 0x00003ffff6b63228 in __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:48 + #2 0x00003ffff6b4358c in __GI_abort () at abort.c:79 + #3 0x000000010080d524 in object_dynamic_cast_assert + (obj=0x1016db860, typename=0x100bf9980 "qemu:iommu-memory-region", file=0x100bf9940 "/usr/src/qemu/include/exec/memory.h", line=<optimized out>, func=0x100c08a70 <__func__.21845> "IOMMU_MEMORY_REGION") at ../qom/object.c:883 + #4 0x00000001006b6f84 in IOMMU_MEMORY_REGION (obj=<optimized out>) at /usr/src/qemu/include/exec/memory.h:42 + #5 0x00000001006b6f84 in vfio_spapr_create_window (container=0x102357380, section=0x3fffffffd410, pgsize=0x3fffffffd368) + at ../hw/vfio/spapr.c:149 + #6 0x00000001007a09a0 in vfio_listener_region_add (listener=0x102357390, section=0x3fffffffd410) at ../hw/vfio/common.c:709 + #7 0x00000001006ea6f4 in listener_add_address_space (as=<optimized out>, listener=0x102357390) at ../softmmu/memory.c:2729 + #8 0x00000001006ea6f4 in memory_listener_register (listener=0x102357390, as=<optimized out>) at ../softmmu/memory.c:2796 + #9 0x00000001007a36f4 in vfio_connect_container (errp=0x3fffffffe818, as=<optimized out>, group=0x102357300) + at ../hw/vfio/common.c:1886 + #10 0x00000001007a36f4 in vfio_get_group (groupid=<optimized out>, as=<optimized out>, errp=0x3fffffffe818) + at ../hw/vfio/common.c:2003 + #11 0x000000010071a2a8 in vfio_realize (pdev=0x102350f80, errp=0x3fffffffe818) at ../hw/vfio/pci.c:2834 + #12 0x0000000100488e20 in pci_qdev_realize (qdev=0x102350f80, errp=0x3fffffffe940) at ../hw/pci/pci.c:2113 + #13 0x00000001008063e0 in device_set_realized (obj=0x102350f80, value=<optimized out>, errp=0x3fffffffea50) at ../hw/core/qdev.c:761 + #14 0x000000010080afbc in property_set_bool + (obj=0x102350f80, v=<optimized out>, name=<optimized out>, opaque=0x1014f1930, errp=0x3fffffffea50) at ../qom/object.c:2257 + #15 0x000000010080ee2c in object_property_set (obj=0x102350f80, name=0x100c023a0 "realized", v= + 0x102351d30, errp=0x101450b30 <error_fatal>) at ../qom/object.c:1402 + #16 0x000000010080a55c in object_property_set_qobject + (obj=0x102350f80, name=0x100c023a0 "realized", value=<optimized out>, errp=0x101450b30 <error_fatal>) at ../qom/qom-qobject.c:28 + #17 0x000000010080f1b0 in object_property_set_bool + (obj=0x102350f80, name=0x100c023a0 "realized", value=<optimized out>, errp=0x101450b30 <error_fatal>) at ../qom/object.c:1472 + #18 0x00000001008042bc in qdev_realize (dev=0x102350f80, bus=<optimized out>, errp=0x101450b30 <error_fatal>) + at ../hw/core/qdev.c:389 + #19 0x000000010036cfac in qdev_device_add (opts=0x1014e9960, errp=0x101450b30 <error_fatal>) + at /usr/src/qemu/include/hw/qdev-core.h:17 + #20 0x00000001006d5e68 in device_init_func (opaque=<optimized out>, opts=<optimized out>, errp=<optimized out>) + at ../softmmu/vl.c:1202 + #21 0x0000000100abe070 in qemu_opts_foreach + (list=<optimized out>, func=0x1006d5e40 <device_init_func>, opaque=0x0, errp=0x101450b30 <error_fatal>) + at ../util/qemu-option.c:1167 + #22 0x00000001006da110 in qemu_create_cli_devices () at ../softmmu/vl.c:2494 + #23 0x00000001006da110 in qmp_x_exit_preconfig (errp=<optimized out>) at ../softmmu/vl.c:2542 + #24 0x00000001006df87c in qemu_init (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/vl.c:3553 + #25 0x000000010031d3c8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:49 + +I also took a look at some of the arguments in frame #5 (where the type check is failing): + + (gdb) f + #5 vfio_spapr_create_window (container=0x102357380, section=0x3fffffffd410, pgsize=0x3fffffffd368) at ../hw/vfio/spapr.c:149 + 149 IOMMUMemoryRegion *iommu_mr = IOMMU_MEMORY_REGION(section->mr); + (gdb) l + 144 int vfio_spapr_create_window(VFIOContainer *container, + 145 MemoryRegionSection *section, + 146 hwaddr *pgsize) + 147 { + 148 int ret = 0; + 149 IOMMUMemoryRegion *iommu_mr = IOMMU_MEMORY_REGION(section->mr); + 150 uint64_t pagesize = memory_region_iommu_get_min_page_size(iommu_mr), pgmask; + 151 unsigned entries, bits_total, bits_per_level, max_levels; + 152 struct vfio_iommu_spapr_tce_create create = { .argsz = sizeof(create) }; + 153 long rampagesize = qemu_minrampagesize(); + (gdb) p *section->mr + $5 = {parent_obj = {class = 0x101512f90, free = 0x0, Python Exception <class 'gdb.error'> There is no member named keys.: + properties = 0x101716b60, ref = 1, parent = 0x1016db800}, romd_mode = true, + ram = true, subpage = false, readonly = false, nonvolatile = false, rom_device = false, flush_coalesced_mmio = false, + dirty_log_mask = 0 '\000', is_iommu = false, ram_block = 0x101725c30, owner = 0x1016db800, ops = 0x101300b00 <unassigned_mem_ops>, + opaque = 0x0, container = 0x0, size = 134217728, addr = 0, destructor = 0x1006e0d50 <memory_region_destructor_ram>, + align = 2097152, terminates = true, ram_device = false, enabled = true, warning_printed = false, vga_logging_count = 0 '\000', + alias = 0x0, alias_offset = 0, priority = 0, subregions = {tqh_first = 0x0, tqh_circ = {tql_next = 0x0, tql_prev = 0x1016db908}}, + subregions_link = {tqe_next = 0x0, tqe_circ = {tql_next = 0x0, tql_prev = 0x0}}, coalesced = {tqh_first = 0x0, tqh_circ = { + tql_next = 0x0, tql_prev = 0x1016db928}}, name = 0x101725b10 "pc.ram", ioeventfd_nb = 0, ioeventfds = 0x0} + +So it seems this is failing because the memory region "pc.ram" is not an IOMMU ("is_iommu = false"). I'm not really sure what that means, and I still don't know how to fix this, but hopefully this information will help. + +If there's any more information I should provide, please let me know. + +I think cross-arch VFIO has already been discussed in: + +https://bugs.launchpad.net/qemu/+bug/1869006 + +Perhaps you will have some answers. + +> https://bugs.launchpad.net/qemu/+bug/1869006 + +Unfortunately, that's not the same issue I'm having, and the error I see happens regardless of how much or how little RAM I allocate to the VM. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +I've moved this bug over to GitLab here: https://gitlab.com/qemu-project/qemu/-/issues/391 + +Thanks for moving it over! ... so I'm closing this on Launchpad now. + diff --git a/results/classifier/118/unknown/1923689 b/results/classifier/118/unknown/1923689 new file mode 100644 index 00000000..4a79c7ff --- /dev/null +++ b/results/classifier/118/unknown/1923689 @@ -0,0 +1,118 @@ +mistranslation: 0.845 +i386: 0.831 +VMM: 0.813 +permissions: 0.812 +virtual: 0.803 +hypervisor: 0.803 +TCG: 0.802 +user-level: 0.798 +KVM: 0.794 +register: 0.789 +peripherals: 0.787 +architecture: 0.781 +performance: 0.780 +network: 0.774 +device: 0.770 +files: 0.760 +boot: 0.755 +x86: 0.754 +socket: 0.754 +ppc: 0.753 +PID: 0.752 +vnc: 0.751 +graphic: 0.751 +assembly: 0.749 +arm: 0.733 +debug: 0.731 +kernel: 0.731 +risc-v: 0.717 +semantic: 0.705 + +sig-abort / coredump observed from aio_ctx_finalize + +Observing occasional sig-abort based on v5.2.0 (tag) of QEMU. The VMM is configured for Kata use case, launching with a nvdimm/pmem based rootfs, and a set of workloads which are heavily utilizing virtio-fs. + +Sample qemu-cmdline: +/usr/bin/qemu-kata-system-x86_64 +-name sandbox-9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c +-uuid cd58d78d-ad44-4d26-9eab-66efab3fb23b +-machine pc,accel=kvm,kernel_irqchip,nvdimm=on +-cpu host,pmu=off +-qmp unix:/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/qmp.sock,server,nowait +-m 2048M,slots=10,maxmem=386381M +-device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= +-device virtio-serial-pci,disable-modern=false,id=serial0,romfile=,max_ports=2 +-device virtconsole,chardev=charconsole0,id=console0 +-chardev socket,id=charconsole0,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/console.sock,server,nowait +-device nvdimm,id=nv0,memdev=mem0 +-object memory-backend-file,id=mem0,mem-path=/usr/share/kata-containers/kata-containers.img,size=536870912 +-object rng-random,id=rng0,filename=/dev/urandom +-device virtio-rng-pci,rng=rng0,romfile= +-device vhost-vsock-pci,disable-modern=false,vhostfd=3,id=vsock-3054067214,guest-cid=3054067214,romfile= +-chardev socket,id=char-770bb156466e8ed5,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/vhost-fs.sock +-device vhost-user-fs-pci,chardev=char-770bb156466e8ed5,tag=kataShared,romfile= +-netdev tap,id=network-0,vhost=on,vhostfds=4,fds=5 +-device driver=virtio-net-pci,netdev=network-0,mac=9e:ad:0c:d1:58:e0,disable-modern=false,mq=on,vectors=4,romfile= +-rtc base=utc,driftfix=slew,clock=host +-global kvm-pit.lost_tick_policy=discard +-vga none +-no-user-config +-nodefaults +-nographic +--no-reboot +-daemonize +-object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on +-numa node,memdev=dimm1 +-kernel /usr/share/kata-containers/vmlinuz +-append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=32 systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket +-pidfile /run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/pid +-smp 1,cores=1,threads=1,sockets=32,maxcpus=32 + +From the core file I was able to obtain a backtrace: + +``` +(gdb) info thread + Id Target Id Frame + 6 Thread 0x7f92feffd700 (LWP 14678) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 5 Thread 0x7f92fffff700 (LWP 13860) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 4 Thread 0x7f930dcff700 (LWP 13572) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 3 Thread 0x7f92ff7fe700 (LWP 14179) 0x00007f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 + 2 Thread 0x7f93aed03700 (LWP 13565) 0x00007f93b20bfd19 in syscall () from /lib64/libc.so.6 +* 1 Thread 0x7f93c718dcc0 (LWP 13564) 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +(gdb) bt trace +No symbol table is loaded. Use the "file" command. +(gdb) bt +#0 0x00007f93b1ffd3d7 in raise () from /lib64/libc.so.6 +#1 0x00007f93b1ffeac8 in abort () from /lib64/libc.so.6 +#2 0x00007f93b1ff61a6 in __assert_fail_base () from /lib64/libc.so.6 +#3 0x00007f93b1ff6252 in __assert_fail () from /lib64/libc.so.6 +#4 0x00000000007c6955 in aio_ctx_finalize () +#5 0x00007f93c64223d1 in g_source_unref_internal () from /lib64/libglib-2.0.so.0 +#6 0x00007f93c64225f5 in g_source_iter_next () from /lib64/libglib-2.0.so.0 +#7 0x00007f93c642362d in g_main_context_unref () from /lib64/libglib-2.0.so.0 +#8 0x00007f93c6425628 in g_main_loop_unref () from /lib64/libglib-2.0.so.0 +#9 0x00000000006dbaa0 in iothread_instance_finalize () +#10 0x00000000006c01e9 in object_unref () +#11 0x00000000006be647 in object_property_del_child () +#12 0x000000000075ad79 in monitor_cleanup () +#13 0x0000000000630635 in qemu_cleanup () +#14 0x000000000040fed3 in main () +``` + +I *think* we're hitting this assert: https://github.com/qemu/qemu/blob/master/util/async.c#L339 based on +``` +(gdb) up +#4 0x00000000007c6955 in aio_ctx_finalize () +``` + +The error is relatively infrequent, but a catastrophic core dump none the less. + +Please let me know if there's more I can pull from the core, or more info I can share to help facilitate debugging this error. + +Please install debuginfo and run "p *ctx" in GDB from the aio_ctx_finalize frame. That should show ctx->scheduled_coroutines, ctx->bh_slice_list, etc. + +Thanks to Stefan for the help -- IRL we debugged this to the following assert failure: + assert(QSIMPLEQ_EMPTY(&ctx->bh_slice_list)); + +This has been resolved upstream in https://github.com/qemu/qemu/commit/c81219a7dd36a815bd85beed9932fc973d4f5d51 + diff --git a/results/classifier/118/unknown/1924912 b/results/classifier/118/unknown/1924912 new file mode 100644 index 00000000..3ab762df --- /dev/null +++ b/results/classifier/118/unknown/1924912 @@ -0,0 +1,210 @@ +user-level: 0.830 +hypervisor: 0.827 +mistranslation: 0.821 +virtual: 0.814 +vnc: 0.812 +KVM: 0.808 +peripherals: 0.806 +architecture: 0.802 +debug: 0.801 +semantic: 0.795 +permissions: 0.795 +device: 0.792 +register: 0.792 +assembly: 0.790 +graphic: 0.786 +arm: 0.785 +performance: 0.785 +TCG: 0.785 +PID: 0.785 +socket: 0.782 +ppc: 0.780 +kernel: 0.780 +risc-v: 0.778 +network: 0.773 +VMM: 0.768 +x86: 0.768 +boot: 0.763 +files: 0.761 +i386: 0.760 + +VirtIO drivers don't work on Windows: "GLib: Too many handles to wait for!" crash + +I ran SerenityOS <https://github.com/SerenityOS/serenity> out of WSL2 with native Windows QEMU. The system runs fine on the Linux QEMU (with Windows X-Server). However, with Windows QEMU I get a hard crash after the following output: + +``` +[#0 colonel(0:0)]: Scheduler[0]: idle loop running +[init_stage2(2:2)]: PCI [0000:00:00:00] PCI::ID [8086:1237] +[init_stage2(2:2)]: PCI [0000:00:01:00] PCI::ID [8086:7000] +[init_stage2(2:2)]: PCI [0000:00:01:01] PCI::ID [8086:7010] +[init_stage2(2:2)]: PCI [0000:00:01:02] PCI::ID [8086:7020] +[init_stage2(2:2)]: PCI [0000:00:01:03] PCI::ID [8086:7113] +[init_stage2(2:2)]: PCI [0000:00:02:00] PCI::ID [1234:1111] +[init_stage2(2:2)]: PCI [0000:00:03:00] PCI::ID [8086:2922] +[init_stage2(2:2)]: PCI [0000:00:04:00] PCI::ID [1af4:1003] +[init_stage2(2:2)]: PCI [0000:00:05:00] PCI::ID [1af4:1005] +[init_stage2(2:2)]: PCI [0000:00:06:00] PCI::ID [8086:100e] +[#0 init_stage2(2:2)]: BXVGA: framebuffer @ P0xf8000000 +[#0 init_stage2(2:2)]: BXVGADevice resolution set to 1024x768 (pitch=4096) +[init_stage2(2:2)]: UHCI: Controller found PCI::ID [8086:7020] @ PCI [0000:00:01:02] +[init_stage2(2:2)]: UHCI: I/O base IO c080 +[init_stage2(2:2)]: UHCI: Interrupt line: 11 +[#0 init_stage2(2:2)]: UHCI: Allocated framelist at physical address P0x00e40000 +[#0 init_stage2(2:2)]: UHCI: Framelist is at virtual address V0xc115d000 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f000) @ 14946304: link_ptr=14946338, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f020) @ 14946336: link_ptr=14946370, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f040) @ 14946368: link_ptr=14946402, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f060) @ 14946400: link_ptr=14946434, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: QH(0xc115f080) @ 14946432: link_ptr=14958593, element_link_ptr=1 +[#0 init_stage2(2:2)]: UHCI: Reset completed +[#0 init_stage2(2:2)]: UHCI: Started +[#0 init_stage2(2:2)]: DMIExpose: SMBIOS 32bit Entry point @ P0x000f5870 +[#0 init_stage2(2:2)]: DMIExpose: Data table @ P0x000f5890 +[#0 init_stage2(2:2)]: VirtIOConsole: Found @ PCI [0000:00:04:00] +[#0 init_stage2(2:2)]: Trying to unregister unused handler (?) +[#0 init_stage2(2:2)]: VirtIOConsole: Multi port is not yet supported! +[#0 init_stage2(2:2)]: VirtIOConsole: cols: 0, rows: 0, max nr ports 0 +qemu-system-i386.exe: warning: GLib: Too many handles to wait for! +``` + +The lines starting with [ are SerenityOS output; QEMU warns "GLib: Too many handles to wait for!" and crashes right after (can't even Ctrl-C in the WSL command line, force-close in Windows necessary). A window is still spawned but as the OS already switched out of text mode, just a black screen is visible as QEMU crashes. + +I first thought this to be an issue with SerenityOS and reported it over there: <https://github.com/SerenityOS/serenity/issues/6422>. The kernel devs pointed out that this seems to be a VirtIO driver/device issue on the Windows build of QEMU, because the Serenity kernel tries to initialize VirtIO devices which apparently crashes QEMU. There will be mitigations from the SerenityOS side (by allowing to disable VirtIO on boot) but it would of course be great if QEMU handled this properly. + +Version info: Both QEMU 6.0.0-rc3 and 5.2.0 exhibit this issue. Windows release is 20H2, WSL2 is running Debian 10.9. SerenityOS has no proper version but it was reproduced on the most current commits as of 18/04/2021. + +Did you build your own Windows binary based on the official sources? Or did you use a precompiled binary? If yes, which one? + +Please describe the exact steps to reproduce the issue. + +I used the pre-built binaries with the versions described above. I did not change any install options so this can be reproduced after using the official install binaries for each version. + +Le 19/04/2021 à 12:39, Stefan Weil a écrit : +> I can confirm the issue also with latest official QEMU sources. +> +> Related issue URLs: +> +> https://github.com/tesseract-ocr/tesseract/issues/2838 +> +> https://bugs.launchpad.net/qemu/+bug/1924912 +> +> Instructions and files required to reproduce the issue: +> +> https://qemu.weilnetz.de/test/bugs/1924912/ +> +> Michael, Laurent, maybe you have an idea how to narrow down this issue? + +Could it be related to the number of file descriptors that can differ between linux an windows? + +We have a series of patches that sets the number of queues to the number of vCPU: + +a4eef0711b2c vhost-user-blk-pci: default num_queues to -smp N +9445e1e15e66 virtio-blk-pci: default num_queues to -smp N +6a558822849f virtio-scsi-pci: default num_queues to -smp N +4e5163bd8444 virtio-scsi: introduce a constant for fixed virtqueues +1436f32a84c3 virtio-pci: add virtio_pci_optimal_num_queues() helper + +And I think it can have inpact on the number of open file descriptors. + +You can try by specifiying "num_queues=1" with the virtio interfaces on the QEMU command line. +(ot choose a machine type earlier than 5.2) + +Thanks, +Laurent + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +Moved to https://gitlab.com/qemu-project/qemu/-/issues/332 + +So it's a virtio console issue on a windows host. + +[#0 init_stage2(2:2)]: VirtIOConsole: Found @ PCI [0000:00:04:00] +[#0 init_stage2(2:2)]: Trying to unregister unused handler (?) +[#0 init_stage2(2:2)]: VirtIOConsole: Multi port is not yet supported! +[#0 init_stage2(2:2)]: VirtIOConsole: cols: 0, rows: 0, max nr ports 0 +qemu-system-i386.exe: warning: GLib: Too many handles to wait for! + +Laurent? + + +On Mon, Apr 19, 2021 at 04:30:23PM +0200, Laurent Vivier wrote: +> Le 19/04/2021 à 12:39, Stefan Weil a écrit : +> > I can confirm the issue also with latest official QEMU sources. +> > +> > Related issue URLs: +> > +> > https://github.com/tesseract-ocr/tesseract/issues/2838 +> > +> > https://bugs.launchpad.net/qemu/+bug/1924912 +> > +> > Instructions and files required to reproduce the issue: +> > +> > https://qemu.weilnetz.de/test/bugs/1924912/ +> > +> > Michael, Laurent, maybe you have an idea how to narrow down this issue? +> +> Could it be related to the number of file descriptors that can differ between linux an windows? +> +> We have a series of patches that sets the number of queues to the number of vCPU: +> +> a4eef0711b2c vhost-user-blk-pci: default num_queues to -smp N +> 9445e1e15e66 virtio-blk-pci: default num_queues to -smp N +> 6a558822849f virtio-scsi-pci: default num_queues to -smp N +> 4e5163bd8444 virtio-scsi: introduce a constant for fixed virtqueues +> 1436f32a84c3 virtio-pci: add virtio_pci_optimal_num_queues() helper +> +> And I think it can have inpact on the number of open file descriptors. +> +> You can try by specifiying "num_queues=1" with the virtio interfaces on the QEMU command line. +> (ot choose a machine type earlier than 5.2) +> +> Thanks, +> Laurent + + + +Le 26/05/2021 à 11:47, mst a écrit : +> So it's a virtio console issue on a windows host. +> +> [#0 init_stage2(2:2)]: VirtIOConsole: Found @ PCI [0000:00:04:00] +> [#0 init_stage2(2:2)]: Trying to unregister unused handler (?) +> [#0 init_stage2(2:2)]: VirtIOConsole: Multi port is not yet supported! +> [#0 init_stage2(2:2)]: VirtIOConsole: cols: 0, rows: 0, max nr ports 0 +> qemu-system-i386.exe: warning: GLib: Too many handles to wait for! +> +> Laurent? + +I will answer on gitlab issue: + +https://gitlab.com/qemu-project/qemu/-/issues/332 + + diff --git a/results/classifier/118/unknown/1926497 b/results/classifier/118/unknown/1926497 new file mode 100644 index 00000000..a15b19d7 --- /dev/null +++ b/results/classifier/118/unknown/1926497 @@ -0,0 +1,158 @@ +risc-v: 0.919 +device: 0.909 +semantic: 0.900 +user-level: 0.898 +performance: 0.896 +architecture: 0.894 +peripherals: 0.889 +permissions: 0.883 +graphic: 0.881 +register: 0.874 +assembly: 0.870 +PID: 0.868 +ppc: 0.852 +arm: 0.846 +VMM: 0.837 +boot: 0.836 +vnc: 0.834 +kernel: 0.827 +files: 0.824 +network: 0.817 +hypervisor: 0.815 +virtual: 0.812 +debug: 0.809 +KVM: 0.805 +TCG: 0.794 +x86: 0.787 +socket: 0.781 +mistranslation: 0.767 +i386: 0.735 + +dp83932 stops working after a short while + +Following the instructions here https://wiki.qemu.org/Documentation/Platforms/m68k I was able to successfully install debian. However, running apt-get update stalls after the first 1-2MB. + +root@debian:~# apt-get update +Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB] +Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease +Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 kB] +18% [2 Packages 2,155 kB/8,735 kB 25%] + +After running apt-get update. I don't seem to be able to send any packets anymore. ping host lookups fail and a subsequent apt-get update makes no progress. + +I'm launching qemu with: + + qemu-system-m68k -boot c \ + -M q800 -serial none -serial mon:stdio -m 1000M \ + -net nic,model=dp83932 -net user \ + -append "root=/dev/sda2 rw console=ttyS0 console=tty" \ + -kernel vmlinux-4.16.0-1-m68k \ + -initrd initrd.img-4.16.0-1-m68k \ + -drive file=m68k-deb10.qcow2,format=qcow2 \ + -nographic + +I see this with qemu v6.0.0-rc5 + +I also see the same problem with version 4.2.1 + +I think you must use a more recent kernel because some bugs have been fixed in QEMU and kernel that need both of them in sync. + +Could you extract the kernel from your m68k disk image to use it with QEMU "-kernel" and "-initrd" parameters? + +The kernel in my m68k disk image is vmlinux-4.16.0-1-m68k which is presumably what comes from https://cdimage.debian.org/cdimage/ports/10.0/m68k/iso-cd/debian-10.0-m68k-NETINST-1.iso. Is there a debian image that uses a newer kernel? + +It looks like using https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/debian-10.0.0-m68k-NETINST-1.iso instead fixes the issue. Perhaps the instruction on https://wiki.qemu.org/Documentation/Platforms/m68k should be updated. + +On Wed, Apr 28, 2021 at 11:31 PM Jeff <email address hidden> wrote: +> +> It looks like using +> https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/debian-10.0.0 +> -m68k-NETINST-1.iso instead fixes the issue. Perhaps the instruction on +> https://wiki.qemu.org/Documentation/Platforms/m68k should be updated. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1926497 +> +> Title: +> dp83932 stops working after a short while +> +> Status in QEMU: +> New +> +> Bug description: +> Following the instructions here +> https://wiki.qemu.org/Documentation/Platforms/m68k I was able to +> successfully install debian. However, running apt-get update stalls +> after the first 1-2MB. +> +> root@debian:~# apt-get update +> Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB] +> Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease +> Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 kB] +> 18% [2 Packages 2,155 kB/8,735 kB 25%] +> +> After running apt-get update. I don't seem to be able to send any +> packets anymore. ping host lookups fail and a subsequent apt-get +> update makes no progress. +> +> I'm launching qemu with: +> +> qemu-system-m68k -boot c \ +> -M q800 -serial none -serial mon:stdio -m 1000M \ +> -net nic,model=dp83932 -net user \ +> -append "root=/dev/sda2 rw console=ttyS0 console=tty" \ +> -kernel vmlinux-4.16.0-1-m68k \ +> -initrd initrd.img-4.16.0-1-m68k \ +> -drive file=m68k-deb10.qcow2,format=qcow2 \ +> -nographic +> +> I see this with qemu v6.0.0-rc5 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1926497/+subscriptions + +I've updated the page to include: + +Please note that the instructions below use kernel versions that might +have been superseded by newer ones on the most recent installation cd +images! Also, during installation on hard disk image the update +process might install a newer kernel. Always make sure to extract the +latest kernel and initrd.gz from your hard disk image after +installation or update and replace the kernel names in the examples +below with what is currently installed. + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1926782 b/results/classifier/118/unknown/1926782 new file mode 100644 index 00000000..f1d44f9b --- /dev/null +++ b/results/classifier/118/unknown/1926782 @@ -0,0 +1,93 @@ +KVM: 0.886 +TCG: 0.884 +VMM: 0.881 +risc-v: 0.869 +x86: 0.869 +hypervisor: 0.861 +vnc: 0.860 +network: 0.859 +i386: 0.859 +arm: 0.856 +kernel: 0.855 +performance: 0.855 +permissions: 0.854 +assembly: 0.853 +PID: 0.853 +architecture: 0.852 +files: 0.851 +semantic: 0.850 +debug: 0.850 +peripherals: 0.849 +graphic: 0.847 +mistranslation: 0.846 +register: 0.845 +user-level: 0.845 +virtual: 0.845 +device: 0.844 +socket: 0.844 +ppc: 0.830 +boot: 0.830 + +configure script --extra-cflags not passed to config-meson.cross + +Since qemu 5.2, when building, the configure would not finish, but would return this error instead: + + qemu ../meson.build:852:2: ERROR: C header 'sasl/sasl.h' not found + +This is for a cross build, and I invoke qemu with the --extra-cflags and --extra-ldflags containing all the proper paths to the headers, libraries etc. It worked properly with qemu 3.1 to 5.1. + +After looking into the configure script, it seems that meson is passed the CFLAGS environment variable instead of QEMU_CFLAGS, and only the latter contains the --extra-cflags argument: + + echo "c_args = [${CFLAGS:+$(meson_quote $CFLAGS)}]" >> $cross + +Using the CFLAGS and LDFLAGS environment variable instead of --extra-cflags and --extra-ldflags fixes the issue. + +Here is my full invocation of the configure script: + +CFLAGS=" -isystem /home/anisse/dev/qemu-cross/build/usr/include" \ +LDFLAGS="-Wl,--gc-sections -Wl,-Y/home/anisse/dev/qemu-cross/build/lib -Wl,-Y/home/anisse/dev/qemu-cross/build/usr/lib -Wl,-rpath-link,/home/anisse/dev/qemu-cross/build/lib -Wl,-rpath-link,/home/anisse/dev/qemu-cross/build/usr/lib" \ +PKG_CONFIG=pkg-config \ +PKG_CONFIG_LIBDIR="/home/anisse/dev/qemu-cross/build/usr/lib/pkgconfig" \ +PKG_CONFIG_SYSROOT_DIR="/home/anisse/dev/qemu-cross/build" \ +./configure $(cat ../features) --enable-vnc --enable-vnc-sasl --enable-vnc-jpeg --enable-vnc-png --target-list=aarch64-softmmu --cross-prefix=/opt/toolchains/aarch64-musl-1.2.2-gcc-10.2.0-binutils-2.36-gdb-7.12.1-1/bin/aarch64-linux-musl- + +And the content of the ./features file: + +--enable-system --disable-user --disable-linux-user --disable-bsd-user --disable-docs --disable-guest-agent --disable-guest-agent-msi --enable-pie --disable-modules --disable-module-upgrades --disable-debug-tcg --disable-debug-info --disable-sparse --disable-safe-stack --disable-gnutls --disable-nettle --disable-gcrypt --disable-auth-pam --disable-sdl --disable-sdl-image --disable-gtk --disable-vte --disable-curses --disable-iconv --enable-vnc --enable-vnc-sasl --enable-vnc-jpeg --enable-vnc-png --disable-cocoa --disable-virtfs --disable-virtiofsd --disable-libudev --disable-mpath --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-curl --enable-membarrier --enable-fdt --enable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-pvrdma --disable-vde --disable-netmap --disable-linux-aio --disable-linux-io-uring --disable-cap-ng --disable-attr --enable-vhost-net --enable-vhost-vsock --enable-vhost-scsi --enable-vhost-crypto --enable-vhost-kernel --enable-vhost-user --disable-vhost-user-blk-server --disable-vhost-vdpa --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-u2f --enable-libusb --disable-live-block-migration --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-lzfse --disable-zstd --disable-seccomp --disable-coroutine-pool --disable-glusterfs --disable-tpm --disable-libssh --disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc --disable-avx2 --disable-avx512f --disable-replication --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --enable-tools --disable-bochs --disable-cloop --disable-dmg --enable-qcow1 --enable-vdi --disable-vvfat --disable-qed --disable-parallels --disable-sheepdog --enable-crypto-afalg --disable-capstone --disable-debug-mutex --disable-libpmem --disable-xkbcommon --disable-rng-none --disable-libdaxctl + + +Sorry, this is the "fixed" version, but you get the idea of how I invoke it. sasl.h is present in +/home/anisse/dev/qemu-cross/build/usr/include/sasl/sasl.h ; this path is passed through -isystem. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/1967814 b/results/classifier/118/unknown/1967814 new file mode 100644 index 00000000..42e43333 --- /dev/null +++ b/results/classifier/118/unknown/1967814 @@ -0,0 +1,455 @@ +KVM: 0.889 +register: 0.882 +kernel: 0.870 +PID: 0.869 +arm: 0.863 +graphic: 0.863 +assembly: 0.859 +vnc: 0.853 +virtual: 0.847 +permissions: 0.847 +architecture: 0.846 +debug: 0.844 +network: 0.840 +ppc: 0.839 +VMM: 0.839 +boot: 0.839 +performance: 0.835 +socket: 0.835 +x86: 0.835 +TCG: 0.834 +semantic: 0.823 +peripherals: 0.823 +hypervisor: 0.822 +device: 0.822 +files: 0.811 +user-level: 0.794 +risc-v: 0.762 +mistranslation: 0.746 +i386: 0.740 + +Ubuntu 20.04.3 - ilzlnx3g1 - virtio-scsi devs on KVM guest having miscompares on disktests when there is a failed path. + +== Comment: #63 - Halil Pasic <email address hidden> - 2022-03-28 17:33:34 == +I'm pretty confident I've figured out what is going on. + +From the guest side, the decision whether the SCSI command was completed successfully or not comes down to looking at the sense data. Prior to commit +a108557bbf ("scsi: inline sg_io_sense_from_errno() into the callers."), we don't +build sense data as a response to seeing a host status presented by the host SCSI stack (e.g. kernel). + +Thus when the kernel tells us that a given SCSI command did not get completed via +SCSI_HOST_TRANSPORT_DISRUPTED or SCSI_HOST_NO_LUN, we end up fooling the guest into believing that the command completed successfully. + +The guest kernel, and especially virtio and multipath are at no fault (AFAIU). Given these facts, it isn't all that surprising, that we end up with corruptions. + +All we have to do is do backports for QEMU (when necessary). I didn't investigate vhost-scsi -- my guess is, that it ain't affected. + +How do we want to handle the back-ports? + +== Comment: #66 - Halil Pasic <email address hidden> - 2022-04-04 05:36:33 == +This is a proposed backport containing 7 patches in mbox format. I tried to pick patches sanely, and all I had to do was basically resolving merge conflicts. + +I have to admit I have no extensive experience in doing such invasive backports, and my knowledge of the QEMU SCSI stack is very limited. I would be happy if the Ubuntu folks would have a good look at this, and if possible improve on it. + +Default Comment by Bridge + +Default Comment by Bridge + +Changing the affected package from "linux (Ubuntu)" (kernel) to "qemu (Ubuntu)" as affected package, since the attached patch set is for qemu. + +List of original commits and the version they were in: + +v5.2.0 +commit 3b12a7fd39307017c8968b8d05986a63b33752b5 +Author: Paolo Bonzini <email address hidden> +Date: Thu Nov 12 10:52:04 2020 +0100 + scsi-disk: convert more errno values back to SCSI statuses + +v6.0.0 +commit f95f61c2c9618fae7d8ea4c1d63e7416884bad52 +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 24 13:14:07 2021 +0100 + scsi-disk: move scsi_handle_rw_error earlier + +v6.0.0 +commit d7a84021db8eeddcd5d24ab591a1434763caff6c +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 24 16:30:09 2021 +0100 + scsi: introduce scsi_sense_from_errno() + +v6.0.0 +commit f63c68bc0f514694a958b2e84a204b7792d28b17 +Author: Paolo Bonzini <email address hidden> +Date: Wed Feb 24 18:59:36 2021 +0100 + scsi-disk: pass SCSI status to scsi_handle_rw_error + +v6.0.0 +commit 41af878b96582fc8c83303ab8921e40468403702 +Author: Hannes Reinecke <email address hidden> +Date: Mon Nov 16 19:40:38 2020 +0100 + scsi: Rename linux-specific SG_ERR codes to generic SCSI_HOST error codes + +v6.0.0 +commit db66a15cb80f09da24a5311a3f3b8f0c1835bf71 +Author: Hannes Reinecke <email address hidden> +Date: Mon Nov 16 19:40:39 2020 +0100 + scsi: Add mapping for generic SCSI_HOST status to sense codes + +v6.0.0 +commit a108557bbff8a3f44233982f015f996426411be8 +Author: Hannes Reinecke <email address hidden> +Date: Mon Nov 16 19:40:40 2020 +0100 + scsi: inline sg_io_sense_from_errno() into the callers. + +Thereby indeed this is only for Focal. +Sorry, but analyzing the details will take more time... + +I can confirm that just on the patch-level only two need backporting, the rest applies as is and I have regenerated them to match the packaging requirements. The backport-adaptations themselves are minimal. + +From the content I guess it is complex enough that nobody can be fully sure. +I'm still reading it ... + +Until then a few questions: +- I wonder if we'd also want/need dc293f6 "scsi: fix sense code for EREMOTEIO" (to ensure this kind of ioerror gets to the guest as well) - what do you think? +- I also wondered about 424740d "scsi-disk: do not complete requests early for rerror/werror=ignore" but we do not have 40dce4ee applied so that should be ok + +I'm done reading and while a complex subsystem and a bunch of changes they individually all seem sane to me (although a108557b could have side effects that are hard to spot). + +For SRU considerations I think this includes potential change of behavior of formerly silently ignored errors now becoming visible (or with more detail) to the guest. But IMHO silently hiding I/O errors is asking for problems and data corruption (just as you've found it=, while reporting them is correct. + +I'll later build a PPA for your testing as you seem to have a testcase with Disktest on your side that can reproduce the issue that made you aware. + +Prepared +PPA: https://launchpad.net/~paelzer/+archive/ubuntu/lp-1967814-scsi-error-handling/+packages +MP: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/418636 + +Let us see if one builds and tests fine and the other gets positive review feedback. + +------- Comment From <email address hidden> 2022-04-06 09:24 EDT------- +(In reply to comment #76) +> I can confirm that just on the patch-level only two need backporting, the +> rest applies as is and I have regenerated them to match the packaging +> requirements. The backport-adaptations themselves are minimal. +> +> From the content I guess it is complex enough that nobody can be fully sure. +> I'm still reading it ... +> +> Until then a few questions: +> - I wonder if we'd also want/need dc293f6 "scsi: fix sense code for +> EREMOTEIO" (to ensure this kind of ioerror gets to the guest as well) - what +> do you think? +> - I also wondered about 424740d "scsi-disk: do not complete requests early +> for rerror/werror=ignore" but we do not have 40dce4ee applied so that should +> be ok + +I have nothing against including those. I was under the impression that a minimal fix is desired, and my tests indicate that dose patches are not strictly necessary. + +Generally I think that those are good patches, and having them is better than not having them. But then I hope most of the patches are good patches, and obviously backporting all the good patches is not very practicable -- hence the principle of minimality. + +It is just my two cents. My understanding of SCSI is quite poor. + +You are right for a general stance of SRU minimality + +But this case felt like fixing 7/8 of a single whole. +And while indeed your case didn't need this one more fix someone else would and we touch this code anyway. Vice versa all tests since this is upstream is done with it applied - so the coverage of the code with this added is better than without - so we also avoid unexpected side effects. +OTOH We would not fix something totally else like something in virtio as part of this, no matter how reasonable that patch might look like. + +Let me know if you had time to push the PPA through your testing. + +------- Comment From <email address hidden> 2022-04-07 18:42 EDT------- +(In reply to comment #80) +> Let me know if you had time to push the PPA through your testing. + +Pulled the PPA + +root@ilzlnx3:~# apt info qemu +Package: qemu +Version: 1:4.2-3ubuntu6.22~focalppa1 + +I triggered a path failure from the host and saw the faulty paths on the guest but no data miscompares (first time I've ever seen it not having miscompares at the first try). +Recovered and tried again, this time I did got the miscompares, I captured the DBGINFO and sosreport, let me know if something else is needed. + +********** EXPECTED (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: 1243520, Offset: 5) ********** +00000000 00 00 00 00 00 12 F9 80 00 00 00 00 00 00 00 01 ................ +00000010 00 00 00 00 62 4F 60 1C 00 00 00 00 00 00 06 EB ....bO`......... +00000020 69 6C 7A 6C 6E 78 33 67 31 00 00 00 00 00 00 00 ilzlnx3g1....... +00000030 2F 66 63 2F 6D 61 70 70 65 72 2F 73 63 73 69 5F /fc/mapper/scsi_ +00000040 33 32 47 5F 64 31 5F 69 6C 73 64 39 38 34 30 6C 32G_d1_ilsd9840l + +********** ACTUAL (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: 1243520, Offset: 5) ********** +00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + + +------- Comment (attachment only) From <email address hidden> 2022-04-07 18:43 EDT------- + + + +------- Comment (attachment only) From <email address hidden> 2022-04-07 18:44 EDT------- + + +------- Comment From <email address hidden> 2022-04-08 05:13 EDT------- +(In reply to comment #81) +> (In reply to comment #80) +> > Let me know if you had time to push the PPA through your testing. +> +> Pulled the PPA +> +> root@ilzlnx3:~# apt info qemu +> Package: qemu +> Version: 1:4.2-3ubuntu6.22~focalppa1 +> +> I triggered a path failure from the host and saw the faulty paths on the +> guest but no data miscompares (first time I've ever seen it not having +> miscompares at the first try). +> Recovered and tried again, this time I did got the miscompares, I captured +> the DBGINFO and sosreport, let me know if something else is needed. +> +> ********** EXPECTED (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: +> 1243520, Offset: 5) ********** +> 00000000 00 00 00 00 00 12 F9 80 00 00 00 00 00 00 00 01 +> ................ +> 00000010 00 00 00 00 62 4F 60 1C 00 00 00 00 00 00 06 EB +> ....bO`......... +> 00000020 69 6C 7A 6C 6E 78 33 67 31 00 00 00 00 00 00 00 +> ilzlnx3g1....... +> 00000030 2F 66 63 2F 6D 61 70 70 65 72 2F 73 63 73 69 5F +> /fc/mapper/scsi_ +> 00000040 33 32 47 5F 64 31 5F 69 6C 73 64 39 38 34 30 6C +> 32G_d1_ilsd9840l +> +> ********** ACTUAL (Target: /fc/mapper/scsi_32G_d1_ilsd9840l/test, LBA: +> 1243520, Offset: 5) ********** +> 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ +> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ +> 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ +> 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +> ................ + +That is very bad news! :( + +I was not able to trigger the problem with the patched qemu. I will try harder, but if I can't trigger the problem it becomes very difficult for me to work on it. + +------- Comment From <email address hidden> 2022-04-08 05:20 EDT------- +(In reply to comment #81) +> (In reply to comment #80) +> > Let me know if you had time to push the PPA through your testing. +> +> Pulled the PPA +> +> root@ilzlnx3:~# apt info qemu +> Package: qemu +> Version: 1:4.2-3ubuntu6.22~focalppa1 +> +> I triggered a path failure from the host and saw the faulty paths on the +> guest but no data miscompares (first time I've ever seen it not having +> miscompares at the first try). +> Recovered and tried again, this time I did got the miscompares, I captured +> the DBGINFO and sosreport, let me know if something else is needed. + +Maybe we are hitting a different case. Maybe not. In the past we used to observe multiple types of miscompares one of which is the all zero, and another one is wrong but still disktest data. + +I'm curious if we see the wrong disktest data type of miscompare with the patched qemu. + +Also I would like to know if the miscompare is still observable after a reboot (i.e. if you destroy and re-start the guest, and then do a manual compare with disktest on the given block (without the write phase). + +Also can I help you install a self-built upstream qemu so we can test with that as well? Maybe we are just missing some more patches. + +Thanks Vanessa for the testing on the PPA! + +@Halil - I'd leave the debugging of the remaining issue to you as while you can't reproduce it yet it still is much closer to you than it is to me :-/ Thanks in advance, let us know what you find. + +In the meantime I have prepared the SRU content and got a PR review, so once we are convinced it is good - or found what we need to change - we should be ready to continue. + +------- Comment From <email address hidden> 2022-04-25 19:20 EDT------- +(In reply to comment #94) +> Thanks Vanessa for the testing on the PPA! +> +> @Halil - I'd leave the debugging of the remaining issue to you as while you +> can't reproduce it yet it still is much closer to you than it is to me :-/ +> Thanks in advance, let us know what you find. +> +> In the meantime I have prepared the SRU content and got a PR review, so once +> we are convinced it is good - or found what we need to change - we should be +> ready to continue. + +I was not testing the PPA you provided properly, I pulled it again and made sure it was installed and running: + +root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22~focalppa1) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +I ran the error injects for a few hours and no miscompares were encountered. +Thanks @Halil, for bringing the issue to my attention! + +------- Comment From <email address hidden> 2022-04-28 05:22 EDT------- +(In reply to comment #97) +> (In reply to comment #94) +> > Thanks Vanessa for the testing on the PPA! +> > +> > @Halil - I'd leave the debugging of the remaining issue to you as while you +> > can't reproduce it yet it still is much closer to you than it is to me :-/ +> > Thanks in advance, let us know what you find. +> > +> > In the meantime I have prepared the SRU content and got a PR review, so once +> > we are convinced it is good - or found what we need to change - we should be +> > ready to continue. +> +> I was not testing the PPA you provided properly, I pulled it again and made +> sure it was installed and running: +> +> root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +> QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22~focalppa1) +> Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +> +> I ran the error injects for a few hours and no miscompares were encountered. +> Thanks @Halil, for bringing the issue to my attention! + +@Ubuntu: I think we can and should move forward with this. The problem with the +previous test results is, that the qemu from the PPA wasn't installed at all, and thus we ended up just verifying that the old one is still broken. + +I read Vanessas comment like, she the issue is not observed any more with the PPA installed: i.e. the fix works at least for the test-case that used to trigger the problem reliably. @Vanessa: Please correct me if I'm wrong. + +------- Comment From <email address hidden> 2022-04-28 18:36 EDT------- +(In reply to comment #98) +> +> @Ubuntu: I think we can and should move forward with this. The problem with +> the +> previous test results is, that the qemu from the PPA wasn't installed at +> all, and thus we ended up just verifying that the old one is still broken. +> +> I read Vanessas comment like, she the issue is not observed any more with +> the PPA installed: i.e. the fix works at least for the test-case that used +> to trigger the problem reliably. @Vanessa: Please correct me if I'm wrong. + +That is correct, the fix works, no miscompares while doing the test-case I've been using to reproduce this issue (tested for a few hours, no more than 30 seconds in between error injects). + +root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22~focalppa1) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Following up on some older bugs... +Okay, that means the PPA version of qemu for focal could be successfully verified (no miss-compares). +So I'll change the status back to In Progress ... + +Thanks for the pre-check. +Everything is ready and now uploaded to Focal, there please verify it on the real build once accepted by the SRU team. + +Hello bugproxy, or anyone else affected, + +Accepted qemu into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.22 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! + +N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. + +I've accepted this, and I agree that this is a good candidate for testing in proposed for longer than 7 days; I'll do so after at least 14 days, so double the normal soak time. + +All autopkgtests for the newly accepted qemu (1:4.2-3ubuntu6.22) for focal have finished running. +The following regressions have been reported in tests triggered by the package: + +ubuntu-image/1.11+20.04ubuntu1 (amd64) + + +Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. + +https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#qemu + +[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions + +Thank you! + + +That was a flaky test, resolved by now. + +This bug was fixed in the package qemu - 1:4.2-3ubuntu6.23 + +--------------- +qemu (1:4.2-3ubuntu6.23) focal-security; urgency=medium + + * SECURITY UPDATE: heap overflow in floppy disk emulator + - debian/patches/CVE-2021-3507.patch: prevent end-of-track overrun in + hw/block/fdc.c. + - CVE-2021-3507 + * SECURITY UPDATE: integer overflow in QXL display device emulation + - debian/patches/CVE-2021-4206.patch: check width and height in + hw/display/qxl-render.c, hw/display/vmware_vga.c, ui/cursor.c. + - CVE-2021-4206 + * SECURITY UPDATE: heap overflow in QXL display device emulation + - debian/patches/CVE-2021-4207.patch: fix race condition in qxl_cursor + in hw/display/qxl-render.c. + - CVE-2021-4207 + * SECURITY UPDATE: memory leakage in virtio-net device + - debian/patches/CVE-2022-26353.patch: fix map leaking on error during + receive in hw/net/virtio-net.c. + - CVE-2022-26353 + * SECURITY UPDATE: memory leakage in vhost-vsock device + - debian/patches/CVE-2022-26354.patch: detach the virqueue element in + case of error in hw/virtio/vhost-vsock.c. + - CVE-2022-26354 + + -- Marc Deslauriers <email address hidden> Thu, 09 Jun 2022 11:35:04 -0400 + +------- Comment From <email address hidden> 2022-06-21 11:20 EDT------- +(In reply to comment #105) +> If this package fixes the bug for you, please add a comment to this bug, +> mentioning the version of the package you tested, what testing has been +> performed on the package and change the tag from verification-needed-focal +> to verification-done-focal. If it does not fix the bug for you, please add a +> comment stating that, and change the tag to verification-failed-focal. In +> either case, without details of your testing we will not be able to proceed. +> +Tested this fix and it has solved the issue. Tested with the following version: + +root@ilzlnx3:~# /usr/bin/qemu-system-s390x --version +QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.22) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +Testing performed: +HostSidePortBounce: +1. Run I/O on mapped LUNs +2. Disable one port on host side and wait for 10 minutes +3. Enable the port and wait for 10 minutes +4. Repeat step b and c with the other ports +5. Check I/O tool logs + +Passed. No miscompares or error logs. + +Switch Reboot: +1. Start IO on mapped LUNs +2. Reload brocade/cisco switch and wait for 5 minutes after switch online for host recovery +3. Check I/O tool logs + +Passed. No miscompares or error logs. + +SVC Node reset: +1. Run I/O on mapped LUNs +2. Execute anode reset warm start script against the cluster. +3. Check both I/O logs and script logs + +Passed. No miscompares or error logs. + +zMpath failover failback +1. Run I/O on mapped LUN +2. Vary off one chpid of a lpar and wait for 60 seconds +3. Vary on the chpid ofthe lpar and wait for 20 minutes +4. Repeat step b and c with the other chpids of the lpar +5. Check logs of I/O tool + +Passed. No miscompares or error logs. + +> Further information regarding the verification process can be found at +> https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in +> advance for helping! + +Thanks for the patience awaiting testing and for all the effort + diff --git a/results/classifier/118/unknown/1972 b/results/classifier/118/unknown/1972 new file mode 100644 index 00000000..7f5a3071 --- /dev/null +++ b/results/classifier/118/unknown/1972 @@ -0,0 +1,69 @@ +performance: 0.883 +virtual: 0.876 +graphic: 0.873 +permissions: 0.858 +register: 0.847 +debug: 0.846 +user-level: 0.840 +peripherals: 0.837 +architecture: 0.827 +risc-v: 0.825 +TCG: 0.820 +arm: 0.818 +KVM: 0.814 +device: 0.812 +VMM: 0.810 +vnc: 0.810 +semantic: 0.803 +assembly: 0.802 +files: 0.799 +boot: 0.798 +network: 0.795 +ppc: 0.793 +hypervisor: 0.777 +PID: 0.775 +mistranslation: 0.769 +i386: 0.758 +kernel: 0.756 +socket: 0.743 +x86: 0.736 + +Windows TCG plugin build fails with mingw cross-compile images +Description of problem: +It looks like the mingw variants of the compiler are sensitive to the order of linking: + +``` +bash-5.2$ x86_64-w64-mingw32-gcc -m64 -mcx16 plugins/qemu_plugin_api.lib -o tests/plugin/libinsn.dll tests/plugin/libinsn.dll.p/insn.c.obj tests/plugin/libinsn.dll.p/.._.._contrib_plugins_win32_linker.c.obj plugins/qemu_plugin_api.lib -Wl,--allow-shlib-undefined -shared -Wl,--start-group -Wl,--out-implib=tests/plugin/libinsn.dll.a -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--warn-common /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libglib-2.0.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libintl.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libgmodule-2.0.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group +bash-5.2$ x86_64-w64-mingw32-gcc -m64 -mcx16 plugins/qemu_plugin_api.lib -o tests/plugin/libinsn.dll tests/plugin/libinsn.dll.p/insn.c.obj tests/plugin/libinsn.dll.p/.._.._contrib_plugins_win32_linker.c.obj -Wl,--allow-shlib-undefined -shared -Wl,--start-group -Wl,--out-implib=tests/plugin/libinsn.dll.a -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--warn-common /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libglib-2.0.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libintl.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libgmodule-2.0.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: tests/plugin/libinsn.dll.p/insn.c.obj: in function `vcpu_tb_trans': +/tmp/qemu-test/build/../src/tests/plugin/insn.c:90: undefined reference to `__imp_qemu_plugin_tb_n_insns' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:100: undefined reference to `__imp_qemu_plugin_insn_vaddr' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:97: undefined reference to `__imp_qemu_plugin_register_vcpu_insn_exec_inline' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:94: undefined reference to `__imp_qemu_plugin_tb_get_insn' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:101: undefined reference to `__imp_qemu_plugin_register_vcpu_insn_exec_cb' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:107: undefined reference to `__imp_qemu_plugin_insn_size' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:121: undefined reference to `__imp_qemu_plugin_insn_disas' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:130: undefined reference to `__imp_qemu_plugin_register_vcpu_insn_exec_cb' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: tests/plugin/libinsn.dll.p/insn.c.obj: in function `plugin_exit': +/tmp/qemu-test/build/../src/tests/plugin/insn.c:168: undefined reference to `__imp_qemu_plugin_outs' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:168: undefined reference to `__imp_qemu_plugin_outs' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:168: undefined reference to `__imp_qemu_plugin_outs' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: tests/plugin/libinsn.dll.p/insn.c.obj: in function `vcpu_insn_matched_exec_before': +/tmp/qemu-test/build/../src/tests/plugin/insn.c:83: undefined reference to `__imp_qemu_plugin_outs' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: tests/plugin/libinsn.dll.p/insn.c.obj: in function `qemu_plugin_install': +/tmp/qemu-test/build/../src/tests/plugin/insn.c:199: undefined reference to `__imp_qemu_plugin_bool_parse' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:215: undefined reference to `__imp_qemu_plugin_register_vcpu_tb_trans_cb' +/usr/lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld: /tmp/qemu-test/build/../src/tests/plugin/insn.c:216: undefined reference to `__imp_qemu_plugin_register_atexit_cb' +collect2: error: ld returned 1 exit status + + +If you move the qemu_plugin_api.lib to after the other .obj files, it works: + +bash-5.2$ x86_64-w64-mingw32-gcc -m64 -mcx16 plugins/qemu_plugin_api.lib -o tests/plugin/libinsn.dll tests/plugin/libinsn.dll.p/insn.c.obj tests/plugin/libinsn.dll.p/.._.._contrib_plugins_win32_linker.c.obj plugins/qemu_plugin_api.lib -Wl,--allow-shlib-undefined -shared -Wl,--start-group -Wl,--out-implib=tests/plugin/libinsn.dll.a -fstack-protector-strong -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--warn-common /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libglib-2.0.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libintl.dll.a /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libgmodule-2.0.dll.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group +bash-5.2$ echo $? +0 +``` +Steps to reproduce: +``` +make docker-test-build@fedora-win64-cross J=30 V=1 EXTRA_CONFIGURE_OPTS="--enable-fdt=internal --enable-plugins" NETWORK=1 +``` diff --git a/results/classifier/118/unknown/2063 b/results/classifier/118/unknown/2063 new file mode 100644 index 00000000..5849af0e --- /dev/null +++ b/results/classifier/118/unknown/2063 @@ -0,0 +1,85 @@ +risc-v: 0.878 +mistranslation: 0.869 +KVM: 0.868 +peripherals: 0.867 +TCG: 0.866 +performance: 0.862 +vnc: 0.857 +virtual: 0.842 +hypervisor: 0.842 +i386: 0.840 +user-level: 0.838 +assembly: 0.832 +VMM: 0.830 +socket: 0.829 +permissions: 0.829 +semantic: 0.829 +network: 0.827 +x86: 0.826 +arm: 0.826 +debug: 0.825 +device: 0.823 +kernel: 0.822 +ppc: 0.821 +architecture: 0.820 +register: 0.816 +files: 0.811 +graphic: 0.791 +PID: 0.789 +boot: 0.784 + +Poor performance with -accel whpx on Server 2022 host, windows 10 guest - missing CPUID hypervisor ident data? +Description of problem: +**Performance of Windows 10 x64 QEMU virtual machine is essentially unusable, compared to same image running under Hyper-V on the same host system.** + +It appears the VM is not being provided the Hyper-V enlightenment hints while running under QEMU. The hv-XXX cpu options do not appear applicable to -accel WHPX. + +Below are dumps of the 0x40000000 cpuid values on the host, QEMU guest, and Hyper-V guest (exact same .VHD file used, nested virtualization not enabled for this VM). + +host: +- 0x40000000 eax=4000000c ebx=7263694d ecx=666f736f edx=76482074 +- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d +- 0x40000003 eax=bfff ebx=2bb9ff ecx=22 edx=71fffbf6 +- 0x40000004 eax=50d1c ebx=fff ecx=0 edx=0 +- 0x40000005 eax=400 ebx=400 ecx=ba00 edx=0 +- 0x40000006 eax=1e00be ebx=0 ecx=0 edx=0 +- 0x40000007 eax=80000007 ebx=3 ecx=0 edx=0 +- 0x40000008 eax=100001 ebx=1 ecx=aaaa edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000c eax=0 ebx=0 ecx=0 edx=0 + +qemu guest with -accel whpx : +- 0x40000000 eax=40000010 ebx=0 ecx=0 edx=0 +- 0x40000001 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000003 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000004 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000005 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000006 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000007 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000008 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000c eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000d eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000e eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000f eax=0 ebx=0 ecx=0 edx=0 +- 0x40000010 eax=225519 ebx=30d40 ecx=0 edx=0 + +hyperv guest VM: (nested virtualization not enabled) +- 0x40000000 eax=4000000b ebx=7263694d ecx=666f736f edx=76482074 +- 0x40000001 eax=31237648 ebx=0 ecx=0 edx=0 +- 0x40000002 eax=4f7c ebx=a0000 ecx=2 edx=85d +- 0x40000003 eax=ae7f ebx=388030 ecx=22 edx=e0bed7b2 +- 0x40000004 eax=40c2c ebx=fff ecx=0 edx=0 +- 0x40000005 eax=f0 ebx=400 ecx=ba00 edx=0 +- 0x40000006 eax=e ebx=0 ecx=0 edx=0 +- 0x40000007 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000008 eax=0 ebx=0 ecx=0 edx=0 +- 0x40000009 eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000a eax=0 ebx=0 ecx=0 edx=0 +- 0x4000000b eax=0 ebx=0 ecx=0 edx=0 diff --git a/results/classifier/118/unknown/2078790 b/results/classifier/118/unknown/2078790 new file mode 100644 index 00000000..11a6e157 --- /dev/null +++ b/results/classifier/118/unknown/2078790 @@ -0,0 +1,690 @@ +virtual: 0.916 +permissions: 0.908 +user-level: 0.900 +KVM: 0.882 +risc-v: 0.880 +device: 0.878 +peripherals: 0.877 +architecture: 0.871 +VMM: 0.869 +kernel: 0.868 +vnc: 0.865 +x86: 0.865 +socket: 0.863 +assembly: 0.856 +network: 0.853 +debug: 0.849 +register: 0.849 +files: 0.846 +PID: 0.846 +arm: 0.845 +graphic: 0.840 +performance: 0.838 +TCG: 0.836 +boot: 0.830 +hypervisor: 0.825 +semantic: 0.821 +mistranslation: 0.795 +i386: 0.758 +ppc: 0.743 + +jammy qemu x86 int3: 0000 [#1] SMP NOPTI + +jammy:linux-lowlatency-hwe-6.8 6.8.0-44.44.1~22.04.1 qemu-x86 QEMU Standard PC (i440FX + PIIX, 1996) + + +Recently (2024.08.05), I have been seeing this issue with ADT:systemd:upstream-1/2 test in which kernel panics/prints a stack. I have seen this with jammy:linux-lowlatency-hwe-6.8 and jammy:linux-ibm-6.8. Stack trace is different everytime because kernel receives an interrupt, drop what it is doing, and crash when handling the interrupt. + +I think this is an issue with qemu and not kernel. For jammy, we are using qemu 6.2 and there are some fixes related to x86 interrupt handling in 8.x (https://<email address hidden>/T/). I propose we create a launchpad bug and trace the issue. If I am correct, we shouldn't see this in noble. And we should occasionally see this in 5.15 jammy kernels (and more frequently with lowlantecy kernels). + + +Meanwhile see comments below for some stack traces; + +jammy:linux-lowlatency-hwe-6.8 6.8.0-44.44.1~22.04.1 qemu-x86 QEMU Standard PC (i440FX + PIIX, 1996) -> ADT:systemd:upstream-2 + +5373s --x-- Running TEST-36-NUMAPOLICY --x-- +5373s + make -C TEST-36-NUMAPOLICY setup run +5373s make: Entering directory '/tmp/autopkgtest.pW1AKT/build.qvP/src/test/TEST-36-NUMAPOLICY' +5373s Specify build directory with $BUILD_DIR +5373s TEST-36-NUMAPOLICY SETUP: test NUMAPolicy= and NUMAMask= options +5373s Reusing existing cached image /tmp/autopkgtest.pW1AKT/build.qvP/src/test/TEST-36-NUMAPOLICY/../default.img → /tmp/autopkgtest.pW1AKT/build.qvP/src/test/default.img +5373s '/var/tmp/systemd-test.Wk9jIZ/default.img' -> '/tmp/autopkgtest.pW1AKT/build.qvP/src/test/default.img' +5373s I: Masking supporting services +5373s '/var/tmp/systemd-test.Wk9jIZ/root/etc/systemd/system/systemd-hwdb-update.service' -> '/dev/null' +5373s '/var/tmp/systemd-test.Wk9jIZ/root/etc/systemd/system/systemd-journal-catalog-update.service' -> '/dev/null' +5373s '/var/tmp/systemd-test.Wk9jIZ/root/etc/systemd/system/systemd-networkd.service' -> '/dev/null' +5373s '/var/tmp/systemd-test.Wk9jIZ/root/etc/systemd/system/systemd-networkd.socket' -> '/dev/null' +5373s '/var/tmp/systemd-test.Wk9jIZ/root/etc/systemd/system/systemd-resolved.service' -> '/dev/null' +5373s Specify build directory with $BUILD_DIR +5373s TEST-36-NUMAPOLICY RUN: test NUMAPolicy= and NUMAMask= options +5374s + /bin/qemu-system-x86_64 -smp 4 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-6.8.0-44-lowlatency -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.Wk9jIZ/default.img -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0 -initrd /boot/initrd.img-6.8.0-44-lowlatency -append 'root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-36.service systemd.wants=end.service' +5374s c[?7l[2J[0mSeaBIOS (version 1.15.0-1) +5384s Booting from ROM..c[?7l[2JLoading, please wait... +5384s Starting version 249.11-0ubuntu3.12 +5386s Begin: Loading essential drivers ... done. +5386s Begin: Running /scripts/init-premount ... done. +5386s Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. +5387s Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems +5387s done. +5387s Begin: Will now check root file system ... fsck from util-linux 2.37.2 +5388s [/usr/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -a -C0 /dev/sda1 +5388s systemd: clean, 2420/115200 files, 46512/115200 blocks +5388s done. +5388s done. +5388s Begin: Running /scripts/local-bottom ... done. +5388s Begin: Running /scripts/init-bottom ... done. +5389s +5389s Welcome to [1mUbuntu 22.04.4 LTS[0m! +5389s +5390s [[0;32m OK [0m] Created slice [0;1;39mSlice /system/modprobe[0m. +5390s [[0;32m OK [0m] Created slice [0;1;39mSlice /system/serial-getty[0m. +5390s [[0;32m OK [0m] Created slice [0;1;39mUser and Session Slice[0m. +5390s [[0;32m OK [0m] Started [0;1;39mDispatch Password …ts to Console Directory Watch[0m. +5390s [[0;32m OK [0m] Started [0;1;39mForward Password R…uests to Wall Directory Watch[0m. +5390s [[0;1;38;5;185mUNSUPP[0m] Starting of [0;1;39mArbitrary Exec…m Automount Point[0m unsupported. +5390s [[0;32m OK [0m] Reached target [0;1;39mLocal Encrypted Volumes[0m. +5390s [[0;32m OK [0m] Reached target [0;1;39mPath Units[0m. +5390s [[0;32m OK [0m] Reached target [0;1;39mSlice Units[0m. +5390s [[0;32m OK [0m] Reached target [0;1;39mSwaps[0m. +5390s [[0;32m OK [0m] Reached target [0;1;39mLocal Verity Protected Volumes[0m. +5390s [[0;32m OK [0m] Listening on [0;1;39mProcess Core Dump Socket[0m. +5390s [[0;32m OK [0m] Listening on [0;1;39minitctl Compatibility Named Pipe[0m. +5390s [[0;32m OK [0m] Listening on [0;1;39mJournal Audit Socket[0m. +5390s [[0;32m OK [0m] Listening on [0;1;39mJournal Socket (/dev/log)[0m. +5390s [[0;32m OK [0m] Listening on [0;1;39mJournal Socket[0m. +5390s [[0;32m OK [0m] Listening on [0;1;39mudev Control Socket[0m. +5390s [[0;32m OK [0m] Listening on [0;1;39mudev Kernel Socket[0m. +5390s [[0;32m OK [0m] Reached target [0;1;39mSockets[0m. +5390s Mounting [0;1;39mHuge Pages File System[0m... +5390s Mounting [0;1;39mPOSIX Message Queue File System[0m... +5390s Mounting [0;1;39mKernel Debug File System[0m... +5390s Mounting [0;1;39mKernel Trace File System[0m... +5390s Starting [0;1;39mJournal Service[0m... +5391s Starting [0;1;39mLoad Kernel Module configfs[0m... +5391s Starting [0;1;39mLoad Kernel Module drm[0m... +5391s Starting [0;1;39mLoad Kernel Module fuse[0m... +5391s Starting [0;1;39mLoad Kernel Modules[0m... +5391s Starting [0;1;39mRemount Root and Kernel File Systems[0m... +5391s Starting [0;1;39mColdplug All udev Devices[0m... +5391s [[0;32m OK [0m] Mounted [0;1;39mHuge Pages File System[0m. +5391s [[0;32m OK [0m] Mounted [0;1;39mPOSIX Message Queue File System[0m. +5391s [[0;32m OK [0m] Mounted [0;1;39mKernel Debug File System[0m. +5391s [[0;32m OK [0m] Mounted [0;1;39mKernel Trace File System[0m. +5391s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Module configfs[0m. +5391s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Module drm[0m. +5391s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Module fuse[0m. +5391s Mounting [0;1;39mFUSE Control File System[0m... +5391s Mounting [0;1;39mKernel Configuration File System[0m... +5391s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Modules[0m. +5391s [[0;32m OK [0m] Finished [0;1;39mRemount Root and Kernel File Systems[0m. +5391s Starting [0;1;39mLoad/Save Random Seed[0m... +5391s Starting [0;1;39mApply Kernel Variables[0m... +5391s Starting [0;1;39mCreate System Users[0m... +5391s [[0;32m OK [0m] Mounted [0;1;39mFUSE Control File System[0m. +5391s [[0;32m OK [0m] Mounted [0;1;39mKernel Configuration File System[0m. +5391s [[0;32m OK [0m] Finished [0;1;39mLoad/Save Random Seed[0m. +5391s [[0;32m OK [0m] Started [0;1;39mJournal Service[0m. +5391s Starting [0;1;39mFlush Journal to Persistent Storage[0m... +5391s [[0;32m OK [0m] Finished [0;1;39mApply Kernel Variables[0m. +5391s [[0;32m OK [0m] Finished [0;1;39mCreate System Users[0m. +5391s Starting [0;1;39mCreate Static Device Nodes in /dev[0m... +5391s [[0;32m OK [0m] Finished [0;1;39mFlush Journal to Persistent Storage[0m. +5391s [[0;32m OK [0m] Finished [0;1;39mCreate Static Device Nodes in /dev[0m. +5391s [[0;32m OK [0m] Reached target [0;1;39mPreparation for Local File Systems[0m. +5391s [[0;32m OK [0m] Reached target [0;1;39mLocal File Systems[0m. +5391s Starting [0;1;39mCreate Volatile Files and Directories[0m... +5391s Starting [0;1;39mRule-based Manage…for Device Events and Files[0m... +5391s [[0;32m OK [0m] Finished [0;1;39mColdplug All udev Devices[0m. +5392s [[0;32m OK [0m] Finished [0;1;39mCreate Volatile Files and Directories[0m. +5392s Starting [0;1;39mRecord System Boot/Shutdown in UTMP[0m... +5392s [[0;32m OK [0m] Finished [0;1;39mRecord System Boot/Shutdown in UTMP[0m. +5392s [[0;32m OK [0m] Started [0;1;39mRule-based Manager for Device Events and Files[0m. +5392s [[0;32m OK [0m] Reached target [0;1;39mSystem Initialization[0m. +5392s [[0;32m OK [0m] Started [0;1;39mDaily Cleanup of Temporary Directories[0m. +5392s [[0;32m OK [0m] Reached target [0;1;39mBasic System[0m. +5392s [[0;32m OK [0m] Reached target [0;1;39mTimers[0m. +5392s [[0;32m OK [0m] Listening on [0;1;39mD-Bus System Message Bus Socket[0m. +5392s Starting [0;1;39m/etc/rc.local Compatibility[0m... +5392s Starting [0;1;39mUser Login Management[0m... +5392s [ 15.916889] rc.local[258]: /etc/rc.local: 2: iptables: not found +5392s [ 15.907320] traps: PANIC: double fault, error_code: 0x0 +5392s [ 15.909893] double fault: 0000 [#1] PREEMPT SMP NOPTI +5392s [ 15.909893] CPU: 3 PID: 252 Comm: systemd-udevd Not tainted 6.8.0-44-lowlatency #44.1~22.04.1-Ubuntu +5392s [ 15.909893] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 +5392s [ 15.911200] RIP: 0010:kmem_cache_alloc+0x93/0x370 +5392s [ 15.911200] Code: 52 02 00 00 41 f6 44 24 0b 04 0f 85 46 02 00 00 45 31 d2 4d 85 e4 0f 84 33 02 00 00 0f 1f 44 00 00 48 c7 44 24 10 00 00 00 00 <49> 8b 04 24 65 48 03 05 d1 e0 7b 52 48 8b 50 08 48 83 78 10 00 48 +5392s [ 15.911200] RSP: 0018:ffffa5d6c03dfbf0 EFLAGS: 4376b202 +5392s [ 15.911200] RAX: ffff95764376b000 RBX: ffff95764376c000 RCX: 0000000005486003 +5392s [ 15.911200] RDX: 0000000005540003 RSI: 000000000003cf80 RDI: ffff95764376b000 +5392s [ 15.911200] RBP: ffffa5d6c03dfc40 R08: 0000000000000000 R09: 0000000000000000 +5392s [ 15.911200] R10: 0000000000000000 R11: 0000000000000000 R12: ffff95764129f600 +5392s [ 15.911200] R13: 0000000000000cc0 R14: 0000000000001000 R15: ffffffffad8f1b10 +5392s [ 15.911200] FS: 000071234826f8c0(0000) GS:ffff95765b180000(0000) knlGS:0000000000000000 +5392s [ 15.911200] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +5392s [ 15.911200] CR2: 000076d1398389c5 CR3: 00000000023c4000 CR4: 00000000000006f0 +5392s [ 15.911200] Call Trace: +5392s [ 15.911200] <#DF> +5392s [ 15.911200] ? show_regs+0x6d/0x80 +5392s [ 15.911200] ? die+0x37/0xa0 +5392s [ 15.911200] ? exc_double_fault+0xf2/0x1c0 +5392s [ 15.911200] ? asm_exc_double_fault+0x1f/0x30 +5392s [ 15.911200] ? getname_flags.part.0+0x30/0x1e0 +5392s [ 15.911200] ? kmem_cache_alloc+0x93/0x370 +5392s [ 15.911200] </#DF> +5392s [ 15.911200] <TASK> +5392s [ 15.911200] ? do_syscall_64+0x8d/0x170 +5392s [ 15.911200] getname_flags.part.0+0x30/0x1e0 +5392s [ 15.911200] getname_flags+0x40/0x70 +5392s [ 15.911200] user_path_at_empty+0x27/0x70 +5392s [ 15.911200] do_faccessat+0x10a/0x2f0 +5392s [ 15.911200] __x64_sys_access+0x1c/0x30 +5392s [ 15.911200] x64_sys_call+0xa08/0x24b0 +5392s [ 15.911200] do_syscall_64+0x81/0x170 +5392s [ 15.911200] ? scheduler_tick+0x14e/0x370 +5392s [ 15.911200] ? invoke_rcu_core+0x51/0x70 +5392s [ 15.911200] ? irqentry_exit+0x20/0x50 +5392s [ 15.915119] ? common_interrupt+0x54/0xb0 +5392s [ 15.915119] ? asm_common_interrupt+0x27/0x40 +5392s [ 15.915119] ? note_gp_changes+0x8f/0xa0 +5392s [ 15.915119] ? rcu_core+0x1d2/0x390 +5392s [ 15.915119] ? rcu_core_si+0xe/0x20 +5392s [ 15.915119] ? handle_softirqs+0xdb/0x340 +5392s [ 15.915119] ? irqentry_exit_to_user_mode+0x7e/0x260 +5392s [ 15.915119] ? irqentry_exit+0x43/0x50 +5392s [ 15.915119] entry_SYSCALL_64_after_hwframe+0x78/0x80 +5392s [ 15.915119] RIP: 0033:0x71234811494b +5392s [ 15.915119] Code: 77 05 c3 0f 1f 40 00 48 8b 15 e1 54 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 f3 0f 1e fa b8 15 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 b1 54 10 00 f7 d8 +5392s [ 15.915119] RSP: 002b:00007fffb16c6918 EFLAGS: 00000246 ORIG_RAX: 0000000000000015 +5392s [ 15.915119] RAX: ffffffffffffffda RBX: 00007fffb16c6920 RCX: 000071234811494b +5392s [ 15.915119] RDX: 00007fffb16c6937 RSI: 0000000000000000 RDI: 00007fffb16c6920 +5392s [ 15.915119] RBP: 00007fffb16c69b0 R08: fefefefefefefeff R09: feff5ae353ff6368 +5392s [ 15.915119] R10: 00007123480b26e0 R11: 0000000000000246 R12: 00007fffb16c6970 +5392s [ 15.915119] R13: 00007fffb16c6970 R14: 00007fffb16c6970 R15: 00007fffb16c69c0 +5392s [ 15.915119] </TASK> +5392s [ 15.915119] Modules linked in: btrfs blake2b_generic xor raid6_pq libcrc32c psmouse i2c_piix4 floppy pata_acpi +5392s [ 15.915119] ---[ end trace 0000000000000000 ]--- +5392s [ 15.915119] RIP: 0010:kmem_cache_alloc+0x93/0x370 +5392s [ 15.915119] Code: 52 02 00 00 41 f6 44 24 0b 04 0f 85 46 02 00 00 45 31 d2 4d 85 e4 0f 84 33 02 00 00 0f 1f 44 00 00 48 c7 44 24 10 00 00 00 00 <49> 8b 04 24 65 48 03 05 d1 e0 7b 52 48 8b 50 08 48 83 78 10 00 48 +5392s [ 15.915119] RSP: 0018:ffffa5d6c03dfbf0 EFLAGS: 4376b202 +5392s [ 15.915119] RAX: ffff95764376b000 RBX: ffff95764376c000 RCX: 0000000005486003 +5392s [ 15.915119] RDX: 0000000005540003 RSI: 000000000003cf80 RDI: ffff95764376b000 +5392s [ 15.915119] RBP: ffffa5d6c03dfc40 R08: 0000000000000000 R09: 0000000000000000 +5392s [ 15.915119] R10: 0000000000000000 R11: 0000000000000000 R12: ffff95764129f600 +5392s [ 15.915119] R13: 0000000000000cc0 R14: 0000000000001000 R15: ffffffffad8f1b10 +5392s [ 15.915119] FS: 000071234826f8c0(0000) GS:ffff95765b180000(0000) knlGS:0000000000000000 +5392s [ 15.915119] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +5392s [ 15.915119] CR2: 000076d1398389c5 CR3: 00000000023c4000 CR4: 00000000000006f0 +5392s [ 15.915119] Kernel panic - not syncing: Fatal exception in interrupt +5392s [ 15.915119] Kernel Offset: 0x2c400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) +5392s [ 15.915119] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- +25295s autopkgtest [03:19:35]: ERROR: timed out on command "su -s /bin/bash root -c set -e; exec /tmp/autopkgtest.pW1AKT/wrapper.sh --artifacts=/tmp/autopkgtest.pW1AKT/upstream-2-artifacts --chdir=/tmp/autopkgtest.pW1AKT/build.qvP/src --env=AUTOPKGTEST_TESTBED_ARCH=amd64 --env=AUTOPKGTEST_TEST_ARCH=amd64 --env=DEB_BUILD_OPTIONS=parallel=4 --env=DEBIAN_FRONTEND=noninteractive --env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS --unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE --unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT --unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME --unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE --unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid --source-profile --stderr=/tmp/autopkgtest.pW1AKT/upstream-2-stderr --stdout=/tmp/autopkgtest.pW1AKT/upstream-2-stdout --tmp=/tmp/autopkgtest.pW1AKT/autopkgtest_tmp --env=AUTOPKGTEST_NORMAL_USER=ubuntu --env=ADT_NORMAL_USER=ubuntu '--env=ADT_TEST_TRIGGERS=linux-meta-lowlatency-hwe-6.8/6.8.0-44.44.1~22.04.1 linux-lowlatency-hwe-6.8/6.8.0-44.44.1~22.04.1 linux-signed-lowlatency-hwe-6.8/6.8.0-44.44.1~22.04.1' --make-executable=/tmp/autopkgtest.pW1AKT/build.qvP/src/debian/tests/upstream-2 -- /tmp/autopkgtest.pW1AKT/build.qvP/src/debian/tests/upstream-2" (kind: test) +25295s autopkgtest [03:19:35]: test upstream-2: -----------------------] +25295s autopkgtest [03:19:35]: test upstream-2: - - - - - - - - - - results - - - - - - - - - - +25295s upstream-2 FAIL timed out +25296s autopkgtest [03:19:36]: test boot-smoke: preparing testbed +25348s autopkgtest [03:20:28]: testbed dpkg architecture: amd64 +25348s autopkgtest [03:20:28]: testbed apt version: 2.4.12 +25348s autopkgtest [03:20:28]: @@@@@@@@@@@@@@@@@@@@ test bed setup + + +jammy:ibm-6.8 6.8.0-1012.12~22.04.1 qemu-x86 QEMU Standard PC (i440FX + PIIX, 1996) -> ADT:systemd:upstream-1 + +3055s TEST-13-NSPAWN-SMOKE RUN: systemd-nspawn smoke test +3055s + /bin/qemu-system-x86_64 -smp 4 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-6.8.0-1008-ibm -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.rYHUnh/nspawn.img -initrd /boot/initrd.img-6.8.0-1008-ibm -append 'root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-13.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-13.service systemd.wants=end.service' +3055s c[?7l[2J[0mSeaBIOS (version 1.15.0-1) +3066s Booting from ROM..c[?7l[2JLoading, please wait... +3067s Starting version 249.11-0ubuntu3.12 +3068s Begin: Loading essential drivers ... done. +3068s Begin: Running /scripts/init-premount ... done. +3068s Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. +3069s Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems +3070s done. +3070s Begin: Will now check root file system ... fsck from util-linux 2.37.2 +3070s [/usr/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -a -C0 /dev/sda1 +3070s systemd: clean, 2418/115200 files, 47699/115200 blocks +3070s done. +3070s done. +3070s Begin: Running /scripts/local-bottom ... done. +3070s Begin: Running /scripts/init-bottom ... done. +3072s +3072s Welcome to [1mUbuntu 22.04.4 LTS[0m! +3072s +3073s [[0;32m OK [0m] Created slice [0;1;39mSlice /system/modprobe[0m. +3073s [[0;32m OK [0m] Created slice [0;1;39mSlice /system/serial-getty[0m. +3073s [[0;32m OK [0m] Created slice [0;1;39mUser and Session Slice[0m. +3073s [[0;32m OK [0m] Started [0;1;39mDispatch Password …ts to Console Directory Watch[0m. +3073s [[0;32m OK [0m] Started [0;1;39mForward Password R…uests to Wall Directory Watch[0m. +3073s [[0;1;38;5;185mUNSUPP[0m] Starting of [0;1;39mArbitrary Exec…m Automount Point[0m unsupported. +3073s [[0;32m OK [0m] Reached target [0;1;39mLocal Encrypted Volumes[0m. +3073s [[0;32m OK [0m] Reached target [0;1;39mPath Units[0m. +3073s [[0;32m OK [0m] Reached target [0;1;39mSlice Units[0m. +3073s [[0;32m OK [0m] Reached target [0;1;39mSwaps[0m. +3073s [[0;32m OK [0m] Reached target [0;1;39mLocal Verity Protected Volumes[0m. +3073s [[0;32m OK [0m] Listening on [0;1;39mProcess Core Dump Socket[0m. +3073s [[0;32m OK [0m] Listening on [0;1;39minitctl Compatibility Named Pipe[0m. +3073s [[0;32m OK [0m] Listening on [0;1;39mJournal Audit Socket[0m. +3073s [[0;32m OK [0m] Listening on [0;1;39mJournal Socket (/dev/log)[0m. +3073s [[0;32m OK [0m] Listening on [0;1;39mJournal Socket[0m. +3073s [[0;32m OK [0m] Listening on [0;1;39mudev Control Socket[0m. +3073s [[0;32m OK [0m] Listening on [0;1;39mudev Kernel Socket[0m. +3073s [[0;32m OK [0m] Reached target [0;1;39mSockets[0m. +3073s Mounting [0;1;39mHuge Pages File System[0m... +3073s Mounting [0;1;39mPOSIX Message Queue File System[0m... +3073s Mounting [0;1;39mKernel Debug File System[0m... +3073s Mounting [0;1;39mKernel Trace File System[0m... +3073s Starting [0;1;39mJournal Service[0m... +3073s Starting [0;1;39mLoad Kernel Module configfs[0m... +3073s Starting [0;1;39mLoad Kernel Module drm[0m... +3073s Starting [0;1;39mLoad Kernel Module fuse[0m... +3073s Starting [0;1;39mLoad Kernel Modules[0m... +3073s Starting [0;1;39mRemount Root and Kernel File Systems[0m... +3073s Starting [0;1;39mColdplug All udev Devices[0m... +3073s [[0;32m OK [0m] Mounted [0;1;39mHuge Pages File System[0m. +3073s [[0;32m OK [0m] Mounted [0;1;39mPOSIX Message Queue File System[0m. +3073s [[0;32m OK [0m] Mounted [0;1;39mKernel Debug File System[0m. +3073s [[0;32m OK [0m] Mounted [0;1;39mKernel Trace File System[0m. +3073s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Module configfs[0m. +3073s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Module drm[0m. +3073s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Module fuse[0m. +3073s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Modules[0m. +3073s [[0;32m OK [0m] Finished [0;1;39mRemount Root and Kernel File Systems[0m. +3073s Mounting [0;1;39mFUSE Control File System[0m... +3073s Mounting [0;1;39mKernel Configuration File System[0m... +3073s Starting [0;1;39mLoad/Save Random Seed[0m... +3073s Starting [0;1;39mApply Kernel Variables[0m... +3074s Starting [0;1;39mCreate System Users[0m... +3074s [[0;32m OK [0m] Started [0;1;39mJournal Service[0m. +3074s [[0;32m OK [0m] Mounted [0;1;39mFUSE Control File System[0m. +3074s [[0;32m OK [0m] Mounted [0;1;39mKernel Configuration File System[0m. +3074s [[0;32m OK [0m] Finished [0;1;39mLoad/Save Random Seed[0m. +3074s Starting [0;1;39mFlush Journal to Persistent Storage[0m... +3074s [[0;32m OK [0m] Finished [0;1;39mApply Kernel Variables[0m. +3074s [[0;32m OK [0m] Finished [0;1;39mCreate System Users[0m. +3074s Starting [0;1;39mCreate Static Device Nodes in /dev[0m... +3074s [[0;32m OK [0m] Finished [0;1;39mCreate Static Device Nodes in /dev[0m. +3074s [[0;32m OK [0m] Finished [0;1;39mFlush Journal to Persistent Storage[0m. +3074s [[0;32m OK [0m] Reached target [0;1;39mPreparation for Local File Systems[0m. +3074s [[0;32m OK [0m] Reached target [0;1;39mLocal File Systems[0m. +3074s Starting [0;1;39mCreate Volatile Files and Directories[0m... +3074s Starting [0;1;39mRule-based Manage…for Device Events and Files[0m... +3074s [[0;32m OK [0m] Finished [0;1;39mColdplug All udev Devices[0m. +3074s [[0;32m OK [0m] Finished [0;1;39mCreate Volatile Files and Directories[0m. +3074s Starting [0;1;39mRecord System Boot/Shutdown in UTMP[0m... +3074s [[0;32m OK [0m] Finished [0;1;39mRecord System Boot/Shutdown in UTMP[0m. +3075s [[0;32m OK [0m] Started [0;1;39mRule-based Manager for Device Events and Files[0m. +3075s [[0;32m OK [0m] Reached target [0;1;39mSystem Initialization[0m. +3075s [[0;32m OK [0m] Started [0;1;39mDaily Cleanup of Temporary Directories[0m. +3075s [[0;32m OK [0m] Reached target [0;1;39mBasic System[0m. +3075s [[0;32m OK [0m] Reached target [0;1;39mTimers[0m. +3075s [[0;32m OK [0m] Listening on [0;1;39mD-Bus System Message Bus Socket[0m. +3075s Starting [0;1;39m/etc/rc.local Compatibility[0m... +3075s Starting [0;1;39mUser Login Management[0m... +3075s [ 17.418607] rc.local[251]: /etc/rc.local: 2: iptables: not found +3075s Starting [0;1;39mPermit User Sessions[0m... +3075s Starting [0;1;39mTEST-13-NSPAWN-SMOKE[0m... +3075s [[0;32m OK [0m] Started [0;1;39m/etc/rc.local Compatibility[0m. +3075s [[0;32m OK [0m] Finished [0;1;39mPermit User Sessions[0m. +3076s [[0;32m OK [0m] Started [0;1;39mD-Bus System Message Bus[0m. +3076s [[0;32m OK [0m] Started [0;1;39mUser Login Management[0m. +3077s [[0;32m OK [0m] Found device [0;1;39m/dev/ttyS0[0m. +3078s [[0;32m OK [0m] Created slice [0;1;39mVirtual Machine and Container Slice[0m. +3078s [[0;32m OK [0m] Started [0;1;39mContainer testsuite-13.bind-tmp-path[0m. +3078s [[0;32m OK [0m] Listening on [0;1;39mLoad/Save RF …itch Status /dev/rfkill Watch[0m. +3078s [[0;32m OK [0m] Started [0;1;39mSerial Getty on ttyS0[0m. +3078s [[0;32m OK [0m] Reached target [0;1;39mLogin Prompts[0m. +3078s [[0;32m OK [0m] Reached target [0;1;39mMulti-User System[0m. +3078s Starting [0;1;39mRecord Runlevel Change in UTMP[0m... +3078s [[0;32m OK [0m] Finished [0;1;39mRecord Runlevel Change in UTMP[0m. +3078s Starting [0;1;39mVirtual Machine a…tainer Registration Service[0m... +3079s [[0;32m OK [0m] Started [0;1;39mVirtual Machine an…ontainer Registration Service[0m. +3080s [[0;32m OK [0m] Started [0;1;39mContainer testsuite-13.norbind-path[0m. +3081s [[0;32m OK [0m] Started [0;1;39mContainer testsuite-13.nc-container[0m. +3084s + +3113s H login: [ 55.539526] int3: 0000 [#1] SMP NOPTI +3113s [ 55.539526] CPU: 3 PID: 685 Comm: ip Not tainted 6.8.0-1008-ibm #8~22.04.1-Ubuntu +3113s [ 55.539526] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 +3113s [ 55.539526] RIP: 0010:__alloc_pages+0xe0/0x330 +3113s [ 55.539526] Code: 10 40 01 00 48 8d 84 02 00 1e 00 00 48 89 45 a8 8b 05 44 65 40 02 85 c0 0f 85 03 02 00 00 89 d8 c1 e8 03 83 e0 03 89 45 c0 66 <90> 41 89 df 41 be 01 00 00 00 f6 c7 04 75 71 44 89 e6 89 df e8 f7 +3113s [ 55.539526] RSP: 0000:ffffb834c112bc30 EFLAGS: 00000202 +3113s [ 55.539526] RAX: 0000000000000001 RBX: 0000000000140dca RCX: 0000000000000014 +3113s [ 55.539526] RDX: ffff8d6cdba51000 RSI: 0000000000000000 RDI: 0000000000140dca +3113s [ 55.539526] RBP: ffffb834c112bc88 R08: 0000000000000000 R09: 0000000000000000 +3113s [ 55.539526] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 +3113s [ 55.539526] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +3113s [ 55.539526] FS: 0000000000000000(0000) GS:ffff8d6cdb180000(0000) knlGS:0000000000000000 +3113s [ 55.539526] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +3113s [ 55.539526] CR2: 000074ea73257538 CR3: 00000000031e0000 CR4: 00000000000006f0 +3113s [ 55.539526] Call Trace: +3113s [ 55.539526] <TASK> +3113s [ 55.539526] ? show_regs+0x6d/0x80 +3113s [ 55.539526] ? die+0x37/0xa0 +3113s [ 55.539526] ? exc_int3+0xe2/0xf0 +3113s [ 55.539526] ? asm_exc_int3+0x3a/0x40 +3113s [ 55.539526] ? __alloc_pages+0xe0/0x330 +3113s [ 55.539526] ? __alloc_pages+0xe0/0x330 +3113s [ 55.539526] alloc_pages_mpol+0x91/0x200 +3113s [ 55.539526] vma_alloc_folio+0x64/0xe0 +3113s [ 55.539526] alloc_anon_folio+0x2c5/0x340 +3113s [ 55.539526] do_anonymous_page+0x6c/0x420 +3113s [ 55.539526] handle_pte_fault+0x1ba/0x1c0 +3113s [ 55.539526] __handle_mm_fault+0x659/0x7a0 +3113s [ 55.539526] handle_mm_fault+0x17f/0x380 +3113s [ 55.539526] do_user_addr_fault+0x158/0x6a0 +3113s [ 55.539526] exc_page_fault+0x83/0x190 +3113s [ 55.539526] asm_exc_page_fault+0x27/0x30 +3113s [ 55.539526] RIP: 0033:0x74ea7333346a +3113s [ 55.539526] Code: 8d 44 20 ff be 10 00 00 00 49 f7 f4 49 0f af c4 4c 8d a4 03 40 f6 ff ff 31 c0 49 8d 7c 24 08 4c 89 e1 49 c7 04 24 00 00 00 00 <49> c7 84 24 b8 09 00 00 00 00 00 00 48 83 e7 f8 48 29 f9 81 c1 c0 +3113s [ 55.539526] RSP: 002b:00007fff10d6e800 EFLAGS: 00000246 +3113s [ 55.539526] RAX: 0000000000000000 RBX: 0000000000001100 RCX: 000074ea73256b80 +3113s [ 55.539526] RDX: 000000000000001f RSI: 0000000000000010 RDI: 000074ea73256b88 +3113s [ 55.539526] RBP: 000074ea73256420 R08: 0000000000000000 R09: 0000000000000094 +3113s [ 55.539526] R10: 0000000000000002 R11: 0000000000000090 R12: 000074ea73256b80 +3113s [ 55.539526] R13: 0000000000000000 R14: 0000000000000000 R15: 000074ea7335a2e0 +3113s [ 55.539526] </TASK> +3113s [ 55.539526] Modules linked in: btrfs blake2b_generic xor raid6_pq libcrc32c psmouse i2c_piix4 pata_acpi floppy +3113s [ 55.539526] ---[ end trace 0000000000000000 ]--- +3113s [ 55.539526] RIP: 0010:__alloc_pages+0xe0/0x330 +3113s [ 55.539526] Code: 10 40 01 00 48 8d 84 02 00 1e 00 00 48 89 45 a8 8b 05 44 65 40 02 85 c0 0f 85 03 02 00 00 89 d8 c1 e8 03 83 e0 03 89 45 c0 66 <90> 41 89 df 41 be 01 00 00 00 f6 c7 04 75 71 44 89 e6 89 df e8 f7 +3113s [ 55.539526] RSP: 0000:ffffb834c112bc30 EFLAGS: 00000202 +3113s [ 55.539526] RAX: 0000000000000001 RBX: 0000000000140dca RCX: 0000000000000014 +3113s [ 55.539526] RDX: ffff8d6cdba51000 RSI: 0000000000000000 RDI: 0000000000140dca +3113s [ 55.539526] RBP: ffffb834c112bc88 R08: 0000000000000000 R09: 0000000000000000 +3113s [ 55.539526] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 +3113s [ 55.539526] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +3113s [ 55.539526] FS: 0000000000000000(0000) GS:ffff8d6cdb180000(0000) knlGS:0000000000000000 +3113s [ 55.539526] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +3113s [ 55.539526] CR2: 000074ea73257538 CR3: 00000000031e0000 CR4: 00000000000006f0 +3113s [ 55.539526] Kernel panic - not syncing: Fatal exception in interrupt +3113s [ 55.539526] Kernel Offset: 0x2ee00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) +3113s [ 55.539526] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- +22800s autopkgtest [02:55:43]: ERROR: timed out on command "su -s /bin/bash root -c set -e; exec /tmp/autopkgtest.vOfxo6/wrapper.sh --artifacts=/tmp/autopkgtest.vOfxo6/upstream-1-artifacts --chdir=/tmp/autopkgtest.vOfxo6/build.1l5/src --env=AUTOPKGTEST_TESTBED_ARCH=amd64 --env=AUTOPKGTEST_TEST_ARCH=amd64 --env=DEB_BUILD_OPTIONS=parallel=4 --env=DEBIAN_FRONTEND=noninteractive --env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS --unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE --unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT --unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME --unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE --unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid --source-profile --stderr=/tmp/autopkgtest.vOfxo6/upstream-1-stderr --stdout=/tmp/autopkgtest.vOfxo6/upstream-1-stdout --tmp=/tmp/autopkgtest.vOfxo6/autopkgtest_tmp --env=AUTOPKGTEST_NORMAL_USER=ubuntu --env=ADT_NORMAL_USER=ubuntu '--env=ADT_TEST_TRIGGERS=linux-meta-ibm-6.8/6.8.0-1008.8~22.04.1 systemd/249.11-0ubuntu3.12' --make-executable=/tmp/autopkgtest.vOfxo6/build.1l5/src/debian/tests/upstream-1 -- /tmp/autopkgtest.vOfxo6/build.1l5/src/debian/tests/upstream-1" (kind: test) +22800s autopkgtest [02:55:43]: test upstream-1: -----------------------] +22801s autopkgtest [02:55:44]: test upstream-1: - - - - - - - - - - results - - - - - - - - - - +22801s upstream-1 FAIL timed out +22804s autopkgtest [02:55:47]: test upstream-2: preparing testbed +22805s Reading package lists... +22805s Building dependency tree... +22805s Reading state information... +22806s Starting pkgProblemResolver with broken count: 0 +22806s Starting 2 pkgProblemResolver with broken count: 0 +22806s Done +22806s The following NEW packages will be installed: +22806s autopkgtest-satdep +22806s 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. +22806s Need to get 0 B/996 B of archives. +22806s After this operation, 0 B of additional disk space will be used. +22806s Get:1 /tmp/autopkgtest.vOfxo6/15-autopkgtest-satdep.deb autopkgtest-satdep amd64 0 [996 B] +22807s Selecting previously unselected package autopkgtest-satdep. +22807s (Reading database ... +(Reading database ... 5% +(Reading database ... 10% +(Reading database ... 15% +(Reading database ... 20% +(Reading database ... 25% +(Reading database ... 30% +(Reading database ... 35% +(Reading database ... 40% +(Reading database ... 45% +(Reading database ... 50% +(Reading database ... 55% +(Reading database ... 60% +(Reading database ... 65% +(Reading database ... 70% +(Reading database ... 75% +(Reading database ... 80% +(Reading database ... 85% +(Reading database ... 90% +(Reading database ... 95% +(Reading database ... 100% +(Reading database ... 109759 files and directories currently installed.) +22807s Preparing to unpack .../15-autopkgtest-satdep.deb ... +22807s Unpacking autopkgtest-satdep (0) ... +22807s Setting up autopkgtest-satdep (0) ... +22810s (Reading database ... 109759 files and directories currently installed.) +22810s Removing autopkgtest-satdep (0) ... +22810s autopkgtest [02:55:53]: test upstream-2: [----------------------- +22810s + + +jammy:linux-lowlatency-hwe-6.8 6.8.0-44.44.1~22.04.1 qemu-x86 QEMU Standard PC (i440FX + PIIX, 1996) -> ADT:systemd:upstream-1 + + +2564s --x-- Running TEST-13-NSPAWN-SMOKE --x-- +2564s make: Entering directory '/tmp/autopkgtest.Nji8tC/build.UBO/src/test/TEST-13-NSPAWN-SMOKE' +2564s Specify build directory with $BUILD_DIR +2565s TEST-13-NSPAWN-SMOKE SETUP: systemd-nspawn smoke test +2565s '/tmp/autopkgtest.Nji8tC/build.UBO/src/test/default.img' -> '/tmp/autopkgtest.Nji8tC/build.UBO/src/test/TEST-13-NSPAWN-SMOKE/../nspawn.img' +2565s Reusing existing cached image /tmp/autopkgtest.Nji8tC/build.UBO/src/test/TEST-13-NSPAWN-SMOKE/../nspawn.img → /tmp/autopkgtest.Nji8tC/build.UBO/src/test/nspawn.img +2565s '/tmp/autopkgtest.Nji8tC/build.UBO/src/test/nspawn.img' -> '/var/tmp/systemd-test.RZ0EoL/nspawn.img' +2566s I: Masking supporting services +2566s '/var/tmp/systemd-test.RZ0EoL/root/etc/systemd/system/systemd-hwdb-update.service' -> '/dev/null' +2566s '/var/tmp/systemd-test.RZ0EoL/root/etc/systemd/system/systemd-journal-catalog-update.service' -> '/dev/null' +2566s '/var/tmp/systemd-test.RZ0EoL/root/etc/systemd/system/systemd-networkd.service' -> '/dev/null' +2566s '/var/tmp/systemd-test.RZ0EoL/root/etc/systemd/system/systemd-networkd.socket' -> '/dev/null' +2566s '/var/tmp/systemd-test.RZ0EoL/root/etc/systemd/system/systemd-resolved.service' -> '/dev/null' +2566s Specify build directory with $BUILD_DIR +2566s TEST-13-NSPAWN-SMOKE RUN: systemd-nspawn smoke test +2566s + /bin/qemu-system-x86_64 -smp 4 -net none -m 512M -nographic -vga none -kernel /boot/vmlinuz-6.8.0-44-lowlatency -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.RZ0EoL/nspawn.img -initrd /boot/initrd.img-6.8.0-44-lowlatency -append 'root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 selinux=0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-13.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-13.service systemd.wants=end.service' +2566s c[?7l[2J[0mSeaBIOS (version 1.15.0-1) +2576s Booting from ROM..c[?7l[2JLoading, please wait... +2577s Starting version 249.11-0ubuntu3.12 +2579s Begin: Loading essential drivers ... done. +2579s Begin: Running /scripts/init-premount ... done. +2579s Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. +2580s Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems +2580s done. +2580s Begin: Will now check root file system ... fsck from util-linux 2.37.2 +2580s [/usr/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -a -C0 /dev/sda1 +2580s systemd: clean, 2426/115200 files, 47727/115200 blocks +2580s done. +2580s done. +2581s Begin: Running /scripts/local-bottom ... done. +2581s Begin: Running /scripts/init-bottom ... done. +2582s +2582s Welcome to [1mUbuntu 22.04.4 LTS[0m! +2582s +2583s [[0;32m OK [0m] Created slice [0;1;39mSlice /system/modprobe[0m. +2583s [[0;32m OK [0m] Created slice [0;1;39mSlice /system/serial-getty[0m. +2583s [[0;32m OK [0m] Created slice [0;1;39mUser and Session Slice[0m. +2583s [[0;32m OK [0m] Started [0;1;39mDispatch Password …ts to Console Directory Watch[0m. +2583s [[0;32m OK [0m] Started [0;1;39mForward Password R…uests to Wall Directory Watch[0m. +2583s [[0;1;38;5;185mUNSUPP[0m] Starting of [0;1;39mArbitrary Exec…m Automount Point[0m unsupported. +2583s [[0;32m OK [0m] Reached target [0;1;39mLocal Encrypted Volumes[0m. +2583s [[0;32m OK [0m] Reached target [0;1;39mPath Units[0m. +2583s [[0;32m OK [0m] Reached target [0;1;39mSlice Units[0m. +2583s [[0;32m OK [0m] Reached target [0;1;39mSwaps[0m. +2583s [[0;32m OK [0m] Reached target [0;1;39mLocal Verity Protected Volumes[0m. +2583s [[0;32m OK [0m] Listening on [0;1;39mProcess Core Dump Socket[0m. +2583s [[0;32m OK [0m] Listening on [0;1;39minitctl Compatibility Named Pipe[0m. +2583s [[0;32m OK [0m] Listening on [0;1;39mJournal Audit Socket[0m. +2583s [[0;32m OK [0m] Listening on [0;1;39mJournal Socket (/dev/log)[0m. +2583s [[0;32m OK [0m] Listening on [0;1;39mJournal Socket[0m. +2583s [[0;32m OK [0m] Listening on [0;1;39mudev Control Socket[0m. +2583s [[0;32m OK [0m] Listening on [0;1;39mudev Kernel Socket[0m. +2583s [[0;32m OK [0m] Reached target [0;1;39mSockets[0m. +2583s Mounting [0;1;39mHuge Pages File System[0m... +2583s Mounting [0;1;39mPOSIX Message Queue File System[0m... +2583s Mounting [0;1;39mKernel Debug File System[0m... +2583s Mounting [0;1;39mKernel Trace File System[0m... +2583s Starting [0;1;39mJournal Service[0m... +2583s Starting [0;1;39mLoad Kernel Module configfs[0m... +2583s Starting [0;1;39mLoad Kernel Module drm[0m... +2583s Starting [0;1;39mLoad Kernel Module fuse[0m... +2583s Starting [0;1;39mLoad Kernel Modules[0m... +2584s Starting [0;1;39mRemount Root and Kernel File Systems[0m... +2584s Starting [0;1;39mColdplug All udev Devices[0m... +2584s [[0;32m OK [0m] Mounted [0;1;39mHuge Pages File System[0m. +2584s [[0;32m OK [0m] Mounted [0;1;39mPOSIX Message Queue File System[0m. +2584s [[0;32m OK [0m] Mounted [0;1;39mKernel Debug File System[0m. +2584s [[0;32m OK [0m] Mounted [0;1;39mKernel Trace File System[0m. +2584s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Module configfs[0m. +2584s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Module drm[0m. +2584s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Module fuse[0m. +2584s [[0;32m OK [0m] Finished [0;1;39mLoad Kernel Modules[0m. +2584s [[0;32m OK [0m] Finished [0;1;39mRemount Root and Kernel File Systems[0m. +2584s Mounting [0;1;39mFUSE Control File System[0m... +2584s Mounting [0;1;39mKernel Configuration File System[0m... +2584s Starting [0;1;39mLoad/Save Random Seed[0m... +2584s Starting [0;1;39mApply Kernel Variables[0m... +2584s Starting [0;1;39mCreate System Users[0m... +2584s [[0;32m OK [0m] Mounted [0;1;39mFUSE Control File System[0m. +2584s [[0;32m OK [0m] Started [0;1;39mJournal Service[0m. +2584s [[0;32m OK [0m] Mounted [0;1;39mKernel Configuration File System[0m. +2584s Starting [0;1;39mFlush Journal to Persistent Storage[0m... +2584s [[0;32m OK [0m] Finished [0;1;39mLoad/Save Random Seed[0m. +2584s [[0;32m OK [0m] Finished [0;1;39mApply Kernel Variables[0m. +2584s [[0;32m OK [0m] Finished [0;1;39mCreate System Users[0m. +2584s Starting [0;1;39mCreate Static Device Nodes in /dev[0m... +2584s [[0;32m OK [0m] Finished [0;1;39mFlush Journal to Persistent Storage[0m. +2584s [[0;32m OK [0m] Finished [0;1;39mCreate Static Device Nodes in /dev[0m. +2584s [[0;32m OK [0m] Reached target [0;1;39mPreparation for Local File Systems[0m. +2584s [[0;32m OK [0m] Reached target [0;1;39mLocal File Systems[0m. +2584s Starting [0;1;39mCreate Volatile Files and Directories[0m... +2584s Starting [0;1;39mRule-based Manage…for Device Events and Files[0m... +2585s [[0;32m OK [0m] Finished [0;1;39mColdplug All udev Devices[0m. +2585s [[0;32m OK [0m] Finished [0;1;39mCreate Volatile Files and Directories[0m. +2585s Starting [0;1;39mRecord System Boot/Shutdown in UTMP[0m... +2585s [[0;32m OK [0m] Finished [0;1;39mRecord System Boot/Shutdown in UTMP[0m. +2585s [[0;32m OK [0m] Started [0;1;39mRule-based Manager for Device Events and Files[0m. +2585s [[0;32m OK [0m] Reached target [0;1;39mSystem Initialization[0m. +2585s [[0;32m OK [0m] Started [0;1;39mDaily Cleanup of Temporary Directories[0m. +2585s [[0;32m OK [0m] Reached target [0;1;39mBasic System[0m. +2585s [[0;32m OK [0m] Reached target [0;1;39mTimers[0m. +2585s [[0;32m OK [0m] Listening on [0;1;39mD-Bus System Message Bus Socket[0m. +2585s Starting [0;1;39m/etc/rc.local Compatibility[0m... +2585s Starting [0;1;39mUser Login Management[0m... +2585s [ 16.813561] rc.local[255]: /etc/rc.local: 2: iptables: not found +2585s Starting [0;1;39mPermit User Sessions[0m... +2585s Starting [0;1;39mTEST-13-NSPAWN-SMOKE[0m... +2585s [[0;32m OK [0m] Started [0;1;39m/etc/rc.local Compatibility[0m. +2585s [[0;32m OK [0m] Finished [0;1;39mPermit User Sessions[0m. +2586s [[0;32m OK [0m] Started [0;1;39mD-Bus System Message Bus[0m. +2586s [[0;32m OK [0m] Started [0;1;39mUser Login Management[0m. +2588s [[0;32m OK [0m] Found device [0;1;39m/dev/ttyS0[0m. +2588s [[0;32m OK [0m] Created slice [0;1;39mVirtual Machine and Container Slice[0m. +2588s [[0;32m OK [0m] Started [0;1;39mContainer testsuite-13.bind-tmp-path[0m. +2588s [[0;32m OK [0m] Listening on [0;1;39mLoad/Save RF …itch Status /dev/rfkill Watch[0m. +2588s [[0;32m OK [0m] Started [0;1;39mSerial Getty on ttyS0[0m. +2588s [[0;32m OK [0m] Reached target [0;1;39mLogin Prompts[0m. +2588s [[0;32m OK [0m] Reached target [0;1;39mMulti-User System[0m. +2588s Starting [0;1;39mRecord Runlevel Change in UTMP[0m... +2588s [[0;32m OK [0m] Finished [0;1;39mRecord Runlevel Change in UTMP[0m. +2589s Starting [0;1;39mVirtual Machine a…tainer Registration Service[0m... +2589s [[0;32m OK [0m] Started [0;1;39mVirtual Machine an…ontainer Registration Service[0m. +2590s [[0;32m OK [0m] Started [0;1;39mContainer testsuite-13.norbind-path[0m. +2591s [[0;32m OK [0m] Started [0;1;39mContainer testsuite-13.nc-container[0m. +2594s + +2607s H login: [ 39.204860] int3: 0000 [#1] PREEMPT SMP NOPTI +2607s [ 39.204860] CPU: 2 PID: 538 Comm: ip Not tainted 6.8.0-44-lowlatency #44.1~22.04.1-Ubuntu +2607s [ 39.204860] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 +2607s [ 39.204860] RIP: 0010:get_any_partial+0x5f/0x1d0 +2607s [ 39.204860] Code: 2d 01 00 00 83 e6 0f b8 22 01 32 01 49 89 fd 8d 0c 36 d3 f8 89 c1 65 48 8b 04 25 40 43 03 00 48 89 45 c8 83 e1 03 41 89 ce 0f <1f> 44 00 00 c7 45 d4 00 00 00 00 41 8b 1c 24 e8 9d af 02 00 c1 eb +2607s [ 39.204860] RSP: 0018:ffffad70c0a7b878 EFLAGS: 00000202 +2607s [ 39.204860] RAX: ffff904994a2cf00 RBX: ffffad70c0a7b8e0 RCX: 0000000000000002 +2607s [ 39.204860] RDX: 0000000000000017 RSI: 0000000000000000 RDI: ffff904981054600 +2607s [ 39.204860] RBP: ffffad70c0a7b8b0 R08: 00000000ffffffff R09: 0000000000000246 +2607s [ 39.204860] R10: 0000000000000246 R11: 0000000000000000 R12: ffffad70c0a7b8e0 +2607s [ 39.204860] R13: ffff904981054600 R14: 0000000000000002 R15: ffff904981054600 +2607s [ 39.204860] FS: 00007e585fc45b80(0000) GS:ffff90499b100000(0000) knlGS:0000000000000000 +2607s [ 39.204860] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +2607s [ 39.204860] CR2: 00007ffe6da69e88 CR3: 0000000003d84000 CR4: 00000000000006f0 +2607s [ 39.204860] Call Trace: +2607s [ 39.204860] <TASK> +2607s [ 39.204860] ? show_regs+0x6d/0x80 +2607s [ 39.204860] ? die+0x37/0xa0 +2607s [ 39.204860] ? exc_int3+0xe2/0xf0 +2607s [ 39.204860] ? asm_exc_int3+0x3a/0x40 +2607s [ 39.204860] ? get_any_partial+0x5f/0x1d0 +2607s [ 39.204860] ? get_any_partial+0x5f/0x1d0 +2607s [ 39.204860] ? namecmp+0x26/0x40 +2607s [ 39.204860] ___slab_alloc+0x735/0x8d0 +2607s [ 39.204860] ? __mod_memcg_lruvec_state+0xa9/0x1b0 +2607s [ 39.204860] ? __register_sysctl_table+0x3f/0x180 +2607s [ 39.204860] ? mod_memcg_lruvec_state+0x2b/0x60 +2607s [ 39.204860] ? __register_sysctl_table+0x3f/0x180 +2607s [ 39.204860] __kmalloc+0x3e7/0x480 +2607s [ 39.204860] ? string+0x5e/0x110 +2607s [ 39.204860] __register_sysctl_table+0x3f/0x180 +2607s [ 39.204860] ? __register_sysctl_table+0x3f/0x180 +2607s [ 39.204860] register_net_sysctl_sz+0x62/0x80 +2607s [ 39.204860] __devinet_sysctl_register+0x109/0x220 +2607s [ 39.204860] devinet_sysctl_register+0x9c/0xd0 +2607s [ 39.204860] inetdev_init+0xee/0x200 +2607s [ 39.204860] inetdev_event+0x32d/0x3f0 +2607s [ 39.204860] notifier_call_chain+0x61/0xe0 +2607s [ 39.204860] raw_notifier_call_chain+0x16/0x30 +2607s [ 39.204860] call_netdevice_notifiers_info+0x52/0xa0 +2607s [ 39.204860] register_netdevice+0x716/0x8d0 +2607s [ 39.204860] register_netdev+0x1e/0x40 +2607s [ 39.204860] loopback_net_init+0x50/0xb0 +2607s [ 39.204860] ops_init+0x3c/0xe0 +2607s [ 39.204860] setup_net+0x12e/0x2a0 +2607s [ 39.204860] copy_net_ns+0x13d/0x2b0 +2607s [ 39.204860] create_new_namespaces+0x11c/0x300 +2607s [ 39.204860] unshare_nsproxy_namespaces+0x5a/0xc0 +2607s [ 39.204860] ksys_unshare+0x1fc/0x3e0 +2607s [ 39.204860] __x64_sys_unshare+0x12/0x20 +2607s [ 39.204860] x64_sys_call+0xd8a/0x24b0 +2607s [ 39.204860] do_syscall_64+0x81/0x170 +2607s [ 39.204860] ? syscall_exit_to_user_mode+0x89/0x260 +2607s [ 39.204860] ? do_syscall_64+0x8d/0x170 +2607s [ 39.204860] ? do_syscall_64+0x8d/0x170 +2607s [ 39.204860] ? irqentry_exit+0x43/0x50 +2607s [ 39.204860] entry_SYSCALL_64_after_hwframe+0x78/0x80 +2607s [ 39.204860] RIP: 0033:0x7e585fb26e1b +2607s [ 39.204860] Code: 73 01 c3 48 8b 0d 15 30 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e5 2f 0f 00 f7 d8 64 89 01 48 +2607s [ 39.204860] RSP: 002b:00007ffe6da6a668 EFLAGS: 00000217 ORIG_RAX: 0000000000000110 +2607s [ 39.204860] RAX: ffffffffffffffda RBX: 0000628519178fcb RCX: 00007e585fb26e1b +2607s [ 39.204860] RDX: 0000000000000000 RSI: 00006285191740bf RDI: 0000000040000000 +2607s [ 39.204860] RBP: 0000000000000005 R08: 0000000000000000 R09: 00007ffe6da6a4f0 +2607s [ 39.204860] R10: 0000000000000000 R11: 0000000000000217 R12: 0000628519173bea +2607s [ 39.204860] R13: 0000000000000000 R14: 00007ffe6da6c880 R15: 0000628519175efe +2607s [ 39.204860] </TASK> +2607s [ 39.204860] Modules linked in: btrfs blake2b_generic xor raid6_pq libcrc32c psmouse i2c_piix4 pata_acpi floppy +2607s [ 39.204860] ---[ end trace 0000000000000000 ]--- +2607s [ 39.204860] RIP: 0010:get_any_partial+0x5f/0x1d0 +2607s [ 39.204860] Code: 2d 01 00 00 83 e6 0f b8 22 01 32 01 49 89 fd 8d 0c 36 d3 f8 89 c1 65 48 8b 04 25 40 43 03 00 48 89 45 c8 83 e1 03 41 89 ce 0f <1f> 44 00 00 c7 45 d4 00 00 00 00 41 8b 1c 24 e8 9d af 02 00 c1 eb +2607s [ 39.204860] RSP: 0018:ffffad70c0a7b878 EFLAGS: 00000202 +2607s [ 39.204860] RAX: ffff904994a2cf00 RBX: ffffad70c0a7b8e0 RCX: 0000000000000002 +2607s [ 39.204860] RDX: 0000000000000017 RSI: 0000000000000000 RDI: ffff904981054600 +2607s [ 39.204860] RBP: ffffad70c0a7b8b0 R08: 00000000ffffffff R09: 0000000000000246 +2607s [ 39.204860] R10: 0000000000000246 R11: 0000000000000000 R12: ffffad70c0a7b8e0 +2607s [ 39.204860] R13: ffff904981054600 R14: 0000000000000002 R15: ffff904981054600 +2607s [ 39.204860] FS: 00007e585fc45b80(0000) GS:ffff90499b100000(0000) knlGS:0000000000000000 +2607s [ 39.204860] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +2607s [ 39.204860] CR2: 00007ffe6da69e88 CR3: 0000000003d84000 CR4: 00000000000006f0 +2607s [ 39.204860] Kernel panic - not syncing: Fatal exception in interrupt +2607s [ 39.204860] Kernel Offset: 0x11c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) +2607s [ 39.204860] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- +22327s autopkgtest [14:32:03]: ERROR: timed out on command "su -s /bin/bash root -c set -e; exec /tmp/autopkgtest.Nji8tC/wrapper.sh --artifacts=/tmp/autopkgtest.Nji8tC/upstream-1-artifacts --chdir=/tmp/autopkgtest.Nji8tC/build.UBO/src --env=AUTOPKGTEST_TESTBED_ARCH=amd64 --env=AUTOPKGTEST_TEST_ARCH=amd64 --env=DEB_BUILD_OPTIONS=parallel=4 --env=DEBIAN_FRONTEND=noninteractive --env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS --unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE --unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT --unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME --unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE --unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid --source-profile --stderr=/tmp/autopkgtest.Nji8tC/upstream-1-stderr --stdout=/tmp/autopkgtest.Nji8tC/upstream-1-stdout --tmp=/tmp/autopkgtest.Nji8tC/autopkgtest_tmp --env=AUTOPKGTEST_NORMAL_USER=ubuntu --env=ADT_NORMAL_USER=ubuntu '--env=ADT_TEST_TRIGGERS=linux-meta-lowlatency-hwe-6.8/6.8.0-44.44.1~22.04.1 linux-lowlatency-hwe-6.8/6.8.0-44.44.1~22.04.1' --make-executable=/tmp/autopkgtest.Nji8tC/build.UBO/src/debian/tests/upstream-1 -- /tmp/autopkgtest.Nji8tC/build.UBO/src/debian/tests/upstream-1" (kind: test) +22328s autopkgtest [14:32:04]: test upstream-1: -----------------------] +22328s autopkgtest [14:32:04]: test upstream-1: - - - - - - - - - - results - - - - - - - - - - +22328s upstream-1 FAIL timed out +22330s autopkgtest [14:32:06]: test upstream-2: preparing testbed + + + + +Only seen this with x86. + +Hello Mehmet, + +Thanks for filing a bug. + +I'm curious: have you been able to confirm whether the issue also happens in Noble? + +Hi Sergio, + +Looking at the 2024.09.30 (current) cycle results, I have seen this with both 5.15 and 6.8 kernel versions on jammy (this also sort of supports my hypothesis, as far as I have seen this has 10%-20% failure rate). + - linux-aws-6.8 (https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/s/systemd/20241012_161912_2e567@/log.gz) + - linux-aws-5.15 (https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/s/systemd/20240725_105850_27e8e@/log.gz) + - linux-gcp-6.8 (https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/s/systemd/20241017_115203_af43e@/log.gz) + + +I checked the logs, we have yet to see the same issue in noble. + + +Sorry for the late reply. + diff --git a/results/classifier/118/unknown/2111 b/results/classifier/118/unknown/2111 new file mode 100644 index 00000000..84c1d2f1 --- /dev/null +++ b/results/classifier/118/unknown/2111 @@ -0,0 +1,89 @@ +user-level: 0.813 +risc-v: 0.812 +x86: 0.782 +hypervisor: 0.780 +register: 0.774 +architecture: 0.773 +network: 0.769 +graphic: 0.757 +assembly: 0.750 +peripherals: 0.744 +TCG: 0.744 +mistranslation: 0.743 +ppc: 0.743 +permissions: 0.742 +VMM: 0.742 +KVM: 0.741 +arm: 0.741 +debug: 0.741 +semantic: 0.738 +socket: 0.738 +kernel: 0.737 +virtual: 0.733 +device: 0.723 +i386: 0.720 +performance: 0.716 +files: 0.703 +vnc: 0.688 +PID: 0.682 +boot: 0.661 + +Assertion failure with active vhost NIC when snapshot_save_job_bh() is executed as part of a vCPU thread's aio_poll() +Description of problem: +During a `snapshot-save` QMP command the `snapshot_save_job_bh()` bottom half can end up being executed as part of a vCPU thread's `aio_poll()`. This is problematic and can lead to an assertion failure (see below for backtrace) when there is an active vhost network device: + +``` +qemu-system-x86_64: ../hw/net/virtio-net.c:3835: virtio_net_pre_save: Assertion `!n->vhost_started' failed. +``` +Steps to reproduce: +It is very racy and very difficult to reproduce when actually taking snapshots. So the way I can get it pretty reliably is: + +1. Issue `snapshot-save` QMP commands with an invalid device ID in a loop. At the same time, have the guest write to the pflash. +2. In GDB, wait for `snapshot_save_job_bh()` to be hit by a vCPU thread. +3. Manually change the device ID to a valid one (`scsi1` in the example) so that taking a snapshot will actually be attempted. +4. Continue in GDB and the assertion failure will happen. +Additional information: +Full backtrace: + +``` + #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 + #1 0x00007f1de5ae3d9f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 + #2 0x00007f1de5a94f32 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 + #3 0x00007f1de5a7f472 in __GI_abort () at ./stdlib/abort.c:79 + #4 0x00007f1de5a7f395 in __assert_fail_base (fmt=0x7f1de5bf3a90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", + file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:92 + #5 0x00007f1de5a8de32 in __GI___assert_fail (assertion=assertion@entry=0x563cb92d56e7 "!n->vhost_started", file=file@entry=0x563cb92d56d0 "../hw/net/virtio-net.c", line=line@entry=3835, + function=function@entry=0x563cb92d65a0 <__PRETTY_FUNCTION__.2> "virtio_net_pre_save") at ./assert/assert.c:101 + #6 0x0000563cb8ebf23c in virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3835 + #7 virtio_net_pre_save (opaque=<optimized out>) at ../hw/net/virtio-net.c:3829 + #8 0x0000563cb917515b in vmstate_save_state_v (f=0x7f1dc43aec30, vmsd=0x563cb9e5a580 <vmstate_virtio_net>, opaque=0x563cbbb6eb40, vmdesc=0x7f1dc4080040, version_id=11, errp=0x7f1dcbdf9908) + at ../migration/vmstate.c:359 + #9 0x0000563cb9175d0c in vmstate_save_state_with_err (f=<optimized out>, vmsd=<optimized out>, opaque=<optimized out>, vmdesc_id=<optimized out>, errp=<optimized out>) at ../migration/vmstate.c:347 + #10 0x0000563cb8d9a1b2 in vmstate_save (f=f@entry=0x7f1dc43aec30, se=se@entry=0x563cbbcbdc70, vmdesc=vmdesc@entry=0x7f1dc4080040) at ../migration/savevm.c:1037 + #11 0x0000563cb8d9d6e6 in qemu_savevm_state_complete_precopy_non_iterable (f=f@entry=0x7f1dc43aec30, in_postcopy=in_postcopy@entry=false, inactivate_disks=inactivate_disks@entry=false) + at ../migration/savevm.c:1553 + #12 0x0000563cb8d9daa2 in qemu_savevm_state_complete_precopy (f=f@entry=0x7f1dc43aec30, iterable_only=iterable_only@entry=false, inactivate_disks=inactivate_disks@entry=false) at ../migration/savevm.c:1628 + #13 0x0000563cb8da076e in qemu_savevm_state (errp=0x7f1dc42c59f0, f=0x7f1dc43aec30) at ../migration/savevm.c:1734 + #14 save_snapshot (name=<optimized out>, overwrite=overwrite@entry=false, vmstate=<optimized out>, has_devices=has_devices@entry=true, devices=0x7f1dc4096600, errp=0x7f1dc42c59f0) at ../migration/savevm.c:3131 + #15 0x0000563cb8da0926 in snapshot_save_job_bh (opaque=0x7f1dc42c5930) at ../migration/savevm.c:3430 + #16 0x0000563cb9110036 in aio_bh_poll (ctx=ctx@entry=0x563cba818b40) at ../util/async.c:216 + #17 0x0000563cb90fa09a in aio_poll (ctx=ctx@entry=0x563cba818b40, blocking=blocking@entry=true) at ../util/aio-posix.c:722 + #18 0x0000563cb8fb1015 in bdrv_poll_co (s=0x7f1dcbdf9db0) at /home/febner/repos/qemu/block/block-gen.h:43 + #19 blk_pwrite (blk=<optimized out>, offset=offset@entry=91136, bytes=bytes@entry=512, buf=0x7f1dc9a16400, flags=flags@entry=0) at block/block-gen.c:2012 + #20 0x0000563cb8bb8985 in pflash_update (pfl=pfl@entry=0x563cbaa84bf0, offset=91136, offset@entry=91526, size=size@entry=1) at ../hw/block/pflash_cfi01.c:394 + #21 0x0000563cb8bbacd8 in pflash_write (be=0, width=1, value=63, offset=91526, pfl=0x563cbaa84bf0) at ../hw/block/pflash_cfi01.c:522 + #22 pflash_mem_write_with_attrs (opaque=0x563cbaa84bf0, addr=91526, value=<optimized out>, len=1, attrs=...) at ../hw/block/pflash_cfi01.c:681 + #23 0x0000563cb8f06e2e in access_with_adjusted_size (addr=addr@entry=91526, value=value@entry=0x7f1dcbdf9f58, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, + access_fn=0x563cb8f06710 <memory_region_write_with_attrs_accessor>, mr=<optimized out>, attrs=...) at ../system/memory.c:573 + #24 0x0000563cb8f07e59 in memory_region_dispatch_write (mr=mr@entry=0x563cbaa84fb0, addr=addr@entry=91526, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...) at ../system/memory.c:1528 + #25 0x0000563cb8f0f43c in flatview_write_continue (fv=fv@entry=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=..., attrs@entry=..., ptr=ptr@entry=0x7f1de7946028, len=len@entry=1, addr1=<optimized out>, + l=<optimized out>, mr=0x563cbaa84fb0) at ../system/physmem.c:2714 + #26 0x0000563cb8f0f6b3 in flatview_write (fv=0x7f1dc42e4720, addr=addr@entry=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=len@entry=1) at ../system/physmem.c:2756 + #27 0x0000563cb8f12959 in address_space_write (len=1, buf=0x7f1de7946028, attrs=..., addr=4290864518, as=0x563cb9fd8ec0 <address_space_memory>) at ../system/physmem.c:2863 + #28 address_space_rw (as=0x563cb9fd8ec0 <address_space_memory>, addr=4290864518, attrs=attrs@entry=..., buf=buf@entry=0x7f1de7946028, len=1, is_write=<optimized out>) at ../system/physmem.c:2873 + #29 0x0000563cb8f64ab8 in kvm_cpu_exec (cpu=cpu@entry=0x563cbac066d0) at ../accel/kvm/kvm-all.c:2915 + #30 0x0000563cb8f65ce5 in kvm_vcpu_thread_fn (arg=arg@entry=0x563cbac066d0) at ../accel/kvm/kvm-accel-ops.c:51 + #31 0x0000563cb90fd1c8 in qemu_thread_start (args=0x563cbaac33c0) at ../util/qemu-thread-posix.c:541 + #32 0x00007f1de5ae2044 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 + #33 0x00007f1de5b6261c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` diff --git a/results/classifier/118/unknown/2224 b/results/classifier/118/unknown/2224 new file mode 100644 index 00000000..c26a83d8 --- /dev/null +++ b/results/classifier/118/unknown/2224 @@ -0,0 +1,235 @@ +user-level: 0.888 +register: 0.880 +mistranslation: 0.866 +ppc: 0.865 +peripherals: 0.862 +permissions: 0.855 +boot: 0.840 +virtual: 0.827 +graphic: 0.825 +x86: 0.824 +vnc: 0.817 +assembly: 0.814 +semantic: 0.813 +arm: 0.813 +architecture: 0.809 +hypervisor: 0.806 +device: 0.800 +socket: 0.799 +performance: 0.793 +PID: 0.791 +debug: 0.790 +TCG: 0.789 +kernel: 0.782 +files: 0.782 +network: 0.780 +VMM: 0.777 +risc-v: 0.731 +i386: 0.717 +KVM: 0.715 + +OpenBSD 7.4+ does not boot on sbsa-ref with Neoverse-V1/N2 or max cpu core +Description of problem: +System boots and then hangs: + +``` +disks: sd0* +>> OpenBSD/arm64 BOOTAA64 1.18 +boot> +cannot open sd0a:/etc/random.seed: No such file or directory +booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1 +3d5cf8 +FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +Copyright (c) 1982, 1986, 1989, 1991, 1993 + The Regents of the University of California. All rights reserved. +Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org + +OpenBSD 7.4 (RAMDISK) #2131: Sun Oct 8 13:35:40 MDT 2023 + deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK +real mem = 1066156032 (1016MB) +avail mem = 996659200 (950MB) +random: boothowto does not indicate good seed +mainbus0 at root: ACPI +psci0 at mainbus0: PSCI 1.1, SMCCC 1.4 +efi0 at mainbus0: UEFI 2.7 +efi0: EFI Development Kit II / SbsaQemu rev 0x10000 +smbios0 at efi0: SMBIOS 3.4.0 +smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024 +smbios0: QEMU QEMU SBSA-REF Machine +cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3 +cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache +cpu0: 0KB 64b/line 8-way L2 cache +cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR +agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller" +agintcmsi0 at agintc0 +agtimer0 at mainbus0: 62500 kHz +acpi0 at mainbus0: ACPI 6.0 +acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +acpimcfg0 at acpi0 +acpimcfg0: addr 0xf0000000, bus 0-255 +acpiiort0 at acpi0 +pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33 +pluart0: console +ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0 +ahci0: port 0: 1.5Gb/s +scsibus0 at ahci0: 32 targets +sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_ +sd0: 43MB, 512 bytes/sector, 88064 sectors, thin +xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0 +usb0 at xhci0: USB revision 3.0 +uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 +acpipci0 at acpi0 PCI0 +pci0 at acpipci0 +0:1:0: rom address conflict 0xfffc0000/0x40000 +0:2:0: rom address conflict 0xffff8000/0x8000 +"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured +em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56 +"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +simplefb0 at mainbus0: 1280x800, 32bpp +wsdisplay0 at simplefb0 mux 1 +wsdisplay0: screen 0 added (std, vt100 emulation) +``` + +If I use Neoverse-N1 (sbsa-ref default core type) then it boots into installer: + +``` +disks: sd0* +>> OpenBSD/arm64 BOOTAA64 1.18 +boot> +cannot open sd0a:/etc/random.seed: No such file or directory +booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1 +3d5cf8 +FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +Copyright (c) 1982, 1986, 1989, 1991, 1993 + The Regents of the University of California. All rights reserved. +Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org + +OpenBSD 7.4 (RAMDISK) #2131: Sun Oct 8 13:35:40 MDT 2023 + deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK +real mem = 1066156032 (1016MB) +avail mem = 996659200 (950MB) +random: boothowto does not indicate good seed +mainbus0 at root: ACPI +psci0 at mainbus0: PSCI 1.1, SMCCC 1.4 +efi0 at mainbus0: UEFI 2.7 +efi0: EFI Development Kit II / SbsaQemu rev 0x10000 +smbios0 at efi0: SMBIOS 3.4.0 +smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024 +smbios0: QEMU QEMU SBSA-REF Machine +cpu0 at mainbus0 mpidr 0: ARM Neoverse N1 r4p1 +cpu0: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache +cpu0: 1024KB 64b/line 8-way L2 cache +cpu0: DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SBSS+MSR +agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller" +agintcmsi0 at agintc0 +agtimer0 at mainbus0: 62500 kHz +acpi0 at mainbus0: ACPI 6.0 +acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +acpimcfg0 at acpi0 +acpimcfg0: addr 0xf0000000, bus 0-255 +acpiiort0 at acpi0 +pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33 +pluart0: console +ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0 +ahci0: port 0: 1.5Gb/s +scsibus0 at ahci0: 32 targets +sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_ +sd0: 43MB, 512 bytes/sector, 88064 sectors, thin +xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0 +usb0 at xhci0: USB revision 3.0 +uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 +acpipci0 at acpi0 PCI0 +pci0 at acpipci0 +0:1:0: rom address conflict 0xfffc0000/0x40000 +0:2:0: rom address conflict 0xffff8000/0x8000 +"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured +em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56 +"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +simplefb0 at mainbus0: 1280x800, 32bpp +wsdisplay0 at simplefb0 mux 1 +wsdisplay0: screen 0 added (std, vt100 emulation) +softraid0 at root +scsibus1 at softraid0: 256 targets +root on rd0a swap on rd0b dump on rd0b +WARNING: CHECK AND RESET THE DATE! +erase ^?, werase ^W, kill ^U, intr ^C, status ^T + +Welcome to the OpenBSD/arm64 7.4 installation program. +(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? +``` +Steps to reproduce: +1. download OpenBSD 7.4 image: https://cdn.openbsd.org/pub/OpenBSD/7.4/arm64/miniroot74.img +2. download sbsa-ref firmware files from https://artifacts.codelinaro.org/ui/native/linaro-419-sbsa-ref/20240313-116475/edk2/ and decompress them +3. start qemu-system-aarch64 as shown above (adapt paths if needed) +4. watch console serial output +Additional information: +I am going to discuss this on OpenBSD mailing list. Will point to this bug. + +OpenBSD 7.5-current snapshot works on Neoverse-N1 and fails on Neoverse-V1/N2/max: + +``` +disks: sd0* +>> OpenBSD/arm64 BOOTAA64 1.18 +boot> +cannot open sd0a:/etc/random.seed: No such file or directory +booting sd0a:/bsd: 3015576+1213504+12712936+634144 [269381+91+701664+287051]=0x1 +3edee0 +FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +Copyright (c) 1982, 1986, 1989, 1991, 1993 + The Regents of the University of California. All rights reserved. +Copyright (c) 1995-2024 OpenBSD. All rights reserved. https://www.OpenBSD.org + +OpenBSD 7.5 (RAMDISK) #121: Thu Mar 14 03:28:46 MDT 2024 + deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK +real mem = 1066147840 (1016MB) +avail mem = 992886784 (946MB) +random: boothowto does not indicate good seed +mainbus0 at root: ACPI +psci0 at mainbus0: PSCI 1.1, SMCCC 1.4 +efi0 at mainbus0: UEFI 2.7 +efi0: EFI Development Kit II / SbsaQemu rev 0x10000 +smbios0 at efi0: SMBIOS 3.4.0 +smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024 +smbios0: QEMU QEMU SBSA-REF Machine +cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3 +cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache +cpu0: 0KB 64b/line 8-way L2 cache +cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR,MTE +agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller" +agintcmsi0 at agintc0 +agtimer0 at mainbus0: 62500 kHz +acpi0 at mainbus0: ACPI 6.0 +acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT +acpimcfg0 at acpi0 +acpimcfg0: addr 0xf0000000, bus 0-255 +acpiiort0 at acpi0 +pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33 +pluart0: console +ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0 +ahci0: port 0: 1.5Gb/s +scsibus0 at ahci0: 32 targets +sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_ +sd0: 43MB, 512 bytes/sector, 88064 sectors, thin +xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0 +usb0 at xhci0: USB revision 3.0 +uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 +acpipci0 at acpi0 PCI0 +pci0 at acpipci0 +0:1:0: rom address conflict 0xfffc0000/0x40000 +0:2:0: rom address conflict 0xffff8000/0x8000 +"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured +em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56 +"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +"ACPI0007" at acpi0 not configured +``` diff --git a/results/classifier/118/unknown/2273 b/results/classifier/118/unknown/2273 new file mode 100644 index 00000000..9d82de6f --- /dev/null +++ b/results/classifier/118/unknown/2273 @@ -0,0 +1,75 @@ +debug: 0.803 +register: 0.791 +arm: 0.776 +graphic: 0.774 +TCG: 0.771 +risc-v: 0.767 +architecture: 0.766 +device: 0.763 +user-level: 0.761 +assembly: 0.759 +virtual: 0.759 +semantic: 0.753 +hypervisor: 0.753 +permissions: 0.752 +KVM: 0.750 +peripherals: 0.746 +files: 0.746 +performance: 0.746 +x86: 0.741 +boot: 0.740 +VMM: 0.734 +socket: 0.730 +PID: 0.730 +kernel: 0.728 +network: 0.727 +vnc: 0.726 +ppc: 0.715 +mistranslation: 0.714 +i386: 0.709 + +Abort in net_tx_pkt_update_sctp_checksum() +Description of problem: +In the function _net_tx_pkt_update_sctp_checksum(),_ an abort happened: + +``` +qemu-fuzz-x86_64: ../../../third_party/qemu/util/iov.c:39: size_t iov_from_buf_full(const struct iovec *, unsigned int, size_t, const void *, size_t): Assertion `offset == 0' failed. +==1052929== ERROR: libFuzzer: deadly signal + #0 0x5575e5cccbe1 in __sanitizer_print_stack_trace llvm/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x5575e5c479b8 in fuzzer::PrintStackTrace() llvm/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 + #2 0x5575e5c2bbb3 in fuzzer::Fuzzer::CrashCallback() llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 + #3 0x7f691f24251f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) + #4 0x7f691f2969fb in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17 + #5 0x7f691f2969fb in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10 + #6 0x7f691f2969fb in pthread_kill nptl/./nptl/pthread_kill.c:89:10 + #7 0x7f691f242475 in gsignal signal/../sysdeps/posix/raise.c:26:13 + #8 0x7f691f2287f2 in abort stdlib/./stdlib/abort.c:79:7 + #9 0x7f691f22871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x7f691f239e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x5575e81e952a in iov_from_buf_full qemu/util/iov.c:39:5 + #12 0x5575e6500768 in net_tx_pkt_update_sctp_checksum qemu/hw/net/net_tx_pkt.c:144:9 + #13 0x5575e659f3e1 in igb_setup_tx_offloads qemu/hw/net/igb_core.c:478:11 + #14 0x5575e659f3e1 in igb_tx_pkt_send qemu/hw/net/igb_core.c:552:10 + #15 0x5575e659f3e1 in igb_process_tx_desc qemu/hw/net/igb_core.c:671:17 + #16 0x5575e659f3e1 in igb_start_xmit qemu/hw/net/igb_core.c:903:9 + #17 0x5575e659f3e1 in igb_set_tdt qemu/hw/net/igb_core.c:2812:5 + #18 0x5575e657d6a4 in igb_core_write qemu/hw/net/igb_core.c:4248:9 +``` +Steps to reproduce: +Here's a simple PoC: + +``` +cat << EOF | \ +qemu-system-x86_64 \ +-display none -machine accel=qtest -m 512M -M q35 -nodefaults -device \ +igb,netdev=net0 -netdev user,id=net0 -qtest stdio +outl 0xcf8 0x80000810 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x80000804 +outw 0xcfc 0x06 +write 0xe0000403 0x1 0x02 +writel 0xe0003808 0xffffffff +write 0xe000381a 0x1 0x5b +write 0xe000381b 0x1 0x00 +EOF +``` diff --git a/results/classifier/118/unknown/2321 b/results/classifier/118/unknown/2321 new file mode 100644 index 00000000..6c408ebb --- /dev/null +++ b/results/classifier/118/unknown/2321 @@ -0,0 +1,70 @@ +KVM: 0.876 +user-level: 0.871 +graphic: 0.855 +x86: 0.834 +permissions: 0.833 +risc-v: 0.827 +register: 0.826 +peripherals: 0.825 +ppc: 0.818 +TCG: 0.817 +virtual: 0.815 +performance: 0.812 +vnc: 0.811 +debug: 0.808 +arm: 0.800 +hypervisor: 0.800 +VMM: 0.800 +semantic: 0.794 +mistranslation: 0.794 +files: 0.788 +device: 0.788 +architecture: 0.784 +assembly: 0.779 +socket: 0.765 +kernel: 0.762 +PID: 0.757 +i386: 0.737 +boot: 0.721 +network: 0.714 + +Segfault when hibernating a KVM VM with QEMU 8.2.3 +Description of problem: +Attempting to hibernate the machine crashes QEMU. +Steps to reproduce: +This involves Nix, please tell me if you want a reproducer that doesn't. + +1. nix build github:NixOS/nixpkgs#nixosTests.hibernate.driver +2. ./result/bin/nixos-test-driver +3. Observe crash +Additional information: +Backtrace: + +``` +#0 kvm_virtio_pci_vq_vector_release (proxy=0x55bd979fd130, vector=<optimized out>) at ../hw/virtio/virtio-pci.c:834 +#1 kvm_virtio_pci_vector_release_one (proxy=proxy@entry=0x55bd979fd130, queue_no=queue_no@entry=0) at ../hw/virtio/virtio-pci.c:965 +#2 0x000055bd9380c430 in virtio_pci_set_vector (vdev=0x55bd97a05500, proxy=0x55bd979fd130, queue_no=0, old_vector=1, new_vector=65535) + at ../hw/virtio/virtio-pci.c:1445 +#3 0x000055bd939c5490 in memory_region_write_accessor (mr=0x55bd979fdc70, addr=26, value=<optimized out>, size=2, shift=<optimized out>, + mask=<optimized out>, attrs=...) at ../system/memory.c:497 +#4 0x000055bd939c4d56 in access_with_adjusted_size (addr=addr@entry=26, value=value@entry=0x7ff49d1ff3e8, size=size@entry=2, + access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55bd939c5410 <memory_region_write_accessor>, mr=<optimized out>, + attrs=...) at ../system/memory.c:573 +#5 0x000055bd939c5081 in memory_region_dispatch_write (mr=mr@entry=0x55bd979fdc70, addr=addr@entry=26, data=<optimized out>, op=<optimized out>, + attrs=attrs@entry=...) at ../system/memory.c:1528 +#6 0x000055bd939ccb0c in flatview_write_continue (fv=fv@entry=0x7ff4445771c0, addr=addr@entry=61572651286554, attrs=..., attrs@entry=..., + ptr=ptr@entry=0x7ff4a082d028, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x55bd979fdc70) at ../system/physmem.c:2714 +#7 0x000055bd939ccd83 in flatview_write (fv=0x7ff4445771c0, addr=addr@entry=61572651286554, attrs=attrs@entry=..., buf=buf@entry=0x7ff4a082d028, + len=len@entry=2) at ../system/physmem.c:2756 +#8 0x000055bd939d0099 in address_space_write (len=2, buf=0x7ff4a082d028, attrs=..., addr=61572651286554, as=0x55bd94a4e720 <address_space_memory>) + at ../system/physmem.c:2863 +#9 address_space_rw (as=0x55bd94a4e720 <address_space_memory>, addr=61572651286554, attrs=attrs@entry=..., buf=buf@entry=0x7ff4a082d028, len=2, + is_write=<optimized out>) at ../system/physmem.c:2873 +#10 0x000055bd93a24548 in kvm_cpu_exec (cpu=cpu@entry=0x55bd9628a3e0) at ../accel/kvm/kvm-all.c:2915 +#11 0x000055bd93a25795 in kvm_vcpu_thread_fn (arg=arg@entry=0x55bd9628a3e0) at ../accel/kvm/kvm-accel-ops.c:51 +#12 0x000055bd93bb5fa8 in qemu_thread_start (args=0x55bd96294940) at ../util/qemu-thread-posix.c:541 +#13 0x00007ff4a19fd272 in start_thread (arg=<optimized out>) at pthread_create.c:447 +#14 0x00007ff4a1a78dcc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 +``` + +Bisected to https://gitlab.com/qemu-project/qemu/-/commit/fcbb086ae590e910614fe5b8bf76e264f71ef304, reverting that change seems to make things work again. diff --git a/results/classifier/118/unknown/23270873 b/results/classifier/118/unknown/23270873 new file mode 100644 index 00000000..83d1a665 --- /dev/null +++ b/results/classifier/118/unknown/23270873 @@ -0,0 +1,717 @@ +user-level: 0.896 +mistranslation: 0.881 +risc-v: 0.859 +boot: 0.830 +TCG: 0.828 +ppc: 0.827 +vnc: 0.820 +peripherals: 0.820 +device: 0.810 +hypervisor: 0.806 +KVM: 0.803 +virtual: 0.802 +permissions: 0.802 +register: 0.797 +VMM: 0.792 +debug: 0.788 +assembly: 0.768 +network: 0.768 +graphic: 0.764 +arm: 0.761 +socket: 0.758 +semantic: 0.752 +performance: 0.744 +architecture: 0.742 +kernel: 0.735 +PID: 0.731 +x86: 0.730 +files: 0.730 +i386: 0.705 + +[Qemu-devel] [BUG?] aio_get_linux_aio: Assertion `ctx->linux_aio' failed + +Hi, + +I am seeing some strange QEMU assertion failures for qemu on s390x, +which prevents a guest from starting. + +Git bisecting points to the following commit as the source of the error. + +commit ed6e2161715c527330f936d44af4c547f25f687e +Author: Nishanth Aravamudan <address@hidden> +Date: Fri Jun 22 12:37:00 2018 -0700 + + linux-aio: properly bubble up errors from initialization + + laio_init() can fail for a couple of reasons, which will lead to a NULL + pointer dereference in laio_attach_aio_context(). + + To solve this, add a aio_setup_linux_aio() function which is called + early in raw_open_common. If this fails, propagate the error up. The + signature of aio_get_linux_aio() was not modified, because it seems + preferable to return the actual errno from the possible failing + initialization calls. + + Additionally, when the AioContext changes, we need to associate a + LinuxAioState with the new AioContext. Use the bdrv_attach_aio_context + callback and call the new aio_setup_linux_aio(), which will allocate a +new AioContext if needed, and return errors on failures. If it +fails for +any reason, fallback to threaded AIO with an error message, as the + device is already in-use by the guest. + + Add an assert that aio_get_linux_aio() cannot return NULL. + + Signed-off-by: Nishanth Aravamudan <address@hidden> + Message-id: address@hidden + Signed-off-by: Stefan Hajnoczi <address@hidden> +Not sure what is causing this assertion to fail. Here is the qemu +command line of the guest, from qemu log, which throws this error: +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin +QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-s390x -name +guest=rt_vm1,debug-threads=on -S -object +secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-21-rt_vm1/master-key.aes +-machine s390-ccw-virtio-2.12,accel=kvm,usb=off,dump-guest-core=off -m +1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -object +iothread,id=iothread1 -uuid 0cde16cd-091d-41bd-9ac2-5243df5c9a0d +-display none -no-user-config -nodefaults -chardev +socket,id=charmonitor,fd=28,server,nowait -mon +chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown +-boot strict=on -drive +file=/dev/mapper/360050763998b0883980000002a000031,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native +-device +virtio-blk-ccw,iothread=iothread1,scsi=off,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device +virtio-net-ccw,netdev=hostnet0,id=net0,mac=02:3a:c8:67:95:84,devno=fe.0.0000 +-netdev tap,fd=32,id=hostnet1,vhost=on,vhostfd=33 -device +virtio-net-ccw,netdev=hostnet1,id=net1,mac=52:54:00:2a:e5:08,devno=fe.0.0002 +-chardev pty,id=charconsole0 -device +sclpconsole,chardev=charconsole0,id=console0 -device +virtio-balloon-ccw,id=balloon0,devno=fe.3.ffba -sandbox +on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny +-msg timestamp=on +2018-07-17 15:48:42.252+0000: Domain id=21 is tainted: high-privileges +2018-07-17T15:48:42.279380Z qemu-system-s390x: -chardev +pty,id=charconsole0: char device redirected to /dev/pts/3 (label +charconsole0) +qemu-system-s390x: util/async.c:339: aio_get_linux_aio: Assertion +`ctx->linux_aio' failed. +2018-07-17 15:48:43.309+0000: shutting down, reason=failed + + +Any help debugging this would be greatly appreciated. + +Thank you +Farhan + +On 17.07.2018 [13:25:53 -0400], Farhan Ali wrote: +> +Hi, +> +> +I am seeing some strange QEMU assertion failures for qemu on s390x, +> +which prevents a guest from starting. +> +> +Git bisecting points to the following commit as the source of the error. +> +> +commit ed6e2161715c527330f936d44af4c547f25f687e +> +Author: Nishanth Aravamudan <address@hidden> +> +Date: Fri Jun 22 12:37:00 2018 -0700 +> +> +linux-aio: properly bubble up errors from initialization +> +> +laio_init() can fail for a couple of reasons, which will lead to a NULL +> +pointer dereference in laio_attach_aio_context(). +> +> +To solve this, add a aio_setup_linux_aio() function which is called +> +early in raw_open_common. If this fails, propagate the error up. The +> +signature of aio_get_linux_aio() was not modified, because it seems +> +preferable to return the actual errno from the possible failing +> +initialization calls. +> +> +Additionally, when the AioContext changes, we need to associate a +> +LinuxAioState with the new AioContext. Use the bdrv_attach_aio_context +> +callback and call the new aio_setup_linux_aio(), which will allocate a +> +new AioContext if needed, and return errors on failures. If it fails for +> +any reason, fallback to threaded AIO with an error message, as the +> +device is already in-use by the guest. +> +> +Add an assert that aio_get_linux_aio() cannot return NULL. +> +> +Signed-off-by: Nishanth Aravamudan <address@hidden> +> +Message-id: address@hidden +> +Signed-off-by: Stefan Hajnoczi <address@hidden> +> +> +> +Not sure what is causing this assertion to fail. Here is the qemu command +> +line of the guest, from qemu log, which throws this error: +> +> +> +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin +> +QEMU_AUDIO_DRV=none /usr/local/bin/qemu-system-s390x -name +> +guest=rt_vm1,debug-threads=on -S -object +> +secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-21-rt_vm1/master-key.aes +> +-machine s390-ccw-virtio-2.12,accel=kvm,usb=off,dump-guest-core=off -m 1024 +> +-realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -object +> +iothread,id=iothread1 -uuid 0cde16cd-091d-41bd-9ac2-5243df5c9a0d -display +> +none -no-user-config -nodefaults -chardev +> +socket,id=charmonitor,fd=28,server,nowait -mon +> +chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot +> +strict=on -drive +> +file=/dev/mapper/360050763998b0883980000002a000031,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native +> +-device +> +virtio-blk-ccw,iothread=iothread1,scsi=off,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on +> +-netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device +> +virtio-net-ccw,netdev=hostnet0,id=net0,mac=02:3a:c8:67:95:84,devno=fe.0.0000 +> +-netdev tap,fd=32,id=hostnet1,vhost=on,vhostfd=33 -device +> +virtio-net-ccw,netdev=hostnet1,id=net1,mac=52:54:00:2a:e5:08,devno=fe.0.0002 +> +-chardev pty,id=charconsole0 -device +> +sclpconsole,chardev=charconsole0,id=console0 -device +> +virtio-balloon-ccw,id=balloon0,devno=fe.3.ffba -sandbox +> +on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg +> +timestamp=on +> +> +> +> +2018-07-17 15:48:42.252+0000: Domain id=21 is tainted: high-privileges +> +2018-07-17T15:48:42.279380Z qemu-system-s390x: -chardev pty,id=charconsole0: +> +char device redirected to /dev/pts/3 (label charconsole0) +> +qemu-system-s390x: util/async.c:339: aio_get_linux_aio: Assertion +> +`ctx->linux_aio' failed. +> +2018-07-17 15:48:43.309+0000: shutting down, reason=failed +> +> +> +Any help debugging this would be greatly appreciated. +iiuc, this possibly implies AIO was not actually used previously on this +guest (it might have silently been falling back to threaded IO?). I +don't have access to s390x, but would it be possible to run qemu under +gdb and see if aio_setup_linux_aio is being called at all (I think it +might not be, but I'm not sure why), and if so, if it's for the context +in question? + +If it's not being called first, could you see what callpath is calling +aio_get_linux_aio when this assertion trips? + +Thanks! +-Nish + +On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +iiuc, this possibly implies AIO was not actually used previously on this +guest (it might have silently been falling back to threaded IO?). I +don't have access to s390x, but would it be possible to run qemu under +gdb and see if aio_setup_linux_aio is being called at all (I think it +might not be, but I'm not sure why), and if so, if it's for the context +in question? + +If it's not being called first, could you see what callpath is calling +aio_get_linux_aio when this assertion trips? + +Thanks! +-Nish +Hi Nishant, +From the coredump of the guest this is the call trace that calls +aio_get_linux_aio: +Stack trace of thread 145158: +#0 0x000003ff94dbe274 raise (libc.so.6) +#1 0x000003ff94da39a8 abort (libc.so.6) +#2 0x000003ff94db62ce __assert_fail_base (libc.so.6) +#3 0x000003ff94db634c __assert_fail (libc.so.6) +#4 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +#5 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +#6 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +#7 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +#8 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +#9 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +#10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +#11 0x000003ff94f879a8 start_thread (libpthread.so.0) +#12 0x000003ff94e797ee thread_start (libc.so.6) + + +Thanks for taking a look and responding. + +Thanks +Farhan + +On 07/18/2018 09:42 AM, Farhan Ali wrote: +On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +iiuc, this possibly implies AIO was not actually used previously on this +guest (it might have silently been falling back to threaded IO?). I +don't have access to s390x, but would it be possible to run qemu under +gdb and see if aio_setup_linux_aio is being called at all (I think it +might not be, but I'm not sure why), and if so, if it's for the context +in question? + +If it's not being called first, could you see what callpath is calling +aio_get_linux_aio when this assertion trips? + +Thanks! +-Nish +Hi Nishant, +From the coredump of the guest this is the call trace that calls +aio_get_linux_aio: +Stack trace of thread 145158: +#0 0x000003ff94dbe274 raise (libc.so.6) +#1 0x000003ff94da39a8 abort (libc.so.6) +#2 0x000003ff94db62ce __assert_fail_base (libc.so.6) +#3 0x000003ff94db634c __assert_fail (libc.so.6) +#4 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +#5 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +#6 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +#7 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +#8 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +#9 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +#10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +#11 0x000003ff94f879a8 start_thread (libpthread.so.0) +#12 0x000003ff94e797ee thread_start (libc.so.6) + + +Thanks for taking a look and responding. + +Thanks +Farhan +Trying to debug a little further, the block device in this case is a +"host device". And looking at your commit carefully you use the +bdrv_attach_aio_context callback to setup a Linux AioContext. +For some reason the "host device" struct (BlockDriver bdrv_host_device +in block/file-posix.c) does not have a bdrv_attach_aio_context defined. +So a simple change of adding the callback to the struct solves the issue +and the guest starts fine. +diff --git a/block/file-posix.c b/block/file-posix.c +index 28824aa..b8d59fb 100644 +--- a/block/file-posix.c ++++ b/block/file-posix.c +@@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = { + .bdrv_refresh_limits = raw_refresh_limits, + .bdrv_io_plug = raw_aio_plug, + .bdrv_io_unplug = raw_aio_unplug, ++ .bdrv_attach_aio_context = raw_aio_attach_aio_context, + + .bdrv_co_truncate = raw_co_truncate, + .bdrv_getlength = raw_getlength, +I am not too familiar with block device code in QEMU, so not sure if +this is the right fix or if there are some underlying problems. +Thanks +Farhan + +On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: +> +> +> +On 07/18/2018 09:42 AM, Farhan Ali wrote: +> +> +> +> +> +> On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +> +> > iiuc, this possibly implies AIO was not actually used previously on this +> +> > guest (it might have silently been falling back to threaded IO?). I +> +> > don't have access to s390x, but would it be possible to run qemu under +> +> > gdb and see if aio_setup_linux_aio is being called at all (I think it +> +> > might not be, but I'm not sure why), and if so, if it's for the context +> +> > in question? +> +> > +> +> > If it's not being called first, could you see what callpath is calling +> +> > aio_get_linux_aio when this assertion trips? +> +> > +> +> > Thanks! +> +> > -Nish +> +> +> +> +> +> Hi Nishant, +> +> +> +> From the coredump of the guest this is the call trace that calls +> +> aio_get_linux_aio: +> +> +> +> +> +> Stack trace of thread 145158: +> +> #0 0x000003ff94dbe274 raise (libc.so.6) +> +> #1 0x000003ff94da39a8 abort (libc.so.6) +> +> #2 0x000003ff94db62ce __assert_fail_base (libc.so.6) +> +> #3 0x000003ff94db634c __assert_fail (libc.so.6) +> +> #4 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +> +> #5 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +> +> #6 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +> +> #7 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +> +> #8 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +> +> #9 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +> +> #10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +> +> #11 0x000003ff94f879a8 start_thread (libpthread.so.0) +> +> #12 0x000003ff94e797ee thread_start (libc.so.6) +> +> +> +> +> +> Thanks for taking a look and responding. +> +> +> +> Thanks +> +> Farhan +> +> +> +> +> +> +> +> +Trying to debug a little further, the block device in this case is a "host +> +device". And looking at your commit carefully you use the +> +bdrv_attach_aio_context callback to setup a Linux AioContext. +> +> +For some reason the "host device" struct (BlockDriver bdrv_host_device in +> +block/file-posix.c) does not have a bdrv_attach_aio_context defined. +> +So a simple change of adding the callback to the struct solves the issue and +> +the guest starts fine. +> +> +> +diff --git a/block/file-posix.c b/block/file-posix.c +> +index 28824aa..b8d59fb 100644 +> +--- a/block/file-posix.c +> ++++ b/block/file-posix.c +> +@@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = { +> +.bdrv_refresh_limits = raw_refresh_limits, +> +.bdrv_io_plug = raw_aio_plug, +> +.bdrv_io_unplug = raw_aio_unplug, +> ++ .bdrv_attach_aio_context = raw_aio_attach_aio_context, +> +> +.bdrv_co_truncate = raw_co_truncate, +> +.bdrv_getlength = raw_getlength, +> +> +> +> +I am not too familiar with block device code in QEMU, so not sure if +> +this is the right fix or if there are some underlying problems. +Oh this is quite embarassing! I only added the bdrv_attach_aio_context +callback for the file-backed device. Your fix is definitely corect for +host device. Let me make sure there weren't any others missed and I will +send out a properly formatted patch. Thank you for the quick testing and +turnaround! + +-Nish + +On 07/18/2018 08:52 PM, Nishanth Aravamudan wrote: +> +On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: +> +> +> +> +> +> On 07/18/2018 09:42 AM, Farhan Ali wrote: +> +>> +> +>> +> +>> On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: +> +>>> iiuc, this possibly implies AIO was not actually used previously on this +> +>>> guest (it might have silently been falling back to threaded IO?). I +> +>>> don't have access to s390x, but would it be possible to run qemu under +> +>>> gdb and see if aio_setup_linux_aio is being called at all (I think it +> +>>> might not be, but I'm not sure why), and if so, if it's for the context +> +>>> in question? +> +>>> +> +>>> If it's not being called first, could you see what callpath is calling +> +>>> aio_get_linux_aio when this assertion trips? +> +>>> +> +>>> Thanks! +> +>>> -Nish +> +>> +> +>> +> +>> Hi Nishant, +> +>> +> +>> From the coredump of the guest this is the call trace that calls +> +>> aio_get_linux_aio: +> +>> +> +>> +> +>> Stack trace of thread 145158: +> +>> #0 0x000003ff94dbe274 raise (libc.so.6) +> +>> #1 0x000003ff94da39a8 abort (libc.so.6) +> +>> #2 0x000003ff94db62ce __assert_fail_base (libc.so.6) +> +>> #3 0x000003ff94db634c __assert_fail (libc.so.6) +> +>> #4 0x000002aa20db067a aio_get_linux_aio (qemu-system-s390x) +> +>> #5 0x000002aa20d229a8 raw_aio_plug (qemu-system-s390x) +> +>> #6 0x000002aa20d309ee bdrv_io_plug (qemu-system-s390x) +> +>> #7 0x000002aa20b5a8ea virtio_blk_handle_vq (qemu-system-s390x) +> +>> #8 0x000002aa20db2f6e aio_dispatch_handlers (qemu-system-s390x) +> +>> #9 0x000002aa20db3c34 aio_poll (qemu-system-s390x) +> +>> #10 0x000002aa20be32a2 iothread_run (qemu-system-s390x) +> +>> #11 0x000003ff94f879a8 start_thread (libpthread.so.0) +> +>> #12 0x000003ff94e797ee thread_start (libc.so.6) +> +>> +> +>> +> +>> Thanks for taking a look and responding. +> +>> +> +>> Thanks +> +>> Farhan +> +>> +> +>> +> +>> +> +> +> +> Trying to debug a little further, the block device in this case is a "host +> +> device". And looking at your commit carefully you use the +> +> bdrv_attach_aio_context callback to setup a Linux AioContext. +> +> +> +> For some reason the "host device" struct (BlockDriver bdrv_host_device in +> +> block/file-posix.c) does not have a bdrv_attach_aio_context defined. +> +> So a simple change of adding the callback to the struct solves the issue and +> +> the guest starts fine. +> +> +> +> +> +> diff --git a/block/file-posix.c b/block/file-posix.c +> +> index 28824aa..b8d59fb 100644 +> +> --- a/block/file-posix.c +> +> +++ b/block/file-posix.c +> +> @@ -3135,6 +3135,7 @@ static BlockDriver bdrv_host_device = { +> +> .bdrv_refresh_limits = raw_refresh_limits, +> +> .bdrv_io_plug = raw_aio_plug, +> +> .bdrv_io_unplug = raw_aio_unplug, +> +> + .bdrv_attach_aio_context = raw_aio_attach_aio_context, +> +> +> +> .bdrv_co_truncate = raw_co_truncate, +> +> .bdrv_getlength = raw_getlength, +> +> +> +> +> +> +> +> I am not too familiar with block device code in QEMU, so not sure if +> +> this is the right fix or if there are some underlying problems. +> +> +Oh this is quite embarassing! I only added the bdrv_attach_aio_context +> +callback for the file-backed device. Your fix is definitely corect for +> +host device. Let me make sure there weren't any others missed and I will +> +send out a properly formatted patch. Thank you for the quick testing and +> +turnaround! +Farhan, can you respin your patch with proper sign-off and patch description? +Adding qemu-block. + +Hi Christian, + +On 19.07.2018 [08:55:20 +0200], Christian Borntraeger wrote: +> +> +> +On 07/18/2018 08:52 PM, Nishanth Aravamudan wrote: +> +> On 18.07.2018 [11:10:27 -0400], Farhan Ali wrote: +> +>> +> +>> +> +>> On 07/18/2018 09:42 AM, Farhan Ali wrote: +<snip> + +> +>> I am not too familiar with block device code in QEMU, so not sure if +> +>> this is the right fix or if there are some underlying problems. +> +> +> +> Oh this is quite embarassing! I only added the bdrv_attach_aio_context +> +> callback for the file-backed device. Your fix is definitely corect for +> +> host device. Let me make sure there weren't any others missed and I will +> +> send out a properly formatted patch. Thank you for the quick testing and +> +> turnaround! +> +> +Farhan, can you respin your patch with proper sign-off and patch description? +> +Adding qemu-block. +I sent it yesterday, sorry I didn't cc everyone from this e-mail: +http://lists.nongnu.org/archive/html/qemu-block/2018-07/msg00516.html +Thanks, +Nish + diff --git a/results/classifier/118/unknown/2374 b/results/classifier/118/unknown/2374 new file mode 100644 index 00000000..87bd6568 --- /dev/null +++ b/results/classifier/118/unknown/2374 @@ -0,0 +1,141 @@ +debug: 0.896 +TCG: 0.886 +performance: 0.885 +user-level: 0.885 +permissions: 0.878 +device: 0.878 +arm: 0.876 +graphic: 0.876 +hypervisor: 0.874 +vnc: 0.873 +semantic: 0.872 +architecture: 0.872 +assembly: 0.865 +risc-v: 0.862 +register: 0.852 +i386: 0.852 +VMM: 0.851 +PID: 0.846 +kernel: 0.835 +boot: 0.833 +virtual: 0.832 +peripherals: 0.820 +ppc: 0.819 +network: 0.812 +KVM: 0.804 +mistranslation: 0.792 +socket: 0.782 +files: 0.773 +x86: 0.755 + +A bug in AArch64 FMOPA/FMOPS (non-widening) instruction +Description of problem: +fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. Depending on the instruction encoding, the element size of operands is either 32 bits or 64 bits. When the computation produces a NaN as a result, the default NaN should be generated. + +However, the current implementation of 32-bit variant of this instruction does not generate default NaNs, because invalid float_status pointer is passed: +``` +// target/arm/tcg/sme_helper.c +void HELPER(sme_fmopa_s)(void *vza, void *vzn, void *vzm, void *vpn, + void *vpm, void *vst, uint32_t desc) +{ +... + float_status fpst; + + /* + * Make a copy of float_status because this operation does not + * update the cumulative fp exception status. It also produces + * default nans. + */ + fpst = *(float_status *)vst; + set_default_nan_mode(true, &fpst); + +... + *a = float32_muladd(n, *m, *a, 0, vst); // &fpst should be used +... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P0[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P6[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z9[32] = { // Set only the first element as NaN, but it is not default NaN. + 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z27[32] = { + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA1H[128] = { 0x0, }; +char o_ZA1H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA1H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P0\n" + "add x29, x29, :lo12:i_P0\n" + "ldr p0, [x29]\n" + "adrp x29, i_P6\n" + "add x29, x29, :lo12:i_P6\n" + "ldr p6, [x29]\n" + "adrp x29, i_Z9\n" + "add x29, x29, :lo12:i_Z9\n" + "ldr z9, [x29]\n" + "adrp x29, i_Z27\n" + "add x29, x29, :lo12:i_Z27\n" + "ldr z27, [x29]\n" + "adrp x29, i_ZA1H\n" + "add x29, x29, :lo12:i_ZA1H\n" + "mov x15, 0\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".inst 0x809bc121\n" // fmopa za1.s, p0/m, p6/m, z9.s, z27.s + "adrp x29, o_ZA1H\n" + "add x29, x29, :lo12:o_ZA1H\n" + "mov x15, 0\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints 8 non-default NaNs (ff ff ff ff). It should print 8 default NaNs (00 00 c0 7f) after the bug is fixed. +Additional information: + diff --git a/results/classifier/118/unknown/2379 b/results/classifier/118/unknown/2379 new file mode 100644 index 00000000..1929934b --- /dev/null +++ b/results/classifier/118/unknown/2379 @@ -0,0 +1,156 @@ +peripherals: 0.802 +risc-v: 0.794 +ppc: 0.765 +x86: 0.765 +vnc: 0.763 +hypervisor: 0.760 +TCG: 0.757 +VMM: 0.757 +KVM: 0.757 +i386: 0.750 +register: 0.745 +permissions: 0.742 +debug: 0.726 +graphic: 0.725 +user-level: 0.723 +performance: 0.722 +semantic: 0.715 +architecture: 0.712 +arm: 0.709 +virtual: 0.708 +assembly: 0.706 +socket: 0.702 +device: 0.696 +files: 0.695 +network: 0.694 +boot: 0.684 +PID: 0.683 +kernel: 0.681 +mistranslation: 0.668 + +virHashRemoveAll remove all jobs in priv->blockjobs but not set disk->priv->blockjob is null for qemuDomainObjPrivateDataClear and qemuProcessStop +Description of problem: +it call virHashRemoveAll to remove all jobs in priv->blockjobs but the disk privateData blockjob is not null for qemuDomainObjPrivateDataClear and qemuProcessStop. when virHashRemoveAll is caled, accessing priv->blockjob cause segfault in others. +Steps to reproduce: +1. virsh blockcopy testvm vda /root/disk/centos7-copy.qcow2 --wait --verbose --pivot + migrate disk of vm +2. poweoff in guest vm +3. libvirt core dump +Additional information: +--Type <RET> for more, q to quit, c to continue without paging-- + Program terminated with signal SIGSEGV, Segmentation fault. + #0 qemuBlockJobUnregister (vm=0x7f823c045050, job=0x7f827c03ca90) at ../src/qemu/qemu_blockjob.c:211 + 211 if (job == diskPriv->blockjob) { + [Current thread is 1 (Thread 0x7f8283640640 (LWP 152))] + (gdb) bt + #0 qemuBlockJobUnregister (vm=0x7f823c045050, job=0x7f827c03ca90) at ../src/qemu/qemu_blockjob.c:211 + #1 qemuBlockJobEventProcessConcluded (asyncJob=VIR_ASYNC_JOB_MIGRATION_OUT, vm=<optimized out>, driver=<optimized out>, + job=0x7f827c03ca90) at ../src/qemu/qemu_blockjob.c:1678 + #2 qemuBlockJobEventProcess (asyncJob=VIR_ASYNC_JOB_MIGRATION_OUT, job=0x7f827c03ca90, vm=<optimized out>, + driver=<optimized out>) at ../src/qemu/qemu_blockjob.c:1703 + #3 qemuBlockJobUpdate (vm=<optimized out>, job=0x7f827c03ca90, asyncJob=1) at ../src/qemu/qemu_blockjob.c:1756 + #4 0x00007f828050c95f in qemuMigrationSrcNBDStorageCopyReady (vm=0x7f823c045050, asyncJob=VIR_ASYNC_JOB_MIGRATION_OUT) + at ../src/qemu/qemu_migration.c:605 + #5 0x00007f8280518ca5 in qemuMigrationSrcNBDStorageCopy (flags=587, nbdURI=<optimized out>, tlsHostname=0x7f823c2b51d0 "", + tlsAlias=<optimized out>, dconn=0x7f823c014790, migrate_disks=0x7f827c006660, nmigrate_disks=2, speed=<optimized out>, + host=0x7f827c0156a0 "10.253.160.196", mig=0x7f827c027a30, vm=0x7f823c045050, driver=0x7f823c01ac40) + at ../src/qemu/qemu_migration.c:1202 + #6 qemuMigrationSrcRun (driver=0x7f823c01ac40, vm=0x7f823c045050, persist_xml=<optimized out>, cookiein=<optimized out>, + cookieinlen=<optimized out>, cookieout=0x7f828363f500, cookieoutlen=0x7f828363f4d4, flags=587, resource=1024, + spec=0x7f828363f330, dconn=0x7f823c014790, graphicsuri=0x0, nmigrate_disks=2, migrate_disks=0x7f827c006660, + migParams=0x7f827c00d890, nbdURI=0x0) at ../src/qemu/qemu_migration.c:4167 + #7 0x00007f828051a5dd in qemuMigrationSrcPerformNative (driver=0x7f823c01ac40, vm=0x7f823c045050, + persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n <name>default_vm-8altm</name>\n <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n <metadata>\n <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n <vmid>13fb0e90-2930-"..., + uri=<optimized out>, + cookiein=0x7f827c0519e0 "<qemu-migration>\n <name>default_vm-8altm</name>\n <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n <hostname>ceasphere-node-1</hostname>\n <hostuuid>5b0a0842-6535-27c1-b2e7-89c4ac4fd785</hostuuid>"..., + cookieinlen=876, cookieout=0x7f828363f500, cookieoutlen=0x7f828363f4d4, flags=587, resource=1024, dconn=0x7f823c014790, + graphicsuri=0x0, nmigrate_disks=2, migrate_disks=0x7f827c006660, migParams=0x7f827c00d890, nbdURI=0x0) + at ../src/qemu/qemu_migration.c:4506 + #8 0x00007f828051c3e3 in qemuMigrationSrcPerformPeer2Peer3 (flags=<optimized out>, useParams=true, bandwidth=<optimized out>, + migParams=0x7f827c00d890, nbdURI=0x0, nbdPort=0, migrate_disks=0x7f827c006660, nmigrate_disks=<optimized out>, + listenAddress=<optimized out>, graphicsuri=0x0, uri=<optimized out>, dname=0x0, + persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n <name>default_vm-8altm</name>\n <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n <metadata>\n <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n <vmid>13fb0e90-2930-"..., + xmlin=<optimized out>, vm=0x7f823c045050, + dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", dconn=0x7f823c014790, sconn=0x7f826c00e890, driver=0x7f823c01ac40) at ../src/qemu/qemu_migration.c:4925 + #9 qemuMigrationSrcPerformPeer2Peer (v3proto=<synthetic pointer>, resource=<optimized out>, dname=0x0, flags=587, + migParams=0x7f827c00d890, nbdURI=0x0, nbdPort=0, migrate_disks=0x7f827c006660, nmigrate_disks=<optimized out>, + listenAddress=<optimized out>, graphicsuri=0x0, uri=<optimized out>, + dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", + --Type <RET> for more, q to quit, c to continue without paging-- + persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n <name>default_vm-8altm</name>\n <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n <metadata>\n <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n <vmid>13fb0e90-2930-"..., + xmlin=<optimized out>, vm=0x7f823c045050, sconn=0x7f826c00e890, driver=0x7f823c01ac40) at ../src/qemu/qemu_migration.c:5230 + #10 qemuMigrationSrcPerformJob (driver=0x7f823c01ac40, conn=0x7f826c00e890, vm=0x7f823c045050, xmlin=<optimized out>, + persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n <name>default_vm-8altm</name>\n <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n <metadata>\n <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n <vmid>13fb0e90-2930-"..., + dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", uri=<optimized out>, graphicsuri=<optimized out>, listenAddress=<optimized out>, nmigrate_disks=<optimized out>, + migrate_disks=<optimized out>, nbdPort=0, nbdURI=<optimized out>, migParams=<optimized out>, cookiein=<optimized out>, + cookieinlen=0, cookieout=<optimized out>, cookieoutlen=<optimized out>, flags=<optimized out>, dname=<optimized out>, + resource=<optimized out>, v3proto=<optimized out>) at ../src/qemu/qemu_migration.c:5307 + #11 0x00007f828051cce7 in qemuMigrationSrcPerform (driver=0x7f823c01ac40, conn=0x7f826c00e890, vm=0x7f823c045050, + xmlin=0x7f827c01e630 "<domain type=\"kvm\">\n <name>default_vm-8altm</name>\n <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n <metadata>\n <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n <vmid>13fb0e90-2930-"..., + persist_xml=0x7f827c020660 "<domain type=\"kvm\">\n <name>default_vm-8altm</name>\n <uuid>4a40fa64-fd9b-5078-8574-3ce5d0041d31</uuid>\n <metadata>\n <nodeagent xmlns=\"http://kubevirt.io/node-agent.io\">\n <vmid>13fb0e90-2930-"..., + dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", uri=0x556a1f856b20 "tcp://10.253.160.196:27939", graphicsuri=0x0, listenAddress=0x0, nmigrate_disks=2, + migrate_disks=0x7f827c006660, nbdPort=0, nbdURI=0x0, migParams=0x7f827c00d890, cookiein=0x0, cookieinlen=0, + cookieout=0x7f828363f8a8, cookieoutlen=0x7f828363f89c, flags=587, dname=0x0, resource=1024, v3proto=true) + at ../src/qemu/qemu_migration.c:5513 + #12 0x00007f82804e34d0 in qemuDomainMigratePerform3Params (dom=0x7f8268002ee0, + dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", params=0x7f827c01e380, nparams=7, cookiein=0x0, cookieinlen=0, cookieout=0x7f828363f8a8, + cookieoutlen=0x7f828363f89c, flags=587) at ../src/qemu/qemu_driver.c:11796 + #13 0x00007f82853256d6 in virDomainMigratePerform3Params (domain=domain@entry=0x7f8268002ee0, + dconnuri=0x7f827c00c2b0 "qemu+unix:///system?socket=/var/run/kubevirt/migrationproxy/13fb0e90-2930-4f0b-959a-cc40346e7d64-source.sock", params=<optimized out>, nparams=7, cookiein=0x0, cookieinlen=0, cookieout=0x7f828363f8a8, + cookieoutlen=0x7f828363f89c, flags=587) at ../src/libvirt-domain.c:5165 + #14 0x0000556a1f200f17 in remoteDispatchDomainMigratePerform3Params (server=<optimized out>, msg=0x556a1f86ba40, + ret=0x7f827c0197f0, args=0x7f827c019520, rerr=0x7f828363f9a0, client=<optimized out>) + at ../src/remote/remote_daemon_dispatch.c:5710 + #15 remoteDispatchDomainMigratePerform3ParamsHelper (server=<optimized out>, client=<optimized out>, msg=0x556a1f86ba40, + rerr=0x7f828363f9a0, args=0x7f827c019520, ret=0x7f827c0197f0) at src/remote/remote_daemon_dispatch_stubs.h:8761 + #16 0x00007f828522c676 in virNetServerProgramDispatchCall (msg=0x556a1f86ba40, client=0x556a1f85b510, server=0x556a1f84c080, + prog=0x556a1f850410) at ../src/rpc/virnetserverprogram.c:428 + #17 virNetServerProgramDispatch (prog=0x556a1f850410, server=0x556a1f84c080, client=0x556a1f85b510, msg=0x556a1f86ba40) + at ../src/rpc/virnetserverprogram.c:302 + --Type <RET> for more, q to quit, c to continue without paging-- + #18 0x00007f82852331d8 in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, + srv=0x556a1f84c080) at ../src/rpc/virnetserver.c:140 + #19 virNetServerHandleJob (jobOpaque=0x556a1f861f90, opaque=0x556a1f84c080) at ../src/rpc/virnetserver.c:160 + #20 0x00007f8285170653 in virThreadPoolWorker (opaque=<optimized out>) at ../src/util/virthreadpool.c:164 + #21 0x00007f828516fc09 in virThreadHelper (data=<optimized out>) at ../src/util/virthread.c:256 + #22 0x00007f8284b10802 in start_thread () from /lib64/libc.so.6 + #23 0x00007f8284ab0450 in clone3 () from /lib64/libc.so.6 + + + (gdb) p job + $1 = (qemuBlockJobData *) 0x7f827c03ca90 + (gdb) p *job + $2 = {parent = {parent_instance = {g_type_instance = {g_class = 0x7f827c00dc90}, ref_count = 1, qdata = 0x0}}, + name = 0x7f827c038cd0 "drive-ua-vol-vm-8altm", disk = 0x7f823c0475c0, chain = 0x556a1f8548f0, mirrorChain = 0x0, + jobflags = 0, jobflagsmissing = false, data = {pull = {base = 0x0}, commit = {topparent = 0x0, top = 0x0, base = 0x0, + deleteCommittedImages = false}, create = {storage = false, src = 0x0}, copy = {shallownew = false}, backup = { + store = 0x0, bitmap = 0x0}}, type = 2, state = 5, errmsg = 0x0, synchronous = true, newstate = 6, brokentype = 0, + invalidData = false, reconnected = false} + (gdb) p *job->disk + $3 = {src = 0x7f823c047, privateData = 0xffe8eec3390edb93, device = VIR_DOMAIN_DISK_DEVICE_DISK, + bus = VIR_DOMAIN_DISK_BUS_VIRTIO, dst = 0x7f823c047300 "\327_'ą\177", tray_status = VIR_DOMAIN_DISK_TRAY_CLOSED, + removable = VIR_TRISTATE_SWITCH_ABSENT, rotation_rate = 0, mirror = 0x0, mirrorState = 0, mirrorJob = 0, geometry = { + cylinders = 0, heads = 0, sectors = 0, trans = VIR_DOMAIN_DISK_TRANS_DEFAULT}, blockio = {logical_block_size = 0, + physical_block_size = 0}, blkdeviotune = {total_bytes_sec = 0, read_bytes_sec = 0, write_bytes_sec = 0, + total_iops_sec = 0, read_iops_sec = 0, write_iops_sec = 0, total_bytes_sec_max = 0, read_bytes_sec_max = 0, + write_bytes_sec_max = 0, total_iops_sec_max = 0, read_iops_sec_max = 0, write_iops_sec_max = 0, size_iops_sec = 0, + group_name = 0x0, total_bytes_sec_max_length = 0, read_bytes_sec_max_length = 0, write_bytes_sec_max_length = 0, + total_iops_sec_max_length = 0, read_iops_sec_max_length = 0, write_iops_sec_max_length = 0}, + driverName = 0x7f823c047270 "\267\262'ą\177", serial = 0x0, wwn = 0x0, vendor = 0x0, product = 0x0, + cachemode = VIR_DOMAIN_DISK_CACHE_DISABLE, error_policy = VIR_DOMAIN_DISK_ERROR_POLICY_RETRY, + rerror_policy = VIR_DOMAIN_DISK_ERROR_POLICY_DEFAULT, retry_interval = 1000, retry_timeout = 0, + iomode = VIR_DOMAIN_DISK_IO_NATIVE, ioeventfd = VIR_TRISTATE_SWITCH_ABSENT, event_idx = VIR_TRISTATE_SWITCH_ABSENT, + copy_on_read = VIR_TRISTATE_SWITCH_ABSENT, snapshot = VIR_DOMAIN_SNAPSHOT_LOCATION_DEFAULT, + startupPolicy = VIR_DOMAIN_STARTUP_POLICY_DEFAULT, transient = false, transientShareBacking = VIR_TRISTATE_BOOL_ABSENT, + info = {alias = 0x0, type = 0, addr = {pci = {domain = 0, bus = 0, slot = 0, function = 0, + multi = VIR_TRISTATE_SWITCH_ABSENT, extFlags = 0, zpci = {uid = {value = 0, isSet = false}, fid = {value = 0, + isSet = false}}}, drive = {controller = 0, bus = 0, target = 0, unit = 0, diskbus = 0}, vioserial = { + controller = 0, bus = 0, port = 0}, ccid = {controller = 0, slot = 0}, usb = {bus = 0, port = {0, 0, 0, 0}}, + spaprvio = {reg = 0, has_reg = false}, ccw = {cssid = 0, ssid = 0, devno = 0, assigned = false}, isa = {iobase = 0, + irq = 0}, dimm = {slot = 0, base = 0}}, mastertype = 0, master = {usb = {startport = 0}}, + romenabled = VIR_TRISTATE_BOOL_ABSENT, rombar = VIR_TRISTATE_SWITCH_ABSENT, romfile = 0x0, bootIndex = 1, + effectiveBootIndex = 1, acpiIndex = 0, pciConnectFlags = 9, pciAddrExtFlags = 0, loadparm = 0x0, isolationGroup = 0, + isolationGroupLocked = false}, rawio = VIR_TRISTATE_BOOL_ABSENT, sgio = VIR_DOMAIN_DEVICE_SGIO_DEFAULT, + discard = VIR_DOMAIN_DISK_DISCARD_DEFAULT, iothread = 1, detect_zeroes = VIR_DOMAIN_DISK_DETECT_ZEROES_DEFAULT, + domain_name = 0x0, queues = 0, queue_size = 0, model = VIR_DOMAIN_DISK_MODEL_DEFAULT, virtio = 0x7f823c047170, + diskElementAuth = false, diskElementEnc = false} diff --git a/results/classifier/118/unknown/2380 b/results/classifier/118/unknown/2380 new file mode 100644 index 00000000..da3135db --- /dev/null +++ b/results/classifier/118/unknown/2380 @@ -0,0 +1,135 @@ +peripherals: 0.831 +ppc: 0.830 +permissions: 0.829 +device: 0.828 +user-level: 0.824 +KVM: 0.821 +VMM: 0.807 +debug: 0.800 +vnc: 0.792 +performance: 0.792 +register: 0.789 +semantic: 0.787 +boot: 0.779 +graphic: 0.778 +architecture: 0.778 +TCG: 0.776 +arm: 0.774 +i386: 0.773 +risc-v: 0.764 +virtual: 0.761 +files: 0.753 +network: 0.752 +mistranslation: 0.751 +socket: 0.741 +x86: 0.740 +assembly: 0.724 +PID: 0.709 +kernel: 0.694 +hypervisor: 0.684 + +Crash on x86_64 vm launch +Description of problem: +When I started using QEMU for x86 OS programming about a year or 2 ago it ran fine until about a year ago where it just does not launch for more than a few seconds, it always crashes with no output at all, even when running with debug options enabled, it still outputs normal values before just crashing or exiting, this happens when running with an OS image or not, I have tried everything possible (wiping the whole system of anything including "qemu" including the registry, disabling all AV including windows defender, using SFC and DISM to repair corrupt files, installing the oldest versions of qemu up to the newest, running the program in different compatibility modes, running as admin, changing install directories, disabling overclocking, and many more) the only way it runs is if I use a VM to run qemu or reinstall windows, I am not reinstalling windows and im not running a vm to run another vm, my OS is very stable apart from this one program, I need to use QEMU as it is very important for my OS builds as it allows me to automate many things. +Steps to reproduce: +1. launch qemu-system-x86_64 + +unable to reproduce on other clean OS installs +Additional information: +upon clean building QEMU from latest build using MSYS2 and running GDB here is the output + +``` +(gdb) run +Starting program: C:\qemu\build\qemu-system-x86_64.exe +[New Thread 22292.0x250c] +[New Thread 22292.0x2004] +[New Thread 22292.0x1d2c] +[New Thread 22292.0x5614] +[New Thread 22292.0x5b3c] +[New Thread 22292.0x5ae8] +[New Thread 22292.0x2d04] +[New Thread 22292.0x5588] +[New Thread 22292.0x3ce8] +gdb: unknown target exception 0xc0000409 at 0x7ffac8f83e74 + +Thread 8 received signal ?, Unknown signal. +[Switching to Thread 22292.0x2d04] +0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll + +``` + +the error code leads to STATUS_STACK_BUFFER_OVERRUN + +upon back tracing this it leads to this output + +``` +(gdb) bt +#0 0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll +#1 0x00007ffac8f82c04 in msvcrt!longjmp () from C:\Windows\System32\msvcrt.dll +#2 0x00007ff670af2b8e in advance_pc (env=0x34d3c60, s=0x4beff8d0, num_bytes=4) + at ../target/i386/tcg/translate.c:2131 +#3 0x00007ff670af2d33 in x86_ldl_code (env=0x34d3c60, s=0x4beff8d0) + at ../target/i386/tcg/translate.c:2169 +#4 0x00007ff670af3939 in insn_get (env=0x34d3c60, s=0x4beff8d0, ot=MO_32) + at ../target/i386/tcg/translate.c:2454 +#5 0x00007ff670b0c4ca in disas_insn (s=0x4beff8d0, cpu=0x34d1450) + at ../target/i386/tcg/translate.c:5148 +#6 0x00007ff670b1253f in i386_tr_translate_insn (dcbase=0x4beff8d0, cpu=0x34d1450) + at ../target/i386/tcg/translate.c:7023 +#7 0x00007ff670ba30b2 in translator_loop (cpu=0x34d1450, tb=0x3b3a280, max_insns=0x4beffba4, + pc=954352, host_pc=0x43de8ff0, ops=0x7ff671a9b480 <i386_tr_ops>, db=0x4beff8d0) + at ../accel/tcg/translator.c:164 +#8 0x00007ff670b127ef in gen_intermediate_code (cpu=0x34d1450, tb=0x3b3a280, + max_insns=0x4beffba4, pc=954352, host_pc=0x43de8ff0) at ../target/i386/tcg/translate.c:7099 +#9 0x00007ff670ba1abd in setjmp_gen_code (env=0x34d3c60, tb=0x3b3a280, pc=954352, + host_pc=0x43de8ff0, max_insns=0x4beffba4, ti=0x4beffbc0) at ../accel/tcg/translate-all.c:278 +#10 0x00007ff670ba1de3 in tb_gen_code (cpu=0x34d1450, pc=954352, cs_base=0, flags=176, + cflags=-16646144) at ../accel/tcg/translate-all.c:358 +#11 0x00007ff670b96508 in cpu_exec_loop (cpu=0x34d1450, sc=0x4beffd60) + at ../accel/tcg/cpu-exec.c:989 +#12 0x00007ff670b96689 in cpu_exec_setjmp (cpu=0x34d1450, sc=0x4beffd60) + at ../accel/tcg/cpu-exec.c:1035 +#13 0x00007ff670b96728 in cpu_exec (cpu=0x34d1450) at ../accel/tcg/cpu-exec.c:1061 +--Type <RET> for more, q to quit, c to continue without paging-- +#14 0x00007ff670bc1fb7 in tcg_cpu_exec (cpu=0x34d1450) at ../accel/tcg/tcg-accel-ops.c:76 +#15 0x00007ff670bc28a2 in mttcg_cpu_thread_fn (arg=0x34d1450) + at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#16 0x00007ff670de8587 in win32_start_routine (arg=0x3537c60) at ../util/qemu-thread-win32.c:411 +#17 0x00007ffac8f8e634 in msvcrt!_beginthreadex () from C:\Windows\System32\msvcrt.dll +#18 0x00007ffac8f8e70c in msvcrt!_endthreadex () from C:\Windows\System32\msvcrt.dll +#19 0x00007ffac901257d in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll +#20 0x00007ffacae0aa48 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll +#21 0x0000000000000000 in ?? () + +``` + +if I am reading the output correctly qemu/target/i386/tcg/translate.c:2131 is the last file (in source) it accesses before moving to msvcrt.dll, inside of the advance_pc function + + +this is the function + +``` +static uint64_t advance_pc(CPUX86State *env, DisasContext *s, int num_bytes) { + uint64_t pc = s->pc; + + if (s->base.num_insns > 1 && !is_same_page(&s->base, s->pc + num_bytes - 1)) { + siglongjmp(s->jmpbuf, 2); <-------------------------------------------------- The line is the last function call + } + + s->pc += num_bytes; + + if (unlikely(cur_insn_len(s) > X86_MAX_INSN_LENGTH)) { + if (((s->pc - 1) ^ (pc - 1)) & TARGET_PAGE_MASK) { + volatile uint8_t unused = cpu_ldub_code(env, (s->pc - 1) & TARGET_PAGE_MASK); + (void)unused; + } + siglongjmp(s->jmpbuf, 1); + } + + return pc; +} +``` + +if I had to guess this problem could be caused by some windows configuration, something to do with memory, or maybe some corrupt files, but I am unsure + +I am not a c programmer so I don't know much about the code but I can debug more if needed diff --git a/results/classifier/118/unknown/2412 b/results/classifier/118/unknown/2412 new file mode 100644 index 00000000..e6ef8998 --- /dev/null +++ b/results/classifier/118/unknown/2412 @@ -0,0 +1,130 @@ +permissions: 0.870 +register: 0.863 +KVM: 0.862 +user-level: 0.838 +device: 0.836 +risc-v: 0.832 +TCG: 0.818 +semantic: 0.818 +performance: 0.810 +peripherals: 0.796 +mistranslation: 0.792 +vnc: 0.789 +hypervisor: 0.783 +architecture: 0.783 +debug: 0.777 +graphic: 0.775 +virtual: 0.773 +assembly: 0.771 +x86: 0.769 +VMM: 0.768 +PID: 0.761 +boot: 0.751 +network: 0.731 +arm: 0.729 +ppc: 0.728 +files: 0.723 +kernel: 0.719 +socket: 0.716 +i386: 0.702 + +Race condition in megasas device +Description of problem: +Race condition DoS in megasas device was found during **fuzzing**. I'm not sure about **worst case impact**, but for now I can make a suggestion: worst case might be leading to **DoS**, but probably it's a rabbit hole. So if we dig deeper we might find something like CWE-200 or CWE-202 (Exposure of Sensitive Information to an Unauthorized Actor and so on). Also, I think that we should analyse thread usage in this case and make all operations thread-safe, but it's not my business of course. As a consequence, I do not suggest any patch (at least for now). +Steps to reproduce: +This command: + +`cat << EOF | ./build/qemu-system-x86_64 \`\ +`-display none -machine accel=qtest, -m 512M -machine q35 -nodefaults \`\ +`-device megasas -device scsi-cd,drive=null0 -blockdev \`\ +`driver=null-co,read-zeroes=on,node-name=null0 -qtest stdio`\ +`outl 0xcf8 0x80000818`\ +`outl 0xcfc 0xc000`\ +`outl 0xcf8 0x80000804`\ +`outw 0xcfc 0x05`\ +`write 0x20 0x1 0x03`\ +`write 0x26 0x1 0x08`\ +`write 0x27 0x1 0x01`\ +`write 0x30 0x1 0x02`\ +`write 0x40 0x1 0x08`\ +`write 0x57 0x1 0x01`\ +`write 0x5a 0x1 0x08`\ +`outl 0xc03d 0x20000000`\ +`outl 0xc03d 0x00`\ +`EOF`\ +\ +Results in:\ +\ +`[R +0.081916] outl 0xcf8 0x80000818`\ +`[S +0.081986] OK`\ +`OK`\ +`[R +0.082033] outl 0xcfc 0xc000`\ +`[S +0.082083] OK`\ +`OK`\ +`[R +0.082102] outl 0xcf8 0x80000804`\ +`[S +0.082117] OK`\ +`OK`\ +`[R +0.082133] outw 0xcfc 0x05`\ +`[S +0.082926] OK`\ +`OK`\ +`[R +0.082961] write 0x20 0x1 0x03`\ +`[S +0.083688] OK`\ +`OK`\ +`[R +0.083731] write 0x26 0x1 0x08`\ +`[S +0.083754] OK`\ +`OK`\ +`[R +0.083780] write 0x27 0x1 0x01`\ +`[S +0.083799] OK`\ +`OK`\ +`[R +0.083817] write 0x30 0x1 0x02`\ +`[S +0.083850] OK`\ +`OK`\ +`[R +0.083872] write 0x40 0x1 0x08`\ +`[S +0.083903] OK`\ +`OK`\ +`[R +0.083925] write 0x57 0x1 0x01`\ +`[S +0.083947] OK`\ +`OK`\ +`[R +0.083962] write 0x5a 0x1 0x08`\ +`[S +0.083985] OK`\ +`OK`\ +`[R +0.084000] outl 0xc03d 0x20000000`\ +`[S +0.085531] OK`\ +`OK`\ +`[R +0.085570] outl 0xc03d 0x00`\ +`[S +0.085673] OK`\ +`OK`\ +`qemu/include/exec/memory.h:1152:12: runtime error: member access within null pointer of type 'AddressSpace' (aka 'struct AddressSpace')`\ +`SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior qemu/include/exec/memory.h:1152:12 in` \ +`AddressSanitizer:DEADLYSIGNAL`\ +`=================================================================`\ +`==168244==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000020 (pc 0x56259b9829ac bp 0x000000000001 sp 0x7ffe62140220 T0)`\ +`==168244==The signal is caused by a READ memory access.`\ +`==168244==Hint: address points to the zero page.`\ + `#0 0x56259b9829ac in address_space_to_flatview qemu/include/exec/memory.h:1152:12`\ + `#1 0x56259b9829ac in address_space_write qemu/build/../system/physmem.c:2929:14`\ + `#2 0x56259b98665e in address_space_unmap qemu/build/../system/physmem.c:3272:9`\ + `#3 0x56259af31dce in dma_memory_unmap qemu/include/sysemu/dma.h:236:5`\ + `#4 0x56259af31dce in dma_blk_unmap qemu/build/../system/dma-helpers.c:93:9`\ + `#5 0x56259af2f220 in dma_complete qemu/build/../system/dma-helpers.c:105:5`\ + `#6 0x56259af2f220 in dma_blk_cb qemu/build/../system/dma-helpers.c:129:9`\ + `#7 0x56259bce7041 in blk_aio_complete qemu/build/../block/block-backend.c:1555:9`\ + `#8 0x56259c224495 in aio_bh_call qemu/build/../util/async.c:171:5`\ + `#9 0x56259c224ca6 in aio_bh_poll qemu/build/../util/async.c:218:13`\ + `#10 0x56259c1b9b89 in aio_dispatch qemu/build/../util/aio-posix.c:423:5`\ + `#11 0x56259c228f40 in aio_ctx_dispatch qemu/build/../util/async.c:360:5`\ + `#12 0x7f2b8c0a07a8 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x547a8) (BuildId: 9f90bd7bbfcf84a1f1c5a6102f70e6264837b9d4)`\ + `#13 0x56259c22a1ed in glib_pollfds_poll qemu/build/../util/main-loop.c:287:9`\ + `#14 0x56259c22a1ed in os_host_main_loop_wait qemu/build/../util/main-loop.c:310:5`\ + `#15 0x56259c22a1ed in main_loop_wait qemu/build/../util/main-loop.c:589:11`\ + `#16 0x56259af5159e in qemu_main_loop qemu/build/../system/runstate.c:796:9`\ + `#17 0x56259baefdb4 in qemu_default_main qemu/build/../system/main.c:37:14`\ + `#18 0x7f2b8aff7249 (/lib/x86_64-linux-gnu/libc.so.6+0x27249) (BuildId: 82ce4e6e4ef08fa58a3535f7437bd3e592db5ac0)`\ + `#19 0x7f2b8aff7304 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27304) (BuildId: 82ce4e6e4ef08fa58a3535f7437bd3e592db5ac0)`\ + `#20 0x562599f60b70 in _start (qemu/build/qemu-system-x86_64+0x20feb70) (BuildId: 48f1333e9a9d60383d8c9e0db5f690e7c26e1bb2)`\ +`AddressSanitizer can not provide additional info.`\ +`SUMMARY: AddressSanitizer: SEGV qemu/include/exec/memory.h:1152:12 in address_space_to_flatview`\ +`==168244==ABORTING` + +\ +But, if we manually put all of those qtest commands and wait for each command to complete, QEMU doesn't fail. It's because of possible race condition - while QEMU still mapping memory, we already starting to unmap it. It results in this crash. diff --git a/results/classifier/118/unknown/2415 b/results/classifier/118/unknown/2415 new file mode 100644 index 00000000..1eac4406 --- /dev/null +++ b/results/classifier/118/unknown/2415 @@ -0,0 +1,83 @@ +user-level: 0.928 +risc-v: 0.906 +mistranslation: 0.899 +device: 0.898 +graphic: 0.871 +network: 0.867 +register: 0.865 +virtual: 0.856 +peripherals: 0.845 +arm: 0.844 +debug: 0.843 +architecture: 0.833 +TCG: 0.825 +KVM: 0.824 +vnc: 0.822 +assembly: 0.821 +semantic: 0.810 +x86: 0.807 +VMM: 0.802 +kernel: 0.797 +permissions: 0.796 +performance: 0.792 +PID: 0.792 +ppc: 0.782 +files: 0.781 +hypervisor: 0.777 +boot: 0.772 +i386: 0.746 +socket: 0.745 + +Assertion `r->req.aiocb == NULL' in am53c974 device +Description of problem: +The following log reveals it: + +``` +qemu-truman-x86_64-4467afcc: qemu/hw/scsi/scsi-disk.c:558: void scsi_write_data(SCSIRequest *): Assertion `r->req.aiocb == NULL' failed. +==2957464== ERROR: libFuzzer: deadly signal + #0 0x55e76f00e911 in __sanitizer_print_stack_trace llvm/compiler-rt/lib/asan/asan_stack.cpp:87:3 + #1 0x55e76ef88fb8 in fuzzer::PrintStackTrace() llvm/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 + #2 0x55e76ef6d1b3 in fuzzer::Fuzzer::CrashCallback() llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 + #3 0x7f83d604251f (/lib/x86_64-linux-gnu/libc.so.6+0x4251f) + #4 0x7f83d60969fb in __pthread_kill_implementation nptl/./nptl/pthread_kill.c:43:17 + #5 0x7f83d60969fb in __pthread_kill_internal nptl/./nptl/pthread_kill.c:78:10 + #6 0x7f83d60969fb in pthread_kill nptl/./nptl/pthread_kill.c:89:10 + #7 0x7f83d6042475 in gsignal signal/../sysdeps/posix/raise.c:26:13 + #8 0x7f83d60287f2 in abort stdlib/./stdlib/abort.c:79:7 + #9 0x7f83d602871a in __assert_fail_base assert/./assert/assert.c:92:3 + #10 0x7f83d6039e95 in __assert_fail assert/./assert/assert.c:101:3 + #11 0x55e76fbb55a5 in scsi_write_data qemu/hw/scsi/scsi-disk.c:558:5 + #12 0x55e76fb95a1f in scsi_req_continue qemu/hw/scsi/scsi-bus.c + #13 0x55e76fbfe0cc in esp_do_dma qemu/hw/scsi/esp.c + #14 0x55e76fc0be39 in handle_ti qemu/hw/scsi/esp.c:1104:9 + #15 0x55e76fc042f6 in esp_run_cmd qemu/hw/scsi/esp.c:1186:9 + #16 0x55e76fc042f6 in esp_reg_write qemu/hw/scsi/esp.c:1304:9 + #17 0x55e76fc1329b in esp_pci_io_write qemu/hw/scsi/esp-pci.c:248:9 +``` +Steps to reproduce: +``` +cat << EOF | qemu-system-x86_64 -display none\ +-machine accel=qtest, -m 512M -device am53c974,id=scsi -device \ +scsi-hd,drive=disk0 -drive id=disk0,if=none,file=null-co://,format=raw \ +-nodefaults -qtest stdio +outl 0xcf8 0x80001010 +outl 0xcfc 0xc000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x05 +outl 0xc03e 0x030000 +outl 0xc009 0xc1000000 +outl 0xc008 0x8a +outl 0xc00d 0x0 +outl 0xc009 0x00 +outl 0xc00c 0x11 +outl 0xc00d 0x0 +outl 0xc00d 0x00 +outl 0xc00d 0x0 +outw 0xc00f 0x00 +outb 0xc00d 0x0 +outl 0xc00d 0x0 +outl 0xc009 0x41000000 +outb 0xc00c 0x90 +outl 0xc00d 0x0 +EOF +``` diff --git a/results/classifier/118/unknown/2558 b/results/classifier/118/unknown/2558 new file mode 100644 index 00000000..5abf8115 --- /dev/null +++ b/results/classifier/118/unknown/2558 @@ -0,0 +1,95 @@ +user-level: 0.915 +virtual: 0.876 +permissions: 0.875 +device: 0.871 +risc-v: 0.863 +graphic: 0.859 +ppc: 0.852 +register: 0.849 +files: 0.847 +boot: 0.829 +VMM: 0.829 +performance: 0.829 +arm: 0.826 +PID: 0.824 +kernel: 0.823 +hypervisor: 0.821 +architecture: 0.820 +KVM: 0.819 +x86: 0.817 +peripherals: 0.816 +socket: 0.815 +vnc: 0.809 +TCG: 0.805 +debug: 0.798 +semantic: 0.794 +i386: 0.780 +mistranslation: 0.780 +assembly: 0.776 +network: 0.756 + +riscv64: Ubuntu doesn't boot with EDK2, although it boots with u-boot +Description of problem: +Ubuntu doesn't boot with `edk2-riscv-code.fd`: + +```bash +wget https://cloud-images.ubuntu.com/noble/20240822/noble-server-cloudimg-riscv64.img + +qemu-system-riscv64 -M virt -m 2048 -nographic -hda noble-server-cloudimg-riscv64.img \ + -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-riscv-code.fd +``` + + +``` +Loading Linux 6.8.0-41-generic ... +Loading initial ramdisk ... +InstallProtocolInterface: 4006C0C1-FCB3-403E-996D-4A6C8724E06D FDB3F3C8 +InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B FDB3F380 +[Security] 3rd party image[0] can be loaded after EndOfDxe: MemoryMapped(0x2,0xF9CC4000,0xFC194000). +InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B FF29C2C0 +Loading driver at 0x000F732C000 EntryPoint=0x000F817FEA6 +InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF FF29CC18 +ProtectUefiImageCommon - 0xFF29C2C0 + - 0x00000000F732C000 - 0x0000000002598000 +SetUefiImageMemoryAttributes - 0x00000000F732C000 - 0x0000000000001000 (0x0000000000004000) +SetUefiImageMemoryAttributes - 0x00000000F732D000 - 0x0000000000FFF000 (0x0000000000020000) +SetUefiImageMemoryAttributes - 0x00000000F832C000 - 0x0000000001598000 (0x0000000000004000) +TimerDriverSetTimerPeriod(0x0) +SetUefiImageMemoryAttributes - 0x00000000FFEC7000 - 0x000000000000C000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFEBC000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFEAC000 - 0x0000000000010000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFEA1000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE84000 - 0x000000000001D000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE79000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE6E000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE63000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE59000 - 0x000000000000A000 (0x0000000000000000) +(hangs here) +``` + +The same disk image still boots when `uboot.elf` is specified as the kernel image: + +```bash +wget https://github.com/lima-vm/u-boot-qemu-mirror/releases/download/2023.07%2Bdfsg-1/qemu-riscv64_smode_uboot.elf + +qemu-system-riscv64 -M virt -m 2048 -nographic -hda noble-server-cloudimg-riscv64.img \ + -kernel qemu-riscv64_smode_uboot.elf +``` + +``` +Loading Linux 6.8.0-41-generic ... +Loading initial ramdisk ... +syscon-poweroff poweroff: pm_power_off already claimed for sbi_srst_power_off +-.mount +etc-machine\x2did.mount +systemd-journald.service +dev-hugepages.mount +... +Ubuntu 24.04 LTS ubuntu ttyS0 + +ubuntu login: +``` +Steps to reproduce: +See above +Additional information: + diff --git a/results/classifier/118/unknown/2574 b/results/classifier/118/unknown/2574 new file mode 100644 index 00000000..924e69b7 --- /dev/null +++ b/results/classifier/118/unknown/2574 @@ -0,0 +1,79 @@ +permissions: 0.921 +device: 0.920 +register: 0.919 +risc-v: 0.910 +user-level: 0.904 +semantic: 0.893 +performance: 0.889 +debug: 0.873 +virtual: 0.872 +boot: 0.871 +arm: 0.870 +graphic: 0.854 +assembly: 0.853 +architecture: 0.843 +PID: 0.833 +peripherals: 0.831 +mistranslation: 0.831 +hypervisor: 0.826 +socket: 0.824 +x86: 0.818 +VMM: 0.809 +kernel: 0.795 +vnc: 0.794 +files: 0.785 +network: 0.772 +KVM: 0.771 +i386: 0.761 +ppc: 0.747 +TCG: 0.733 + +VM hang: 'error: kvm run failed Bad address' with some AMD GPUs since kernel 6.7 +Description of problem: +The Debian ROCm Team runs GPU-utilizing test workloads in QEMU VMs into which we pass through AMD GPUs attached to PCIe x16 slots on the host. We do this to quickly test various Debian distributions/kernels/firmwares on a single physical host per GPU, and to isolate the host as much as possible from potentially hostile code. + +Starting with kernel 6.7 in the **guest**, with Navi 31 GPUs (eg: RX 7900 XT), as soon as anything triggers access to the GPU's memory, the VM hangs with `error: kvm run failed Bad address` and dumps its state. + +I gather that [this](https://gitlab.com/qemu-project/qemu/-/blob/ea9cdbcf3a0b8d5497cddf87990f1b39d8f3bb0a/accel/kvm/kvm-all.c#L3046-L3048) is where this message originates from. It would seem that the preceding [ioctl](https://gitlab.com/qemu-project/qemu/-/blob/ea9cdbcf3a0b8d5497cddf87990f1b39d8f3bb0a/accel/kvm/kvm-all.c#L3025) runs into `EFAULT` which eventually leads to a break out of the surrounding loop. + +Since we can reliably reproduce this starting with 6.7, our assumption is that this is caused by a change in the kernel and/or the `amdgpu` driver. However, as the error originates from kvm *on the host*, we could not rule out that this might also be a emulation issue. In particular, it was only 9.1 [c15e568](c15e568) where the handling of the `EFAULT` and `KVM_EXIT_MEMORY_FAULT` case was added, so perhaps we ran into something that is still incomplete. + +I'd appreciate any advice you could give us for further debugging. We will bisect 6.7 to see what could have triggered this on the guest side, but is there something that we can do on the host to further track this down, in particular which `-trace`s might be helpful? + +Other notes: +- The VM boots and runs fine, GPU initializes fine according to `dmesg`. The issue is only triggered on GPU utilization +- The problematic GPU in question worked fine with kernels 6.3 - 6.6 +- All other GPU architectures that we test this way (eg: Navi 2x) do not experience this issue, they work fine with all kernels we tested +- We have checked with more than one GPU, to rule out a physical defect +Steps to reproduce: +Reproducing the issue requires +1. A suitable image +2. Access to a Navi 3x card. Remote access can be arranged, if necessary. + +Building a suitable image can be rather complicated and requires a Debian host. If needed, it would be easier for me to just share a pre-built image. +Additional information: +This is dumped just before the VM hangs: +``` +ROCk module is loaded +error: kvm run failed Bad address +RAX=00000000000035c8 RBX=00000000000006ba RCX=0003000108b08073 RDX=00000000000006b9 +RSI=ffff9994b00035c8 RDI=ffff899403c80000 RBP=ffff899408b285e0 RSP=ffff9994816ab620 +R8 =0003000000000073 R9 =ffff9994b0000000 R10=ffff899403c8fb18 R11=ffff899408b065b8 +R12=ffff899403c80000 R13=0003000000000073 R14=ffff9994b0000000 R15=00000000000006ba +RIP=ffffffffc11d8f93 RFL=00000282 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 00000000 00000000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 00000000 00000000 +FS =0000 00007faa76aea780 00000000 00000000 +GS =0000 ffff899f0dd80000 00000000 00000000 +LDT=0000 0000000000000000 00000000 00000000 +TR =0040 fffffe41c66fc000 00004087 00008b00 DPL=0 TSS64-busy +GDT= fffffe41c66fa000 0000007f +IDT= fffffe0000000000 00000fff +CR0=80050033 CR2=000055bd5a5d8598 CR3=000000010342c000 CR4=00750ef0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +Code=ff ff 00 00 48 21 c1 8d 04 d5 00 00 00 00 4c 09 c1 48 01 c6 <48> 89 0e 31 c0 e9 6e b1 92 d2 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 +``` diff --git a/results/classifier/118/unknown/25842545 b/results/classifier/118/unknown/25842545 new file mode 100644 index 00000000..57bfa9ac --- /dev/null +++ b/results/classifier/118/unknown/25842545 @@ -0,0 +1,227 @@ +user-level: 0.958 +risc-v: 0.929 +mistranslation: 0.928 +register: 0.879 +VMM: 0.871 +KVM: 0.867 +ppc: 0.866 +vnc: 0.862 +TCG: 0.857 +device: 0.847 +virtual: 0.843 +hypervisor: 0.841 +debug: 0.836 +performance: 0.831 +semantic: 0.829 +PID: 0.829 +peripherals: 0.829 +boot: 0.824 +assembly: 0.824 +graphic: 0.822 +x86: 0.821 +i386: 0.819 +arm: 0.818 +permissions: 0.817 +socket: 0.808 +kernel: 0.808 +files: 0.806 +architecture: 0.804 +network: 0.796 + +[Qemu-devel] [Bug?] Guest pause because VMPTRLD failed in KVM + +Hello, + + We encountered a problem that a guest paused because the KMOD report VMPTRLD +failed. + +The related information is as follows: + +1) Qemu command: + /usr/bin/qemu-kvm -name omu1 -S -machine pc-i440fx-2.3,accel=kvm,usb=off -cpu +host -m 15625 -realtime mlock=off -smp 8,sockets=1,cores=8,threads=1 -uuid +a2aacfff-6583-48b4-b6a4-e6830e519931 -no-user-config -nodefaults -chardev +socket,id=charmonitor,path=/var/lib/libvirt/qemu/omu1.monitor,server,nowait +-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown +-boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device +virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive +file=/home/env/guest1.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,aio=native + -device +virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 + -drive +file=/home/env/guest_300G.img,if=none,id=drive-virtio-disk1,format=raw,cache=none,aio=native + -device +virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 + -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device +virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:80:05:00:00,bus=pci.0,addr=0x3 +-netdev tap,fd=27,id=hostnet1,vhost=on,vhostfd=28 -device +virtio-net-pci,netdev=hostnet1,id=net1,mac=00:00:80:05:00:01,bus=pci.0,addr=0x4 +-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 +-device usb-tablet,id=input0 -vnc 0.0.0.0:0 -device +cirrus-vga,id=video0,vgamem_mb=16,bus=pci.0,addr=0x2 -device +virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on + + 2) Qemu log: + KVM: entry failed, hardware error 0x4 + RAX=00000000ffffffed RBX=ffff8803fa2d7fd8 RCX=0100000000000000 +RDX=0000000000000000 + RSI=0000000000000000 RDI=0000000000000046 RBP=ffff8803fa2d7e90 +RSP=ffff8803fa2efe90 + R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 +R11=000000000000b69a + R12=0000000000000001 R13=ffffffff81a25b40 R14=0000000000000000 +R15=ffff8803fa2d7fd8 + RIP=ffffffff81053e16 RFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 + ES =0000 0000000000000000 ffffffff 00c00000 + CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] + SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] + DS =0000 0000000000000000 ffffffff 00c00000 + FS =0000 0000000000000000 ffffffff 00c00000 + GS =0000 ffff88040f540000 ffffffff 00c00000 + LDT=0000 0000000000000000 ffffffff 00c00000 + TR =0040 ffff88040f550a40 00002087 00008b00 DPL=0 TSS64-busy + GDT= ffff88040f549000 0000007f + IDT= ffffffffff529000 00000fff + CR0=80050033 CR2=00007f81ca0c5000 CR3=00000003f5081000 CR4=000407e0 + DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 +DR3=0000000000000000 + DR6=00000000ffff0ff0 DR7=0000000000000400 + EFER=0000000000000d01 + Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? <??> ?? ?? +?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? + + 3) Demsg + [347315.028339] kvm: vmptrld ffff8817ec5f0000/17ec5f0000 failed + klogd 1.4.1, ---------- state change ---------- + [347315.039506] kvm: vmptrld ffff8817ec5f0000/17ec5f0000 failed + [347315.051728] kvm: vmptrld ffff8817ec5f0000/17ec5f0000 failed + [347315.057472] vmwrite error: reg 6c0a value ffff88307e66e480 (err +2120672384) + [347315.064567] Pid: 69523, comm: qemu-kvm Tainted: GF X +3.0.93-0.8-default #1 + [347315.064569] Call Trace: + [347315.064587] [<ffffffff810049d5>] dump_trace+0x75/0x300 + [347315.064595] [<ffffffff8145e3e3>] dump_stack+0x69/0x6f + [347315.064617] [<ffffffffa03738de>] vmx_vcpu_load+0x11e/0x1d0 [kvm_intel] + [347315.064647] [<ffffffffa029a204>] kvm_arch_vcpu_load+0x44/0x1d0 [kvm] + [347315.064669] [<ffffffff81054ee1>] finish_task_switch+0x81/0xe0 + [347315.064676] [<ffffffff8145f0b4>] thread_return+0x3b/0x2a7 + [347315.064687] [<ffffffffa028d9b5>] kvm_vcpu_block+0x65/0xa0 [kvm] + [347315.064703] [<ffffffffa02a16d1>] __vcpu_run+0xd1/0x260 [kvm] + [347315.064732] [<ffffffffa02a2418>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 +[kvm] + [347315.064759] [<ffffffffa028ecee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] + [347315.064771] [<ffffffff8116bdfb>] do_vfs_ioctl+0x8b/0x3b0 + [347315.064776] [<ffffffff8116c1c1>] sys_ioctl+0xa1/0xb0 + [347315.064783] [<ffffffff81469272>] system_call_fastpath+0x16/0x1b + [347315.064797] [<00007fee51969ce7>] 0x7fee51969ce6 + [347315.064799] vmwrite error: reg 6c0c value ffff88307e664000 (err +2120630272) + [347315.064802] Pid: 69523, comm: qemu-kvm Tainted: GF X +3.0.93-0.8-default #1 + [347315.064803] Call Trace: + [347315.064807] [<ffffffff810049d5>] dump_trace+0x75/0x300 + [347315.064811] [<ffffffff8145e3e3>] dump_stack+0x69/0x6f + [347315.064817] [<ffffffffa03738ec>] vmx_vcpu_load+0x12c/0x1d0 [kvm_intel] + [347315.064832] [<ffffffffa029a204>] kvm_arch_vcpu_load+0x44/0x1d0 [kvm] + [347315.064851] [<ffffffff81054ee1>] finish_task_switch+0x81/0xe0 + [347315.064855] [<ffffffff8145f0b4>] thread_return+0x3b/0x2a7 + [347315.064865] [<ffffffffa028d9b5>] kvm_vcpu_block+0x65/0xa0 [kvm] + [347315.064880] [<ffffffffa02a16d1>] __vcpu_run+0xd1/0x260 [kvm] + [347315.064907] [<ffffffffa02a2418>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 +[kvm] + [347315.064933] [<ffffffffa028ecee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] + [347315.064943] [<ffffffff8116bdfb>] do_vfs_ioctl+0x8b/0x3b0 + [347315.064947] [<ffffffff8116c1c1>] sys_ioctl+0xa1/0xb0 + [347315.064951] [<ffffffff81469272>] system_call_fastpath+0x16/0x1b + [347315.064957] [<00007fee51969ce7>] 0x7fee51969ce6 + [347315.064959] vmwrite error: reg 6c10 value 0 (err 0) + + 4) The isssue can't be reporduced. I search the Intel VMX sepc about reaseons +of vmptrld failure: + The instruction fails if its operand is not properly aligned, sets +unsupported physical-address bits, or is equal to the VMXON + pointer. In addition, the instruction fails if the 32 bits in memory +referenced by the operand do not match the VMCS + revision identifier supported by this processor. + + But I can't find any cues from the KVM source code. It seems each + error conditions is impossible in theory. :( + +Any suggestions will be appreciated! Paolo? + +-- +Regards, +-Gonglei + +On 10/11/2016 15:10, gong lei wrote: +> +4) The isssue can't be reporduced. I search the Intel VMX sepc about +> +reaseons +> +of vmptrld failure: +> +The instruction fails if its operand is not properly aligned, sets +> +unsupported physical-address bits, or is equal to the VMXON +> +pointer. In addition, the instruction fails if the 32 bits in memory +> +referenced by the operand do not match the VMCS +> +revision identifier supported by this processor. +> +> +But I can't find any cues from the KVM source code. It seems each +> +error conditions is impossible in theory. :( +Yes, it should not happen. :( + +If it's not reproducible, it's really hard to say what it was, except a +random memory corruption elsewhere or even a bit flip (!). + +Paolo + +On 2016/11/17 20:39, Paolo Bonzini wrote: +> +> +On 10/11/2016 15:10, gong lei wrote: +> +> 4) The isssue can't be reporduced. I search the Intel VMX sepc about +> +> reaseons +> +> of vmptrld failure: +> +> The instruction fails if its operand is not properly aligned, sets +> +> unsupported physical-address bits, or is equal to the VMXON +> +> pointer. In addition, the instruction fails if the 32 bits in memory +> +> referenced by the operand do not match the VMCS +> +> revision identifier supported by this processor. +> +> +> +> But I can't find any cues from the KVM source code. It seems each +> +> error conditions is impossible in theory. :( +> +Yes, it should not happen. :( +> +> +If it's not reproducible, it's really hard to say what it was, except a +> +random memory corruption elsewhere or even a bit flip (!). +> +> +Paolo +Thanks for your reply, Paolo :) + +-- +Regards, +-Gonglei + diff --git a/results/classifier/118/unknown/25892827 b/results/classifier/118/unknown/25892827 new file mode 100644 index 00000000..f8a10ccb --- /dev/null +++ b/results/classifier/118/unknown/25892827 @@ -0,0 +1,1102 @@ +risc-v: 0.908 +user-level: 0.889 +permissions: 0.881 +register: 0.876 +KVM: 0.872 +hypervisor: 0.871 +debug: 0.868 +x86: 0.849 +vnc: 0.846 +mistranslation: 0.842 +boot: 0.839 +network: 0.839 +VMM: 0.839 +device: 0.839 +TCG: 0.837 +virtual: 0.835 +i386: 0.835 +peripherals: 0.833 +graphic: 0.832 +assembly: 0.829 +architecture: 0.825 +semantic: 0.825 +ppc: 0.824 +socket: 0.822 +arm: 0.821 +performance: 0.819 +kernel: 0.810 +files: 0.804 +PID: 0.792 + +[Qemu-devel] [BUG/RFC] Two cpus are not brought up normally in SLES11 sp3 VM after reboot + +Hi, + +Recently we encountered a problem in our project: 2 CPUs in VM are not brought +up normally after reboot. + +Our host is using KVM kmod 3.6 and QEMU 2.1. +A SLES 11 sp3 VM configured with 8 vcpus, +cpu model is configured with 'host-passthrough'. + +After VM's first time started up, everything seems to be OK. +and then VM is paniced and rebooted. +After reboot, only 6 cpus are brought up in VM, cpu1 and cpu7 are not online. + +This is the only message we can get from VM: +VM dmesg shows: +[ 0.069867] Booting Node 0, Processors #1 +[ 5.060042] CPU1: Stuck ?? +[ 5.060499] #2 +[ 5.088322] kvm-clock: cpu 2, msr 6:3fc90901, secondary cpu clock +[ 5.088335] KVM setup async PF for cpu 2 +[ 5.092967] NMI watchdog enabled, takes one hw-pmu counter. +[ 5.094405] #3 +[ 5.108324] kvm-clock: cpu 3, msr 6:3fcd0901, secondary cpu clock +[ 5.108333] KVM setup async PF for cpu 3 +[ 5.113553] NMI watchdog enabled, takes one hw-pmu counter. +[ 5.114970] #4 +[ 5.128325] kvm-clock: cpu 4, msr 6:3fd10901, secondary cpu clock +[ 5.128336] KVM setup async PF for cpu 4 +[ 5.134576] NMI watchdog enabled, takes one hw-pmu counter. +[ 5.135998] #5 +[ 5.152324] kvm-clock: cpu 5, msr 6:3fd50901, secondary cpu clock +[ 5.152334] KVM setup async PF for cpu 5 +[ 5.154764] NMI watchdog enabled, takes one hw-pmu counter. +[ 5.156467] #6 +[ 5.172327] kvm-clock: cpu 6, msr 6:3fd90901, secondary cpu clock +[ 5.172341] KVM setup async PF for cpu 6 +[ 5.180738] NMI watchdog enabled, takes one hw-pmu counter. +[ 5.182173] #7 Ok. +[ 10.170815] CPU7: Stuck ?? +[ 10.171648] Brought up 6 CPUs +[ 10.172394] Total of 6 processors activated (28799.97 BogoMIPS). + +From host, we found that QEMU vcpu1 thread and vcpu7 thread were not consuming +any cpu (Should be in idle state), +All of VCPUs' stacks in host is like bellow: + +[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm] +[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm] +[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] +[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] +[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0 +[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0 +[<ffffffff81468092>] system_call_fastpath+0x16/0x1b +[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7 +[<ffffffffffffffff>] 0xffffffffffffffff + +We looked into the kernel codes that could leading to the above 'Stuck' warning, +and found that the only possible is the emulation of 'cpuid' instruct in +kvm/qemu has something wrong. +But since we canât reproduce this problem, we are not quite sure. +Is there any possible that the cupid emulation in kvm/qemu has some bug ? + +Has anyone come across these problem before? Or any idea? + +Thanks, +zhanghailiang + +On 06/07/2015 09:54, zhanghailiang wrote: +> +> +From host, we found that QEMU vcpu1 thread and vcpu7 thread were not +> +consuming any cpu (Should be in idle state), +> +All of VCPUs' stacks in host is like bellow: +> +> +[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm] +> +[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm] +> +[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] +> +[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] +> +[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0 +> +[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0 +> +[<ffffffff81468092>] system_call_fastpath+0x16/0x1b +> +[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7 +> +[<ffffffffffffffff>] 0xffffffffffffffff +> +> +We looked into the kernel codes that could leading to the above 'Stuck' +> +warning, +> +and found that the only possible is the emulation of 'cpuid' instruct in +> +kvm/qemu has something wrong. +> +But since we canât reproduce this problem, we are not quite sure. +> +Is there any possible that the cupid emulation in kvm/qemu has some bug ? +Can you explain the relationship to the cpuid emulation? What do the +traces say about vcpus 1 and 7? + +Paolo + +On 2015/7/6 16:45, Paolo Bonzini wrote: +On 06/07/2015 09:54, zhanghailiang wrote: +From host, we found that QEMU vcpu1 thread and vcpu7 thread were not +consuming any cpu (Should be in idle state), +All of VCPUs' stacks in host is like bellow: + +[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm] +[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm] +[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] +[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] +[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0 +[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0 +[<ffffffff81468092>] system_call_fastpath+0x16/0x1b +[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7 +[<ffffffffffffffff>] 0xffffffffffffffff + +We looked into the kernel codes that could leading to the above 'Stuck' +warning, +and found that the only possible is the emulation of 'cpuid' instruct in +kvm/qemu has something wrong. +But since we canât reproduce this problem, we are not quite sure. +Is there any possible that the cupid emulation in kvm/qemu has some bug ? +Can you explain the relationship to the cpuid emulation? What do the +traces say about vcpus 1 and 7? +OK, we searched the VM's kernel codes with the 'Stuck' message, and it is +located in +do_boot_cpu(). It's in BSP context, the call process is: +BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> do_boot_cpu() +-> wakeup_secondary_via_INIT() to trigger APs. +It will wait 5s for APs to startup, if some AP not startup normally, it will +print 'CPU%d Stuck' or 'CPU%d: Not responding'. + +If it prints 'Stuck', it means the AP has received the SIPI interrupt and +begins to execute the code +'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places before +smp_callin()(smpboot.c). +The follow is the starup process of BSP and AP. +BSP: +start_kernel() + ->smp_init() + ->smp_boot_cpus() + ->do_boot_cpu() + ->start_ip = trampoline_address(); //set the address that AP will go +to execute + ->wakeup_secondary_cpu_via_init(); // kick the secondary CPU + ->for (timeout = 0; timeout < 50000; timeout++) + if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// check if AP +startup or not + +APs: +ENTRY(trampoline_data) (trampoline_64.S) + ->ENTRY(secondary_startup_64) (head_64.S) + ->start_secondary() (smpboot.c) + ->cpu_init(); + ->smp_callin(); + ->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP comes +here, the BSP will not prints the error message. + +From above call process, we can be sure that, the AP has been stuck between +trampoline_data and the cpumask_set_cpu() in +smp_callin(), we look through these codes path carefully, and only found a +'hlt' instruct that could block the process. +It is located in trampoline_data(): + +ENTRY(trampoline_data) + ... + + call verify_cpu # Verify the cpu supports long mode + testl %eax, %eax # Check for return code + jnz no_longmode + + ... + +no_longmode: + hlt + jmp no_longmode + +For the process verify_cpu(), +we can only find the 'cpuid' sensitive instruct that could lead VM exit from +No-root mode. +This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading to +the fail in verify_cpu. + +From the message in VM, we know vcpu1 and vcpu7 is something wrong. +[ 5.060042] CPU1: Stuck ?? +[ 10.170815] CPU7: Stuck ?? +[ 10.171648] Brought up 6 CPUs + +Besides, the follow is the cpus message got from host. +80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh qemu-monitor-command +instance-0000000 +* CPU #0: pc=0x00007f64160c683d thread_id=68570 + CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573 + CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575 + CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576 + CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577 + CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578 + CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583 + CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584 + +Oh, i also forgot to mention in the above message that, we have bond each vCPU +to different physical CPU in +host. + +Thanks, +zhanghailiang + +On 06/07/2015 11:59, zhanghailiang wrote: +> +> +> +Besides, the follow is the cpus message got from host. +> +80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh +> +qemu-monitor-command instance-0000000 +> +* CPU #0: pc=0x00007f64160c683d thread_id=68570 +> +CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573 +> +CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575 +> +CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576 +> +CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577 +> +CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578 +> +CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583 +> +CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584 +> +> +Oh, i also forgot to mention in the above message that, we have bond +> +each vCPU to different physical CPU in +> +host. +Can you capture a trace on the host (trace-cmd record -e kvm) and send +it privately? Please note which CPUs get stuck, since I guess it's not +always 1 and 7. + +Paolo + +On Mon, 6 Jul 2015 17:59:10 +0800 +zhanghailiang <address@hidden> wrote: + +> +On 2015/7/6 16:45, Paolo Bonzini wrote: +> +> +> +> +> +> On 06/07/2015 09:54, zhanghailiang wrote: +> +>> +> +>> From host, we found that QEMU vcpu1 thread and vcpu7 thread were not +> +>> consuming any cpu (Should be in idle state), +> +>> All of VCPUs' stacks in host is like bellow: +> +>> +> +>> [<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm] +> +>> [<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm] +> +>> [<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] +> +>> [<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] +> +>> [<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0 +> +>> [<ffffffff8116c251>] sys_ioctl+0xa1/0xb0 +> +>> [<ffffffff81468092>] system_call_fastpath+0x16/0x1b +> +>> [<00002ab9fe1f99a7>] 0x2ab9fe1f99a7 +> +>> [<ffffffffffffffff>] 0xffffffffffffffff +> +>> +> +>> We looked into the kernel codes that could leading to the above 'Stuck' +> +>> warning, +in current upstream there isn't any printk(...Stuck...) left since that code +path +has been reworked. +I've often seen this on over-committed host during guest CPUs up/down torture +test. +Could you update guest kernel to upstream and see if issue reproduces? + +> +>> and found that the only possible is the emulation of 'cpuid' instruct in +> +>> kvm/qemu has something wrong. +> +>> But since we canât reproduce this problem, we are not quite sure. +> +>> Is there any possible that the cupid emulation in kvm/qemu has some bug ? +> +> +> +> Can you explain the relationship to the cpuid emulation? What do the +> +> traces say about vcpus 1 and 7? +> +> +OK, we searched the VM's kernel codes with the 'Stuck' message, and it is +> +located in +> +do_boot_cpu(). It's in BSP context, the call process is: +> +BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> do_boot_cpu() +> +-> wakeup_secondary_via_INIT() to trigger APs. +> +It will wait 5s for APs to startup, if some AP not startup normally, it will +> +print 'CPU%d Stuck' or 'CPU%d: Not responding'. +> +> +If it prints 'Stuck', it means the AP has received the SIPI interrupt and +> +begins to execute the code +> +'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places +> +before smp_callin()(smpboot.c). +> +The follow is the starup process of BSP and AP. +> +BSP: +> +start_kernel() +> +->smp_init() +> +->smp_boot_cpus() +> +->do_boot_cpu() +> +->start_ip = trampoline_address(); //set the address that AP will +> +go to execute +> +->wakeup_secondary_cpu_via_init(); // kick the secondary CPU +> +->for (timeout = 0; timeout < 50000; timeout++) +> +if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// check if +> +AP startup or not +> +> +APs: +> +ENTRY(trampoline_data) (trampoline_64.S) +> +->ENTRY(secondary_startup_64) (head_64.S) +> +->start_secondary() (smpboot.c) +> +->cpu_init(); +> +->smp_callin(); +> +->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP +> +comes here, the BSP will not prints the error message. +> +> +From above call process, we can be sure that, the AP has been stuck between +> +trampoline_data and the cpumask_set_cpu() in +> +smp_callin(), we look through these codes path carefully, and only found a +> +'hlt' instruct that could block the process. +> +It is located in trampoline_data(): +> +> +ENTRY(trampoline_data) +> +... +> +> +call verify_cpu # Verify the cpu supports long mode +> +testl %eax, %eax # Check for return code +> +jnz no_longmode +> +> +... +> +> +no_longmode: +> +hlt +> +jmp no_longmode +> +> +For the process verify_cpu(), +> +we can only find the 'cpuid' sensitive instruct that could lead VM exit from +> +No-root mode. +> +This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading to +> +the fail in verify_cpu. +> +> +From the message in VM, we know vcpu1 and vcpu7 is something wrong. +> +[ 5.060042] CPU1: Stuck ?? +> +[ 10.170815] CPU7: Stuck ?? +> +[ 10.171648] Brought up 6 CPUs +> +> +Besides, the follow is the cpus message got from host. +> +80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh +> +qemu-monitor-command instance-0000000 +> +* CPU #0: pc=0x00007f64160c683d thread_id=68570 +> +CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573 +> +CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575 +> +CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576 +> +CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577 +> +CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578 +> +CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583 +> +CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584 +> +> +Oh, i also forgot to mention in the above message that, we have bond each +> +vCPU to different physical CPU in +> +host. +> +> +Thanks, +> +zhanghailiang +> +> +> +> +> +-- +> +To unsubscribe from this list: send the line "unsubscribe kvm" in +> +the body of a message to address@hidden +> +More majordomo info at +http://vger.kernel.org/majordomo-info.html + +On 2015/7/7 19:23, Igor Mammedov wrote: +On Mon, 6 Jul 2015 17:59:10 +0800 +zhanghailiang <address@hidden> wrote: +On 2015/7/6 16:45, Paolo Bonzini wrote: +On 06/07/2015 09:54, zhanghailiang wrote: +From host, we found that QEMU vcpu1 thread and vcpu7 thread were not +consuming any cpu (Should be in idle state), +All of VCPUs' stacks in host is like bellow: + +[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm] +[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm] +[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] +[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] +[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0 +[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0 +[<ffffffff81468092>] system_call_fastpath+0x16/0x1b +[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7 +[<ffffffffffffffff>] 0xffffffffffffffff + +We looked into the kernel codes that could leading to the above 'Stuck' +warning, +in current upstream there isn't any printk(...Stuck...) left since that code +path +has been reworked. +I've often seen this on over-committed host during guest CPUs up/down torture +test. +Could you update guest kernel to upstream and see if issue reproduces? +Hmm, Unfortunately, it is very hard to reproduce, and we are still trying to +reproduce it. + +For your test case, is it a kernel bug? +Or is there any related patch could solve your test problem been merged into +upstream ? + +Thanks, +zhanghailiang +and found that the only possible is the emulation of 'cpuid' instruct in +kvm/qemu has something wrong. +But since we canât reproduce this problem, we are not quite sure. +Is there any possible that the cupid emulation in kvm/qemu has some bug ? +Can you explain the relationship to the cpuid emulation? What do the +traces say about vcpus 1 and 7? +OK, we searched the VM's kernel codes with the 'Stuck' message, and it is +located in +do_boot_cpu(). It's in BSP context, the call process is: +BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> do_boot_cpu() +-> wakeup_secondary_via_INIT() to trigger APs. +It will wait 5s for APs to startup, if some AP not startup normally, it will +print 'CPU%d Stuck' or 'CPU%d: Not responding'. + +If it prints 'Stuck', it means the AP has received the SIPI interrupt and +begins to execute the code +'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places before +smp_callin()(smpboot.c). +The follow is the starup process of BSP and AP. +BSP: +start_kernel() + ->smp_init() + ->smp_boot_cpus() + ->do_boot_cpu() + ->start_ip = trampoline_address(); //set the address that AP will +go to execute + ->wakeup_secondary_cpu_via_init(); // kick the secondary CPU + ->for (timeout = 0; timeout < 50000; timeout++) + if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// check if +AP startup or not + +APs: +ENTRY(trampoline_data) (trampoline_64.S) + ->ENTRY(secondary_startup_64) (head_64.S) + ->start_secondary() (smpboot.c) + ->cpu_init(); + ->smp_callin(); + ->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP +comes here, the BSP will not prints the error message. + + From above call process, we can be sure that, the AP has been stuck between +trampoline_data and the cpumask_set_cpu() in +smp_callin(), we look through these codes path carefully, and only found a +'hlt' instruct that could block the process. +It is located in trampoline_data(): + +ENTRY(trampoline_data) + ... + + call verify_cpu # Verify the cpu supports long mode + testl %eax, %eax # Check for return code + jnz no_longmode + + ... + +no_longmode: + hlt + jmp no_longmode + +For the process verify_cpu(), +we can only find the 'cpuid' sensitive instruct that could lead VM exit from +No-root mode. +This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading to +the fail in verify_cpu. + + From the message in VM, we know vcpu1 and vcpu7 is something wrong. +[ 5.060042] CPU1: Stuck ?? +[ 10.170815] CPU7: Stuck ?? +[ 10.171648] Brought up 6 CPUs + +Besides, the follow is the cpus message got from host. +80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh qemu-monitor-command +instance-0000000 +* CPU #0: pc=0x00007f64160c683d thread_id=68570 + CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573 + CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575 + CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576 + CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577 + CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578 + CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583 + CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584 + +Oh, i also forgot to mention in the above message that, we have bond each vCPU +to different physical CPU in +host. + +Thanks, +zhanghailiang + + + + +-- +To unsubscribe from this list: send the line "unsubscribe kvm" in +the body of a message to address@hidden +More majordomo info at +http://vger.kernel.org/majordomo-info.html +. + +On Tue, 7 Jul 2015 19:43:35 +0800 +zhanghailiang <address@hidden> wrote: + +> +On 2015/7/7 19:23, Igor Mammedov wrote: +> +> On Mon, 6 Jul 2015 17:59:10 +0800 +> +> zhanghailiang <address@hidden> wrote: +> +> +> +>> On 2015/7/6 16:45, Paolo Bonzini wrote: +> +>>> +> +>>> +> +>>> On 06/07/2015 09:54, zhanghailiang wrote: +> +>>>> +> +>>>> From host, we found that QEMU vcpu1 thread and vcpu7 thread were not +> +>>>> consuming any cpu (Should be in idle state), +> +>>>> All of VCPUs' stacks in host is like bellow: +> +>>>> +> +>>>> [<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm] +> +>>>> [<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm] +> +>>>> [<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] +> +>>>> [<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] +> +>>>> [<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0 +> +>>>> [<ffffffff8116c251>] sys_ioctl+0xa1/0xb0 +> +>>>> [<ffffffff81468092>] system_call_fastpath+0x16/0x1b +> +>>>> [<00002ab9fe1f99a7>] 0x2ab9fe1f99a7 +> +>>>> [<ffffffffffffffff>] 0xffffffffffffffff +> +>>>> +> +>>>> We looked into the kernel codes that could leading to the above 'Stuck' +> +>>>> warning, +> +> in current upstream there isn't any printk(...Stuck...) left since that +> +> code path +> +> has been reworked. +> +> I've often seen this on over-committed host during guest CPUs up/down +> +> torture test. +> +> Could you update guest kernel to upstream and see if issue reproduces? +> +> +> +> +Hmm, Unfortunately, it is very hard to reproduce, and we are still trying to +> +reproduce it. +> +> +For your test case, is it a kernel bug? +> +Or is there any related patch could solve your test problem been merged into +> +upstream ? +I don't remember all prerequisite patches but you should be able to find +http://marc.info/?l=linux-kernel&m=140326703108009&w=2 +"x86/smpboot: Initialize secondary CPU only if master CPU will wait for it" +and then look for dependencies. + + +> +> +Thanks, +> +zhanghailiang +> +> +>>>> and found that the only possible is the emulation of 'cpuid' instruct in +> +>>>> kvm/qemu has something wrong. +> +>>>> But since we canât reproduce this problem, we are not quite sure. +> +>>>> Is there any possible that the cupid emulation in kvm/qemu has some bug ? +> +>>> +> +>>> Can you explain the relationship to the cpuid emulation? What do the +> +>>> traces say about vcpus 1 and 7? +> +>> +> +>> OK, we searched the VM's kernel codes with the 'Stuck' message, and it is +> +>> located in +> +>> do_boot_cpu(). It's in BSP context, the call process is: +> +>> BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> +> +>> do_boot_cpu() -> wakeup_secondary_via_INIT() to trigger APs. +> +>> It will wait 5s for APs to startup, if some AP not startup normally, it +> +>> will print 'CPU%d Stuck' or 'CPU%d: Not responding'. +> +>> +> +>> If it prints 'Stuck', it means the AP has received the SIPI interrupt and +> +>> begins to execute the code +> +>> 'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places +> +>> before smp_callin()(smpboot.c). +> +>> The follow is the starup process of BSP and AP. +> +>> BSP: +> +>> start_kernel() +> +>> ->smp_init() +> +>> ->smp_boot_cpus() +> +>> ->do_boot_cpu() +> +>> ->start_ip = trampoline_address(); //set the address that AP +> +>> will go to execute +> +>> ->wakeup_secondary_cpu_via_init(); // kick the secondary CPU +> +>> ->for (timeout = 0; timeout < 50000; timeout++) +> +>> if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// +> +>> check if AP startup or not +> +>> +> +>> APs: +> +>> ENTRY(trampoline_data) (trampoline_64.S) +> +>> ->ENTRY(secondary_startup_64) (head_64.S) +> +>> ->start_secondary() (smpboot.c) +> +>> ->cpu_init(); +> +>> ->smp_callin(); +> +>> ->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP +> +>> comes here, the BSP will not prints the error message. +> +>> +> +>> From above call process, we can be sure that, the AP has been stuck +> +>> between trampoline_data and the cpumask_set_cpu() in +> +>> smp_callin(), we look through these codes path carefully, and only found a +> +>> 'hlt' instruct that could block the process. +> +>> It is located in trampoline_data(): +> +>> +> +>> ENTRY(trampoline_data) +> +>> ... +> +>> +> +>> call verify_cpu # Verify the cpu supports long mode +> +>> testl %eax, %eax # Check for return code +> +>> jnz no_longmode +> +>> +> +>> ... +> +>> +> +>> no_longmode: +> +>> hlt +> +>> jmp no_longmode +> +>> +> +>> For the process verify_cpu(), +> +>> we can only find the 'cpuid' sensitive instruct that could lead VM exit +> +>> from No-root mode. +> +>> This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading +> +>> to the fail in verify_cpu. +> +>> +> +>> From the message in VM, we know vcpu1 and vcpu7 is something wrong. +> +>> [ 5.060042] CPU1: Stuck ?? +> +>> [ 10.170815] CPU7: Stuck ?? +> +>> [ 10.171648] Brought up 6 CPUs +> +>> +> +>> Besides, the follow is the cpus message got from host. +> +>> 80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh +> +>> qemu-monitor-command instance-0000000 +> +>> * CPU #0: pc=0x00007f64160c683d thread_id=68570 +> +>> CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573 +> +>> CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575 +> +>> CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576 +> +>> CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577 +> +>> CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578 +> +>> CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583 +> +>> CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584 +> +>> +> +>> Oh, i also forgot to mention in the above message that, we have bond each +> +>> vCPU to different physical CPU in +> +>> host. +> +>> +> +>> Thanks, +> +>> zhanghailiang +> +>> +> +>> +> +>> +> +>> +> +>> -- +> +>> To unsubscribe from this list: send the line "unsubscribe kvm" in +> +>> the body of a message to address@hidden +> +>> More majordomo info at +http://vger.kernel.org/majordomo-info.html +> +> +> +> +> +> . +> +> +> +> +> + +On 2015/7/7 20:21, Igor Mammedov wrote: +On Tue, 7 Jul 2015 19:43:35 +0800 +zhanghailiang <address@hidden> wrote: +On 2015/7/7 19:23, Igor Mammedov wrote: +On Mon, 6 Jul 2015 17:59:10 +0800 +zhanghailiang <address@hidden> wrote: +On 2015/7/6 16:45, Paolo Bonzini wrote: +On 06/07/2015 09:54, zhanghailiang wrote: +From host, we found that QEMU vcpu1 thread and vcpu7 thread were not +consuming any cpu (Should be in idle state), +All of VCPUs' stacks in host is like bellow: + +[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm] +[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm] +[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm] +[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm] +[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0 +[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0 +[<ffffffff81468092>] system_call_fastpath+0x16/0x1b +[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7 +[<ffffffffffffffff>] 0xffffffffffffffff + +We looked into the kernel codes that could leading to the above 'Stuck' +warning, +in current upstream there isn't any printk(...Stuck...) left since that code +path +has been reworked. +I've often seen this on over-committed host during guest CPUs up/down torture +test. +Could you update guest kernel to upstream and see if issue reproduces? +Hmm, Unfortunately, it is very hard to reproduce, and we are still trying to +reproduce it. + +For your test case, is it a kernel bug? +Or is there any related patch could solve your test problem been merged into +upstream ? +I don't remember all prerequisite patches but you should be able to find +http://marc.info/?l=linux-kernel&m=140326703108009&w=2 +"x86/smpboot: Initialize secondary CPU only if master CPU will wait for it" +and then look for dependencies. +Er, we have investigated this patch, and it is not related to our problem, :) + +Thanks. +Thanks, +zhanghailiang +and found that the only possible is the emulation of 'cpuid' instruct in +kvm/qemu has something wrong. +But since we canât reproduce this problem, we are not quite sure. +Is there any possible that the cupid emulation in kvm/qemu has some bug ? +Can you explain the relationship to the cpuid emulation? What do the +traces say about vcpus 1 and 7? +OK, we searched the VM's kernel codes with the 'Stuck' message, and it is +located in +do_boot_cpu(). It's in BSP context, the call process is: +BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> do_boot_cpu() +-> wakeup_secondary_via_INIT() to trigger APs. +It will wait 5s for APs to startup, if some AP not startup normally, it will +print 'CPU%d Stuck' or 'CPU%d: Not responding'. + +If it prints 'Stuck', it means the AP has received the SIPI interrupt and +begins to execute the code +'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places before +smp_callin()(smpboot.c). +The follow is the starup process of BSP and AP. +BSP: +start_kernel() + ->smp_init() + ->smp_boot_cpus() + ->do_boot_cpu() + ->start_ip = trampoline_address(); //set the address that AP will +go to execute + ->wakeup_secondary_cpu_via_init(); // kick the secondary CPU + ->for (timeout = 0; timeout < 50000; timeout++) + if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// check if +AP startup or not + +APs: +ENTRY(trampoline_data) (trampoline_64.S) + ->ENTRY(secondary_startup_64) (head_64.S) + ->start_secondary() (smpboot.c) + ->cpu_init(); + ->smp_callin(); + ->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP +comes here, the BSP will not prints the error message. + + From above call process, we can be sure that, the AP has been stuck between +trampoline_data and the cpumask_set_cpu() in +smp_callin(), we look through these codes path carefully, and only found a +'hlt' instruct that could block the process. +It is located in trampoline_data(): + +ENTRY(trampoline_data) + ... + + call verify_cpu # Verify the cpu supports long mode + testl %eax, %eax # Check for return code + jnz no_longmode + + ... + +no_longmode: + hlt + jmp no_longmode + +For the process verify_cpu(), +we can only find the 'cpuid' sensitive instruct that could lead VM exit from +No-root mode. +This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading to +the fail in verify_cpu. + + From the message in VM, we know vcpu1 and vcpu7 is something wrong. +[ 5.060042] CPU1: Stuck ?? +[ 10.170815] CPU7: Stuck ?? +[ 10.171648] Brought up 6 CPUs + +Besides, the follow is the cpus message got from host. +80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh qemu-monitor-command +instance-0000000 +* CPU #0: pc=0x00007f64160c683d thread_id=68570 + CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573 + CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575 + CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576 + CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577 + CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578 + CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583 + CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584 + +Oh, i also forgot to mention in the above message that, we have bond each vCPU +to different physical CPU in +host. + +Thanks, +zhanghailiang + + + + +-- +To unsubscribe from this list: send the line "unsubscribe kvm" in +the body of a message to address@hidden +More majordomo info at +http://vger.kernel.org/majordomo-info.html +. +. + diff --git a/results/classifier/118/unknown/2607 b/results/classifier/118/unknown/2607 new file mode 100644 index 00000000..c7966970 --- /dev/null +++ b/results/classifier/118/unknown/2607 @@ -0,0 +1,97 @@ +mistranslation: 0.889 +user-level: 0.866 +peripherals: 0.862 +TCG: 0.859 +register: 0.849 +hypervisor: 0.848 +permissions: 0.845 +ppc: 0.834 +files: 0.826 +risc-v: 0.825 +KVM: 0.822 +i386: 0.817 +VMM: 0.815 +device: 0.815 +vnc: 0.810 +network: 0.809 +virtual: 0.809 +performance: 0.807 +debug: 0.807 +graphic: 0.803 +socket: 0.800 +x86: 0.800 +architecture: 0.793 +semantic: 0.792 +PID: 0.790 +boot: 0.786 +assembly: 0.785 +arm: 0.784 +kernel: 0.777 + +msys2 build failed +Description of problem: + +Steps to reproduce: +1. Install MSYS2 and QEMU build dependencies +2. Update (pacman -Syu) +3. Build: +``` +./configure --enable-sdl --enable-fdt=system --disable-docs --target-list=arm-softmmu,aarch64-softmmu --enable-avx2 +make -j16 +``` +Additional information: +See: https://github.com/msys2/MINGW-packages/issues/22104#issuecomment-2393727818 + +output: +``` +FAILED: libcommon.a.p/net_tap-win32.c.obj +"cc" "-m64" "-Ilibcommon.a.p" "-ID:/a/_temp/msys64/mingw64/include/capstone" "-ID:/a/_temp/msys64/mingw64/include/p11-kit-1" "-ID:/a/_temp/msys64/mingw64/include/pixman-1" "-ID:/a/_temp/msys64/mingw64/include/libpng16" "-ID:/a/_temp/msys64/mingw64/include/spice-server" "-ID:/a/_temp/msys64/mingw64/include/spice-1" "-ID:/a/_temp/msys64/mingw64/include/cacard" "-ID:/a/_temp/msys64/mingw64/include/nss3" "-ID:/a/_temp/msys64/mingw64/include/nspr" "-ID:/a/_temp/msys64/mingw64/include/glib-2.0" "-ID:/a/_temp/msys64/mingw64/lib/glib-2.0/include" "-ID:/a/_temp/msys64/mingw64/include/libusb-1.0" "-ID:/a/_temp/msys64/mingw64/include/SDL2" "-ID:/a/_temp/msys64/mingw64/include/slirp" "-ID:/a/_temp/msys64/mingw64/include/ncursesw" "-ID:/a/_temp/msys64/mingw64/include/gtk-3.0" "-ID:/a/_temp/msys64/mingw64/include/pango-1.0" "-ID:/a/_temp/msys64/mingw64/include/harfbuzz" "-ID:/a/_temp/msys64/mingw64/include/cairo" "-ID:/a/_temp/msys64/mingw64/include/freetype2" "-ID:/a/_temp/msys64/mingw64/include/gdk-pixbuf-2.0" "-ID:/a/_temp/msys64/mingw64/include/webp" "-ID:/a/_temp/msys64/mingw64/include/atk-1.0" "-ID:/a/_temp/msys64/mingw64/include/fribidi" "-ID:/a/_temp/msys64/mingw64/include/rav1e" "-ID:/a/_temp/msys64/mingw64/include/svt-av1" "-fdiagnostics-color=auto" "-Wall" "-Winvalid-pch" "-Werror" "-std=gnu11" "-O2" "-g" "-fstack-protector-strong" "-Wempty-body" "-Wendif-labels" "-Wexpansion-to-defined" "-Wformat-security" "-Wformat-y2k" "-Wignored-qualifiers" "-Wimplicit-fallthrough=2" "-Winit-self" "-Wmissing-format-attribute" "-Wmissing-prototypes" "-Wnested-externs" "-Wold-style-declaration" "-Wold-style-definition" "-Wredundant-decls" "-Wshadow=local" "-Wstrict-prototypes" "-Wtype-limits" "-Wundef" "-Wvla" "-Wwrite-strings" "-Wno-missing-include-dirs" "-Wno-psabi" "-Wno-shift-negative-value" "-iquote" "." "-iquote" "D:/a/qemu/qemu" "-iquote" "D:/a/qemu/qemu/include" "-iquote" "D:/a/qemu/qemu/host/include/x86_64" "-iquote" "D:/a/qemu/qemu/host/include/generic" "-iquote" "D:/a/qemu/qemu/tcg/i386" "-msse2" "-mcx16" "-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-D_LARGEFILE_SOURCE" "-fno-strict-aliasing" "-fno-common" "-fwrapv" "-fno-pie" "-no-pie" "-ftrivial-auto-var-init=zero" "-fzero-call-used-regs=used-gpr" "-DHWY_SHARED_DEFINE" "-DAVIF_DLL" "-DEB_DLL" "-DLIBDEFLATE_DLL" "-DNCURSES_WIDECHAR" "-DNCURSES_WIDECHAR=1" "-Dmain=SDL_main" "-DSTRUCT_IOVEC_DEFINED" -MD -MQ libcommon.a.p/net_tap-win32.c.obj -MF "libcommon.a.p/net_tap-win32.c.obj.d" -o libcommon.a.p/net_tap-win32.c.obj "-c" ../net/tap-win32.c +../net/tap-win32.c: In function 'tap_win32_open': +../net/tap-win32.c:343:19: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 176 [-Werror=format-truncation=] + 343 | "%s\\%s\\Connection", + | ^~ + 344 | NETWORK_CONNECTIONS_KEY, enum_name); + | ~~~~~~~~~ +In function 'get_device_guid', + inlined from 'tap_win32_open' at ../net/tap-win32.c:616:10: +../net/tap-win32.c:341:9: note: 'snprintf' output between 92 and 347 bytes into a destination of size 256 + 341 | snprintf(connection_string, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + 342 | sizeof(connection_string), + | ~~~~~~~~~~~~~~~~~~~~~~~~~~ + 343 | "%s\\%s\\Connection", + | ~~~~~~~~~~~~~~~~~~~~~ + 344 | NETWORK_CONNECTIONS_KEY, enum_name); + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../net/tap-win32.c: In function 'tap_win32_open': +../net/tap-win32.c:242:58: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 178 [-Werror=format-truncation=] + 242 | snprintf (unit_string, sizeof(unit_string), "%s\\%s", + | ^~ + 243 | ADAPTER_KEY, enum_name); + | ~~~~~~~~~ +In function 'is_tap_win32_dev', + inlined from 'get_device_guid' at ../net/tap-win32.c:368:21, + inlined from 'tap_win32_open' at ../net/tap-win32.c:616:10: +../net/tap-win32.c:242:9: note: 'snprintf' output between 79 and 334 bytes into a destination of size 256 + 242 | snprintf (unit_string, sizeof(unit_string), "%s\\%s", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 243 | ADAPTER_KEY, enum_name); + | ~~~~~~~~~~~~~~~~~~~~~~~ +../net/tap-win32.c: In function 'tap_win32_open': +../net/tap-win32.c:620:52: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 245 [-Werror=format-truncation=] + 620 | snprintf (device_path, sizeof(device_path), "%s%s%s", + | ^~ + 621 | USERMODEDEVICEDIR, + 622 | device_guid, + | ~~~~~~~~~~~ +../net/tap-win32.c:620:5: note: 'snprintf' output between 16 and 271 bytes into a destination of size 256 + 620 | snprintf (device_path, sizeof(device_path), "%s%s%s", + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 621 | USERMODEDEVICEDIR, + | ~~~~~~~~~~~~~~~~~~ + 622 | device_guid, + | ~~~~~~~~~~~~ + 623 | TAPSUFFIX); + | ~~~~~~~~~~ +cc1.exe: all warnings being treated as errors +``` diff --git a/results/classifier/118/unknown/2631 b/results/classifier/118/unknown/2631 new file mode 100644 index 00000000..f8735d80 --- /dev/null +++ b/results/classifier/118/unknown/2631 @@ -0,0 +1,111 @@ +risc-v: 0.929 +i386: 0.904 +ppc: 0.903 +user-level: 0.891 +KVM: 0.889 +PID: 0.883 +device: 0.881 +arm: 0.879 +hypervisor: 0.877 +register: 0.873 +debug: 0.865 +architecture: 0.864 +graphic: 0.863 +vnc: 0.861 +permissions: 0.853 +assembly: 0.852 +virtual: 0.852 +TCG: 0.846 +kernel: 0.844 +mistranslation: 0.843 +x86: 0.841 +performance: 0.841 +VMM: 0.827 +semantic: 0.827 +peripherals: 0.819 +boot: 0.816 +socket: 0.776 +network: 0.774 +files: 0.748 + +qemu-system-i386: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed. +Description of problem: +While fuzzing, we observed a assertion failures in several virtio devices supporting msi-x functionality. +Steps to reproduce: +Here is qtest reproducer: +```bash +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +``` + +and execution log: +``` +cat << EOF | qemu-system-i386 -display none -machine accel=qtest, -m 512M -machine pc -nodefaults \ +-device virtio-mouse-pci,vectors=19923041 -qtest stdio +outl 0xcf8 0x80001020 +outl 0xcfc 0xe0800000 +outl 0xcf8 0x80001004 +outw 0xcfc 0x02 +write 0xe0800010 0x4 0x6100 +EOF +[I 0.000001] OPENED +[R +0.067760] outl 0xcf8 0x80001020 +[S +0.067795] OK +OK +[R +0.067821] outl 0xcfc 0xe0800000 +[S +0.067959] OK +OK +[R +0.067993] outl 0xcf8 0x80001004 +[S +0.068005] OK +OK +[R +0.068020] outw 0xcfc 0x02 +[S +0.068520] OK +OK +[R +0.068554] write 0xe0800010 0x4 0x6100 +qemu-system-i386: ../hw/pci/msix.c:569: void msix_vector_use(PCIDevice *, unsigned int): Assertion `vector < dev->msix_entries_nr' failed. +Aborted +``` + +If you need more information, let me know so I can discuss more about this issue. +Additional information: +```c +int msix_init(PCIDevice *dev, unsigned short nentries, + MemoryRegion *table_bar, uint8_t table_bar_nr, + unsigned table_offset, MemoryRegion *pba_bar, + uint8_t pba_bar_nr, unsigned pba_offset, uint8_t cap_pos, + Error **errp); +int msix_init_exclusive_bar(PCIDevice *dev, unsigned short nentries, + uint8_t bar_nr, Error **errp); +``` + +`msix_init` accepts `nentries` as `unsigned short` type. + +```c +static void virtio_pci_device_plugged(DeviceState *d, Error **errp): + + ... + + if (proxy->nvectors) { + int err = msix_init_exclusive_bar(&proxy->pci_dev, proxy->nvectors, + proxy->msix_bar_idx, NULL); + if (err) { + /* Notice when a system that supports MSIx can't initialize it */ + if (err != -ENOTSUP) { + warn_report("unable to init msix vectors to %" PRIu32, + proxy->nvectors); + } + proxy->nvectors = 0; + } + } +``` + +When virtio-pci device is initialized, `proxy->nvectors` (`uint32_t` here) is casted into `unsigned short`. +This causes inconsistency between `msix_entries_nr` and `nvectors` and triggers the above crash. + +While this is due to setting invalid value to `nvectors`, we need proper handling of the wrong value in the configuration. diff --git a/results/classifier/118/unknown/2791 b/results/classifier/118/unknown/2791 new file mode 100644 index 00000000..e92eb039 --- /dev/null +++ b/results/classifier/118/unknown/2791 @@ -0,0 +1,93 @@ +user-level: 0.904 +debug: 0.904 +mistranslation: 0.891 +virtual: 0.890 +boot: 0.886 +register: 0.882 +device: 0.877 +semantic: 0.876 +peripherals: 0.871 +assembly: 0.866 +arm: 0.862 +x86: 0.859 +graphic: 0.857 +architecture: 0.853 +performance: 0.853 +permissions: 0.846 +kernel: 0.846 +PID: 0.832 +KVM: 0.830 +risc-v: 0.830 +VMM: 0.817 +vnc: 0.799 +i386: 0.794 +TCG: 0.794 +hypervisor: 0.790 +ppc: 0.789 +socket: 0.773 +files: 0.750 +network: 0.708 + +"Missing character write event in the replay log" when trying rr=replay with snapshot +Description of problem: +Probably best to just illustrate with commands. Happy path: + +```sh +rm replay.bin snapshots.qcow2; qemu-img create -f qcow2 snapshots.qcow2 256M + +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=record,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" + +# It runs, guest kernel crashes when realising it has no rootfs, all good +du -sh snapshots.qcow2 # 976K + +# Repeat same command just switched to rr=replay +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=replay,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" +# Much slower, but same result. All good +``` + +But, I want to take a snapshot later in boot. + +```sh +rm replay.bin snapshots.qcow2; qemu-img create -f qcow2 snapshots.qcow2 256M + +# This time, running with debug. Also have to switch to -monitor stdio because of +# https://gitlab.com/qemu-project/qemu/-/issues/2790 +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -monitor stdio \ + -icount shift=auto,rr=record,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" \ + -s -S + +# In another terminal, attach a debugger, set a breakpoint, continue to the breakpoint +gdb -ex "target remote localhost:1234" .kunit/vmlinux +(gdb) hb start_kernel +(gdb) continue + +# When the breakpoint is hit, back in the first terminal: +(qemu) savevm test +(qemu) quit + +du -sh snapshots.qcow2 # 21M + +# Now try to replay again +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=replay,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" +``` + +Result: + +``` +qemu-system-x86_64: Missing character write event in the replay log (insn total 1598039/586 left, event 886 is EVENT_INSTRUCTION) +fish: Job 1, '~/src/qemu/build/qemu-system-x8…' terminated by signal -icount shift=auto,rr=repla… ( -drive file=snapshots.qcow2…) +fish: Job -kernel ./.kunit/arch/x86/b…, 'SIGABRT' terminated by signal Abort () +``` + +Exit code is 134. diff --git a/results/classifier/118/unknown/2793 b/results/classifier/118/unknown/2793 new file mode 100644 index 00000000..622f4763 --- /dev/null +++ b/results/classifier/118/unknown/2793 @@ -0,0 +1,272 @@ +user-level: 0.911 +permissions: 0.890 +debug: 0.888 +TCG: 0.877 +risc-v: 0.877 +peripherals: 0.867 +graphic: 0.867 +virtual: 0.860 +performance: 0.859 +ppc: 0.852 +semantic: 0.851 +register: 0.851 +hypervisor: 0.849 +KVM: 0.849 +VMM: 0.848 +assembly: 0.848 +mistranslation: 0.847 +files: 0.846 +network: 0.841 +vnc: 0.841 +socket: 0.840 +architecture: 0.839 +device: 0.837 +arm: 0.832 +x86: 0.816 +PID: 0.815 +boot: 0.810 +kernel: 0.772 +i386: 0.768 + +Upgrading from qemu-kvm-* (17:9.1.0-7.el9) to (17:9.1.0-9.el9) causes VM to crash within cockpit-machines (v326-1.el9) with qemu-kvm: ../qapi/qobject-output-visitor.c:95: void qobject_output_add_obj(QObjectOutputVisitor *, const char *, QObject *): Assert +Description of problem: +** From the /var/log/libvirt/qemu/WinDesktop03-log ** + +2025-01-21 21:50:57.464+0000: Starting external device: TPM Emulator +/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/1-WinDesktop-03-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/fb44aa6f-8127-4df7-afc3-2ba54b7b7790/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/WinDesktop-03-swtpm.log --terminate --tpm2 +2025-01-21 21:50:57.501+0000: starting up libvirt version: 10.10.0, package: 3.el9 (builder@centos.org, 2024-12-20-13:49:58, ), qemu version: 9.1.0qemu-kvm-9.1.0-7.el9, kernel: 6.12.9, hostname: amd-strat-3 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03/.config \ +/usr/libexec/qemu-kvm \ +-name guest=WinDesktop-03,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-1-WinDesktop-03/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/WinDesktop-03_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \ +-machine pc-q35-rhel9.6.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,hpet=off,acpi=on \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff,hv-vpindex=on,hv-runtime=on,hv-synic=on,hv-stimer=on,hv-frequencies=on,hv-tlbflush=on,hv-ipi=on,hv-avic=on \ +-global driver=cfi.pflash01,property=secure,value=on \ +-m size=8388608k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,dies=1,clusters=1,cores=8,threads=1 \ +-uuid fb44aa6f-8127-4df7-afc3-2ba54b7b7790 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=23,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/stratistor/clustermounts/machines/WinDesktop-03/WinDesktop-03.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \ +-netdev '{"type":"tap","fd":"25","vhost":true,"vhostfd":"27","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d4:af:c9","bus":"pci.1","addr":"0x0"}' \ +-chardev pty,id=charserial0 \ +-device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \ +-chardev socket,id=charchannel0,fd=22,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/1-WinDesktop-03-swtpm.sock \ +-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \ +-device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \ +-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc 0.0.0.0:0,audiodev=audio1 \ +-device '{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}' \ +-global ICH9-LPC.noreboot=off \ +-watchdog-action reset \ +-incoming defer \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.3","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2025-01-21 21:50:57.502+0000: Domain id=1 is tainted: high-privileges +2025-01-21 21:50:57.502+0000: Domain id=1 is tainted: host-cpu +char device redirected to /dev/pts/0 (label charserial0) +2025-01-21 21:51:07.797+0000: Domain id=1 is tainted: custom-ga-command +2025-01-25T20:54:12.923119Z qemu-kvm: terminating on signal 15 from pid 279229 (/usr/sbin/virtqemud) +2025-01-25 20:54:13.215+0000: shutting down, reason=shutdown +2025-01-25 20:54:18.392+0000: Starting external device: TPM Emulator +/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/2-WinDesktop-03-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/fb44aa6f-8127-4df7-afc3-2ba54b7b7790/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/WinDesktop-03-swtpm.log --terminate --tpm2 +2025-01-25 20:54:18.414+0000: starting up libvirt version: 10.10.0, package: 3.el9 (builder@centos.org, 2024-12-20-13:49:58, ), qemu version: 9.1.0qemu-kvm-9.1.0-9.el9, kernel: 6.12.9, hostname: amd-strat-3 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03/.config \ +/usr/libexec/qemu-kvm \ +-name guest=WinDesktop-03,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-2-WinDesktop-03/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/WinDesktop-03_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \ +-machine pc-q35-rhel9.6.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,hpet=off,acpi=on \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff,hv-vpindex=on,hv-runtime=on,hv-synic=on,hv-stimer=on,hv-frequencies=on,hv-tlbflush=on,hv-ipi=on,hv-avic=on \ +-global driver=cfi.pflash01,property=secure,value=on \ +-m size=8388608k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,dies=1,clusters=1,cores=8,threads=1 \ +-uuid fb44aa6f-8127-4df7-afc3-2ba54b7b7790 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=25,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/stratistor/clustermounts/machines/WinDesktop-03/WinDesktop-03.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \ +-netdev '{"type":"tap","fd":"27","vhost":true,"vhostfd":"34","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d4:af:c9","bus":"pci.1","addr":"0x0"}' \ +-chardev pty,id=charserial0 \ +-device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \ +-chardev socket,id=charchannel0,fd=23,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/2-WinDesktop-03-swtpm.sock \ +-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \ +-device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \ +-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc 0.0.0.0:0,audiodev=audio1 \ +-device '{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}' \ +-global ICH9-LPC.noreboot=off \ +-watchdog-action reset \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.3","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2025-01-25 20:54:18.414+0000: Domain id=2 is tainted: high-privileges +char device redirected to /dev/pts/0 (label charserial0) +qemu-kvm: ../qapi/qobject-output-visitor.c:95: void qobject_output_add_obj(QObjectOutputVisitor *, const char *, QObject *): Assertion `name' failed. +2025-01-25 20:54:19.395+0000: shutting down, reason=crashed +2025-01-25 20:54:25.221+0000: Starting external device: TPM Emulator +/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/3-WinDesktop-03-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/fb44aa6f-8127-4df7-afc3-2ba54b7b7790/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/WinDesktop-03-swtpm.log --terminate --tpm2 +2025-01-25 20:54:25.242+0000: starting up libvirt version: 10.10.0, package: 3.el9 (builder@centos.org, 2024-12-20-13:49:58, ), qemu version: 9.1.0qemu-kvm-9.1.0-9.el9, kernel: 6.12.9, hostname: amd-strat-3 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03/.config \ +/usr/libexec/qemu-kvm \ +-name guest=WinDesktop-03,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-3-WinDesktop-03/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/WinDesktop-03_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \ +-machine pc-q35-rhel9.6.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,hpet=off,acpi=on \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff,hv-vpindex=on,hv-runtime=on,hv-synic=on,hv-stimer=on,hv-frequencies=on,hv-tlbflush=on,hv-ipi=on,hv-avic=on \ +-global driver=cfi.pflash01,property=secure,value=on \ +-m size=8388608k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,dies=1,clusters=1,cores=8,threads=1 \ +-uuid fb44aa6f-8127-4df7-afc3-2ba54b7b7790 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=25,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/stratistor/clustermounts/machines/WinDesktop-03/WinDesktop-03.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \ +-netdev '{"type":"tap","fd":"27","vhost":true,"vhostfd":"34","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d4:af:c9","bus":"pci.1","addr":"0x0"}' \ +-chardev pty,id=charserial0 \ +-device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \ +-chardev socket,id=charchannel0,fd=23,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/3-WinDesktop-03-swtpm.sock \ +-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \ +-device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \ +-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc 0.0.0.0:0,audiodev=audio1 \ +-device '{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}' \ +-global ICH9-LPC.noreboot=off \ +-watchdog-action reset \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.3","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2025-01-25 20:54:25.242+0000: Domain id=3 is tainted: high-privileges +char device redirected to /dev/pts/0 (label charserial0) +**qemu-kvm: ../qapi/qobject-output-visitor.c:95: void qobject_output_add_obj(QObjectOutputVisitor *, const char *, QObject *): Assertion `name' failed. +2025-01-25 20:54:29.967+0000: shutting down, reason=crashed** +Steps to reproduce: +1. Could not produce crash with qemu version 9.1.0-7, upgraded to 9.1.0-9. +2. Started VM using cockpit web interface +3. Crashes within 5 seconds of starting +4. Opening a ticket with cockpit-machines tracker as well as this only happens in cockpit-machines. I am able to open console using virt-manager without crashing, it's only with the cockpit-machines web interface on the VM summary page for the specific VM that appears to cause this. +Additional information: + diff --git a/results/classifier/118/unknown/2917 b/results/classifier/118/unknown/2917 new file mode 100644 index 00000000..fe86a27a --- /dev/null +++ b/results/classifier/118/unknown/2917 @@ -0,0 +1,52 @@ +graphic: 0.860 +TCG: 0.853 +register: 0.851 +performance: 0.844 +permissions: 0.843 +debug: 0.838 +user-level: 0.837 +virtual: 0.831 +files: 0.830 +device: 0.830 +PID: 0.824 +assembly: 0.820 +architecture: 0.818 +kernel: 0.813 +socket: 0.812 +semantic: 0.810 +risc-v: 0.807 +network: 0.803 +arm: 0.802 +VMM: 0.802 +KVM: 0.798 +i386: 0.790 +peripherals: 0.787 +ppc: 0.780 +boot: 0.777 +hypervisor: 0.771 +x86: 0.771 +vnc: 0.769 +mistranslation: 0.756 + +build failure because of warnings when -O3 is used +Description of problem: +qemu build fails when -O3 is enabled and the build is done either from a git cloned qemu or with -Werror enabled (qemu build enables -Werror automatically when it detects the .git folder) +Steps to reproduce: +1. git clone qemu && install appropriate dependencies for qemu build +2. mkdir build +3. ../configure --extra-cflags="-O3" +4. make -j$(nbproc) + +``` +cc -m64 -Ilibcommon.a.p -I../common-user/host/x86_64 -I../linux-user/include/host/x86_64 -I../linux-user/include -Isubprojects/libvduse -I../subprojects/libvduse -I/usr/include/p11-kit-1 -I/usr/include/pixman-1 -I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libusb-1.0 -I/usr/include/SDL2 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sysprof-6 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/slirp -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu -I/usr/include/webp -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/vte-2.91 -I/usr/include/virgl -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/PCSC -I/usr/include/pipewire-0.3 -I/usr/include/spa-0.2 -I/usr/include/fuse3 -I/usr/include/uuid -fdiagnostics-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Wimplicit-fallthrough=2 -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-declaration -Wold-style-definition -Wredundant-decls -Wshadow=local -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -isystem /home/ubuntu/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/ubuntu/qemu -iquote /home/ubuntu/qemu/include -iquote /home/ubuntu/qemu/host/include/x86_64 -iquote /home/ubuntu/qemu/host/include/generic -iquote /home/ubuntu/qemu/tcg/i386 -pthread -mcx16 -msse2 -D_GNU_SOURCE -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -ftrivial-auto-var-init=zero -fzero-call-used-regs=used-gpr -O3 -fPIE -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64 -D__USE_LARGEFILE64 -DUSE_POSIX_ACLS=1 -isystem /usr/include/mit-krb5 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -D_REENTRANT -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.a.p/hw_ssi_xilinx_spips.c.o -MF libcommon.a.p/hw_ssi_xilinx_spips.c.o.d -o libcommon.a.p/hw_ssi_xilinx_spips.c.o -c ../hw/ssi/xilinx_spips.c +../hw/ssi/xilinx_spips.c: In function ‘xilinx_spips_flush_txfifo’: +../hw/ssi/xilinx_spips.c:624:30: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] + 624 | tx_rx[i] = fifo8_pop(&s->tx_fifo); + | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~ +../hw/ssi/xilinx_spips.c:613:17: note: at offset 2 into destination object ‘tx_rx’ of size 2 + 613 | uint8_t tx_rx[MAX_NUM_BUSSES] = { 0 }; + | ^~~~~ +cc1: all warnings being treated as errors +``` +Additional information: +I fixed this warning locally on my build however it is only a start of several build warnings that happen down the road (\~6 warnings in total) diff --git a/results/classifier/118/unknown/2942 b/results/classifier/118/unknown/2942 new file mode 100644 index 00000000..59d280ce --- /dev/null +++ b/results/classifier/118/unknown/2942 @@ -0,0 +1,95 @@ +user-level: 0.879 +mistranslation: 0.875 +arm: 0.870 +architecture: 0.863 +ppc: 0.862 +assembly: 0.854 +permissions: 0.852 +hypervisor: 0.852 +debug: 0.846 +graphic: 0.844 +virtual: 0.838 +device: 0.838 +kernel: 0.838 +register: 0.835 +KVM: 0.829 +semantic: 0.825 +TCG: 0.824 +PID: 0.823 +files: 0.818 +peripherals: 0.817 +performance: 0.816 +boot: 0.811 +socket: 0.809 +network: 0.792 +vnc: 0.788 +risc-v: 0.767 +i386: 0.765 +x86: 0.761 +VMM: 0.760 + +arm: TCG debug assertion failure when handling an ISB or SB insn inside an IT block +Description of problem: +ARM thumb `IT` instruction triggers TCG debug asserts. + +``` +$ ./qemu-system-arm --version +QEMU emulator version 10.0.0 (v10.0.0) + +$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-it-bug.hex -d in_asm,exec +[...] +Trace 0: 0x72a584000800 [00800400/0000000000000164/00000110/ff020000] +---------------- +IN: +0x00000108: f000 f80a bl #0x120 + +Trace 0: 0x72a584000940 [00800400/0000000000000108/00000110/ff020000] +qemu-system-arm: ../tcg/tcg-op.c:3343: void tcg_gen_goto_tb(unsigned int): Assertion `(tcg_ctx->goto_tb_issue_mask & (1 << idx)) == 0' failed. +``` + +Expected behavior: +``` +$ qemu-system-arm -M stm32vldiscovery -device loader,file=raw-hardfault.hex -d in_asm,exec,int +[...] +Trace 0: 0x7df6dc000800 [00800400/0000000000000164/00000110/ff020000] +---------------- +IN: +0x00000108: f000 f80a bl #0x120 + +Trace 0: 0x7df6dc000940 [00800400/0000000000000108/00000110/ff020000] +---------------- +IN: +0x00000120: 2302 movs r3, #2 +0x00000122: bf00 nop +0x00000124: f04f 25e0 mov.w r5, #-0x1fff2000 +0x00000128: f8d5 1d10 ldr.w r1, [r5, #0xd10] +0x0000012c: f041 0014 orr r0, r1, #0x14 +0x00000130: f8c5 0d10 str.w r0, [r5, #0xd10] +0x00000134: f8d5 0200 ldr.w r0, [r5, #0x200] +0x00000138: f8d5 6100 ldr.w r6, [r5, #0x100] +0x0000013c: 4206 tst r6, r0 +0x0000013e: bf02 ittt eq +0x00000140: f3bf 8f4f dsbeq sy +0x00000144: bf20 wfeeq + +Linking TBs 0x7df6dc000940 index 0 -> 0x7df6dc000a80 +Trace 0: 0x7df6dc000a80 [00800400/0000000000000120/00000110/ff020000] +[...] +Trace 0: 0x7df6dc001fc0 [00800400/0000000000000170/00000110/ff020000] +Taking exception 3 [Prefetch Abort] on CPU 0 +...at fault address 0xdeadbeee +...with CFSR.IACCVIOL +...BusFault with BFSR.STKERR +...taking pending nonsecure exception 3 +...loading from element 3 of non-secure vector table at 0xc +...loaded new PC 0x111 +---------------- +IN: +0x00000110: e7fe b #0x110 +``` +Steps to reproduce: +1. Build QEMU with `CONFIG_DEBUG_TCG` enabled, e.g. with `./configure --enable-debug`. +1. Run Cortex-M firmware with `IT` instruction. (minimal example attached) +Additional information: +- Minimal Reproducer: [raw-it-bug.hex](/uploads/3ae30ab78f49bbc933e48c51f6bf2a2b/raw-it-bug.hex) +- Reproduced on `main`, `v10.0.0` and `v9.1.0`. diff --git a/results/classifier/118/unknown/2967 b/results/classifier/118/unknown/2967 new file mode 100644 index 00000000..a817c80b --- /dev/null +++ b/results/classifier/118/unknown/2967 @@ -0,0 +1,244 @@ +peripherals: 0.894 +risc-v: 0.888 +permissions: 0.876 +graphic: 0.874 +virtual: 0.870 +hypervisor: 0.861 +debug: 0.854 +KVM: 0.851 +ppc: 0.845 +register: 0.841 +performance: 0.838 +user-level: 0.837 +architecture: 0.832 +vnc: 0.831 +TCG: 0.828 +mistranslation: 0.825 +x86: 0.823 +VMM: 0.823 +assembly: 0.805 +arm: 0.802 +PID: 0.797 +semantic: 0.796 +boot: 0.795 +socket: 0.790 +i386: 0.780 +device: 0.769 +files: 0.766 +kernel: 0.748 +network: 0.739 + +Heavy graphic glitches when using Virtio with 3D acceleration +Description of problem: +Virtio with 3D acceleration enabled under "Video" and the corresponding OpenGL activated under "Display" with Spice leads to heavy artifacts in the graphical console. + +This error has been observed on Arch Linux with Intel Meteor Lake CPU (Intel Arc Graphics iGPU) as well as on OpenSuse Tumbleweed with Intel Kaby Lake CPU (Intel HD 630 iGPU) + + +(virtio without acceleration enabled) + + +(Same VM, same settings, but with 3D acceleration and OpenGL enabled) + + +(Same issue on a fresh install of OpenSuse Tumbleweed on a system that is in no way linked to the first one) +Steps to reproduce: +1. Enable Virtio Graphics with 3D acceleration under "Video". +2. Activate the corresponding OpenGL under "Spice". +3. Start the VM and open the graphical console. +Additional information: +XML config: + +``` +<domain type='kvm'> + <name>debian12</name> + <uuid>1d39d86a-b341-47bb-9847-4c78da9df863</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://debian.org/debian/12"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>4</vcpu> + <os firmware='efi'> + <type arch='x86_64' machine='pc-q35-9.1'>hvm</type> + <firmware> + <feature enabled='no' name='enrolled-keys'/> + <feature enabled='no' name='secure-boot'/> + </firmware> + <loader readonly='yes' type='pflash'>/usr/share/edk2/x64/OVMF_CODE.4m.fd</loader> + <nvram template='/usr/share/edk2/x64/OVMF_VARS.4m.fd'>/var/lib/libvirt/qemu/nvram/debian12_VARS.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'/> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' discard='unmap'/> + <source file='/var/lib/libvirt/images/debian12.qcow2'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='sda' bus='sata'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='qemu-xhci' ports='15'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x11'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0x12'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> + </controller> + <controller type='pci' index='5' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='5' port='0x14'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> + </controller> + <controller type='pci' index='6' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='6' port='0x15'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> + </controller> + <controller type='pci' index='7' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='7' port='0x16'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> + </controller> + <controller type='pci' index='8' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='8' port='0x17'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x7'/> + </controller> + <controller type='pci' index='9' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='9' port='0x18'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='10' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='10' port='0x19'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x1'/> + </controller> + <controller type='pci' index='11' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='11' port='0x1a'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x2'/> + </controller> + <controller type='pci' index='12' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='12' port='0x1b'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x3'/> + </controller> + <controller type='pci' index='13' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='13' port='0x1c'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x4'/> + </controller> + <controller type='pci' index='14' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='14' port='0x1d'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x5'/> + </controller> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:d6:22:67'/> + <source network='default'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0'/> + <address type='virtio-serial' controller='0' bus='0' port='2'/> + </channel> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice'> + <listen type='none'/> + <image compression='off'/> + <gl enable='yes'/> + </graphics> + <sound model='ich9'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </sound> + <audio id='1' type='spice'/> + <video> + <model type='virtio' heads='1' primary='yes'> + <acceleration accel3d='yes'/> + </model> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <redirdev bus='usb' type='spicevmc'> + <address type='usb' bus='0' port='2'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <address type='usb' bus='0' port='3'/> + </redirdev> + <watchdog model='itco' action='reset'/> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> + </rng> + </devices> +</domain> +``` diff --git a/results/classifier/118/unknown/2975 b/results/classifier/118/unknown/2975 new file mode 100644 index 00000000..4cc92a74 --- /dev/null +++ b/results/classifier/118/unknown/2975 @@ -0,0 +1,98 @@ +risc-v: 0.909 +debug: 0.882 +device: 0.867 +arm: 0.866 +user-level: 0.855 +register: 0.853 +KVM: 0.853 +architecture: 0.851 +PID: 0.847 +TCG: 0.847 +permissions: 0.845 +mistranslation: 0.844 +files: 0.842 +assembly: 0.842 +graphic: 0.841 +virtual: 0.838 +peripherals: 0.835 +vnc: 0.832 +kernel: 0.832 +boot: 0.829 +ppc: 0.828 +socket: 0.827 +performance: 0.825 +x86: 0.824 +VMM: 0.821 +semantic: 0.817 +network: 0.793 +hypervisor: 0.773 +i386: 0.770 + +qemu-system-x86_64: VFIO_MAP_DMA failed: -22 IVSHMEM +Description of problem: +QEMU do not run with looking glass KVMFR and with host model cpu +It only works when I set cpu to `Snowridge,vmx=on,fma=on,avx=on,f16c=on,hypervisor=on...` (you can see in kvm.sh) +Steps to reproduce: +1. I have a script ( search for 'WITH VFIO') +Additional information: +UPD +Some additional debug info from GDB + +``` +=== vfio_listener_region_add === +Arguments: +listener = 0x55555a4dd2f0 +section = 0x7fffedb389c0 + +Section details: + section->offset_within_address_space: 0x382000000000 + Memory region: 0x555558120dd0 + Memory region name: shmmem-shmem0 + Memory region size: 0x10000000 + Memory region addr: 0x382000000000 +Error accessing section details: There is no member named offset. + +=== vfio_get_section_iova_range ENTRY === +Arguments: +bcontainer = 0x55555a4dd2c0 +section = 0x7fffedb389c0 +out_iova = 0x7fffedb388b0 +out_end = 0x7fffedb388b8 +out_llend = 0x7fffedb38900 + +Local variables at entry: +llend = 140737181354144 +iova = 140737181354432 + +Thread 4 "CPU 0/KVM" hit Breakpoint -96, 0x0000555555b8511a in vfio_listener_region_add (listener=0x55555a4dd2f0, + section=0x7fffedb389c0) at ../../../hw/vfio/listener.c:467 +467 if (!vfio_get_section_iova_range(bcontainer, section, &iova, &end, +(gdb) +Continuing. +2025-05-20T22:46:27.819893Z qemu-system-x86_64: vfio_container_dma_map(0x55555a4dd2c0, 0x382000000000, 0x10000000, 0x7fffcffff000) = -22 (Invalid argument) +qemu: hardware error: vfio: DMA mapping failed, unable to continue +CPU #0: +RAX=00000000e0000000 RBX=00000000e0608004 RCX=0000000000608004 RDX=0000000000000003 +RSI=0000000000000003 RDI=0000000000000000 RBP=000000007ef6b640 RSP=000000007ef6b5f0 +R8 =0000000000000000 R9 =000000007ef6b70f R10=0000000000000000 R11=0000000000000004 +R12=000000007ef6b800 R13=0000000000000003 R14=0000000000000000 R15=000000007ef6b7fe +RIP=000000007e1fe2eb RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 + +``` + +Tested with latest QEMU 2af4a82ab2cce3412ffc92cd4c96bd870e33bc8e same error +``` +sudo dnf builddep qemu +../../../configure --enable-debug +``` + +[ERROR-QEMU-GIT-2af4a82ab2cce3412ffc92cd4c96bd870e33bc8e.txt](/uploads/060b26f091f0391f0491ea91dbe78f6d/ERROR-QEMU-GIT-2af4a82ab2cce3412ffc92cd4c96bd870e33bc8e.txt) + +[ERROR-trace-iova-values.txt](/uploads/22cacf4a5cb2c91ff6375c792a25dde1/ERROR-trace-iova-values.txt) + +[WORKINg-trace-iova-values.txt](/uploads/d4d53c2e743cf5f2d5bf810d61b9f1e6/WORKINg-trace-iova-values.txt) + + +[kvm.log.txt](/uploads/ac31eebf6e63aa6abe2498d1a4064bef/kvm.log.txt) + +[kvm.sh](/uploads/7f656f7cf0d623a240309ee61b024dc9/kvm.sh) diff --git a/results/classifier/118/unknown/2980 b/results/classifier/118/unknown/2980 new file mode 100644 index 00000000..37fa7ccd --- /dev/null +++ b/results/classifier/118/unknown/2980 @@ -0,0 +1,294 @@ +user-level: 0.870 +risc-v: 0.851 +register: 0.840 +permissions: 0.839 +graphic: 0.821 +VMM: 0.819 +vnc: 0.818 +virtual: 0.818 +KVM: 0.816 +hypervisor: 0.816 +performance: 0.813 +ppc: 0.811 +device: 0.806 +semantic: 0.805 +architecture: 0.802 +arm: 0.797 +assembly: 0.794 +x86: 0.790 +debug: 0.786 +socket: 0.781 +PID: 0.774 +boot: 0.774 +kernel: 0.770 +TCG: 0.764 +mistranslation: 0.757 +peripherals: 0.756 +files: 0.747 +network: 0.732 +i386: 0.730 + +QEMU Crashes During Snapshot: bdrv_co_write_req_prepare Assertion child->perm & BLK_PERM_WRITE Failed +Description of problem: +After taking a external snapshot (w/ memory state) with libvirt, the QEMU process crashed with an assertion + +``` +qemu-system-x86_64: ../block/io.c:2052: bdrv_co_write_req_prepare: Assertion `child->perm & BLK_PERM_WRITE` failed. +``` +Steps to reproduce: +1. Start the qemu process +2. Take an external (w/ memory) snapshot by libvirt Python API + + ```python + domain.snapshotCreateXML(<xml_string>, + libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_ATOMIC | + libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT | + libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_LIVE) + ``` + +3. The qemu process crashed by hitting the assertion +Additional information: +Libvirt domain XML +```xml +<domain type='kvm'> + <name>1a3dabc5-c33b-4308-acc5-2245f3b64163</name> + <uuid>1a3dabc5-c33b-4308-acc5-2245f3b64163</uuid> + <metadata xmlns:qvs="http://www.qnap.com/schemas/qvs/1.0"> + </metadata> + <memory unit='KiB'>16777216</memory> + <currentMemory unit='KiB'>16777216</currentMemory> + <memoryBacking> + <nosharepages/> + </memoryBacking> + <vcpu placement='static' cpuset='0-23'>5</vcpu> + <sysinfo type='smbios'> + <system> + <entry name='manufacturer'>qemu</entry> + <entry name='product'>qemu</entry> + </system> + </sysinfo> + <os> + <type arch='x86_64' machine='pc-i440fx-7.0'>hvm</type> + <boot dev='cdrom'/> + <boot dev='hd'/> + <bootmenu enable='no'/> + <smbios mode='sysinfo'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode='host-passthrough' check='none' migratable='on'> + <topology sockets='1' dies='1' cores='5' threads='1'/> + <numa> + <cell id='0' cpus='0-4' memory='16777216' unit='KiB' memAccess='private'/> + </numa> + </cpu> + <clock offset='localtime'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/QVS/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='writeback'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747803601' startupPolicy='optional'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747630800'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747371601'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747198801'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1747026001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1746594001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1746421201'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1745557200'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1745211600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1744174801'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1743570001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1743138001'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742965201'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742360400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1742187600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741928400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741755601'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1741323600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740718800'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740546000'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740373200'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1740114000'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739941201'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739768400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739509200'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739336400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1739163600'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1738904400'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1738558801'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1724816945'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1724045214_1'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.1721622169'/> + <backingStore type='file'> + <format type='qcow2'/> + <source file='/share/Virtualization Main/Win 10 x64 - Home VM/Win 10 x64 - Home VM_00.img'/> + <backingStore/> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + </backingStore> + <target dev='vdb' bus='virtio'/> + <serial>1a3dabc5c33b4308ac01</serial> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source startupPolicy='optional'/> + <target dev='hda' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='usb' index='0' model='nec-xhci' ports='6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:a2:a4:e3'/> + <source bridge='qvs0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <channel type='unix'> + <source mode='bind' path='/QVS/var/lib/libvirt/qemu/1a3dabc5-c33b-4308-acc5-2245f3b64163.agent'/> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <tpm model='tpm-tis'> + <backend type='emulator' version='2.0'/> + </tpm> + <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' keymap='en-us'> + <listen type='address' address='127.0.0.1'/> + </graphics> + <graphics type='spice' autoport='yes' listen='127.0.0.1' keymap='en-us'> + <listen type='address' address='127.0.0.1'/> + <image compression='off'/> + <jpeg compression='never'/> + <zlib compression='never'/> + <playback compression='off'/> + <streaming mode='all'/> + </graphics> + <sound model='ich6'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </sound> + <audio id='1' type='spice'/> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> + </memballoon> + </devices> +</domain> +``` diff --git a/results/classifier/118/unknown/31349848 b/results/classifier/118/unknown/31349848 new file mode 100644 index 00000000..7ddafa8f --- /dev/null +++ b/results/classifier/118/unknown/31349848 @@ -0,0 +1,179 @@ +permissions: 0.908 +PID: 0.903 +device: 0.881 +graphic: 0.876 +register: 0.870 +virtual: 0.869 +risc-v: 0.865 +performance: 0.864 +assembly: 0.855 +vnc: 0.854 +arm: 0.852 +semantic: 0.846 +socket: 0.846 +user-level: 0.845 +architecture: 0.845 +TCG: 0.828 +KVM: 0.827 +debug: 0.826 +files: 0.820 +boot: 0.815 +hypervisor: 0.815 +x86: 0.815 +kernel: 0.809 +VMM: 0.801 +ppc: 0.792 +i386: 0.782 +mistranslation: 0.781 +peripherals: 0.770 +network: 0.769 + +[Qemu-devel] [BUG] qemu stuck when detach host-usb device + +Description of problem: +The guest has a host-usb device(Kingston Technology DataTraveler 100 G3/G4/SE9 +G2), which is attached +to xhci controller(on host). Qemu will stuck if I detach it from guest. + +How reproducible: +100% + +Steps to Reproduce: +1. Use usb stick to copy files in guest , make it busy working. +2. virsh detach-device vm_name usb.xml + +Then qemu will stuck for 20s, I found this is because libusb_release_interface +block for 20s. +Dmesg prints: + +[35442.034861] usb 4-2.1: Disable of device-initiated U1 failed. +[35447.034993] usb 4-2.1: Disable of device-initiated U2 failed. +[35452.035131] usb 4-2.1: Set SEL for device-initiated U1 failed. +[35457.035259] usb 4-2.1: Set SEL for device-initiated U2 failed. + +Is this a hardware error or software's bug? + +On Tue, Nov 27, 2018 at 01:26:24AM +0000, linzhecheng wrote: +> +Description of problem: +> +The guest has a host-usb device(Kingston Technology DataTraveler 100 +> +G3/G4/SE9 G2), which is attached +> +to xhci controller(on host). Qemu will stuck if I detach it from guest. +> +> +How reproducible: +> +100% +> +> +Steps to Reproduce: +> +1. Use usb stick to copy files in guest , make it busy working. +> +2. virsh detach-device vm_name usb.xml +> +> +Then qemu will stuck for 20s, I found this is because +> +libusb_release_interface block for 20s. +> +Dmesg prints: +> +> +[35442.034861] usb 4-2.1: Disable of device-initiated U1 failed. +> +[35447.034993] usb 4-2.1: Disable of device-initiated U2 failed. +> +[35452.035131] usb 4-2.1: Set SEL for device-initiated U1 failed. +> +[35457.035259] usb 4-2.1: Set SEL for device-initiated U2 failed. +> +> +Is this a hardware error or software's bug? +I'd guess software error, could be is libusb or (host) linux kernel. +Cc'ing libusb-devel. + +cheers, + Gerd + +> +-----Original Message----- +> +From: Gerd Hoffmann [ +mailto:address@hidden +> +Sent: Tuesday, November 27, 2018 2:09 PM +> +To: linzhecheng <address@hidden> +> +Cc: address@hidden; wangxin (U) <address@hidden>; +> +Zhoujian (jay) <address@hidden>; address@hidden +> +Subject: Re: [Qemu-devel] [BUG] qemu stuck when detach host-usb device +> +> +On Tue, Nov 27, 2018 at 01:26:24AM +0000, linzhecheng wrote: +> +> Description of problem: +> +> The guest has a host-usb device(Kingston Technology DataTraveler 100 +> +> G3/G4/SE9 G2), which is attached to xhci controller(on host). Qemu will +> +> stuck +> +if I detach it from guest. +> +> +> +> How reproducible: +> +> 100% +> +> +> +> Steps to Reproduce: +> +> 1. Use usb stick to copy files in guest , make it busy working. +> +> 2. virsh detach-device vm_name usb.xml +> +> +> +> Then qemu will stuck for 20s, I found this is because +> +> libusb_release_interface +> +block for 20s. +> +> Dmesg prints: +> +> +> +> [35442.034861] usb 4-2.1: Disable of device-initiated U1 failed. +> +> [35447.034993] usb 4-2.1: Disable of device-initiated U2 failed. +> +> [35452.035131] usb 4-2.1: Set SEL for device-initiated U1 failed. +> +> [35457.035259] usb 4-2.1: Set SEL for device-initiated U2 failed. +> +> +> +> Is this a hardware error or software's bug? +> +> +I'd guess software error, could be is libusb or (host) linux kernel. +> +Cc'ing libusb-devel. +Perhaps it's usb driver's bug. Could you also reproduce it? +> +> +cheers, +> +Gerd + diff --git a/results/classifier/118/unknown/32484936 b/results/classifier/118/unknown/32484936 new file mode 100644 index 00000000..63a9ad0c --- /dev/null +++ b/results/classifier/118/unknown/32484936 @@ -0,0 +1,248 @@ +PID: 0.839 +i386: 0.838 +x86: 0.836 +assembly: 0.835 +semantic: 0.832 +register: 0.831 +vnc: 0.830 +device: 0.830 +socket: 0.829 +kernel: 0.828 +permissions: 0.826 +debug: 0.825 +arm: 0.824 +virtual: 0.822 +hypervisor: 0.821 +architecture: 0.821 +files: 0.816 +performance: 0.815 +peripherals: 0.815 +graphic: 0.813 +risc-v: 0.813 +ppc: 0.813 +network: 0.811 +VMM: 0.810 +boot: 0.810 +TCG: 0.809 +user-level: 0.796 +mistranslation: 0.794 +KVM: 0.793 + +[Qemu-devel] [Snapshot Bug?]Qcow2 meta data corruption + +Hi all, +There was a problem about qcow2 image file happened in my serval vms and I could not figure it out, +so have to ask for some help. +Here is the thing: +At first, I found there were some data corruption in a vm, so I did qemu-img check to all my vms. +parts of check report: +3-Leaked cluster 2926229 refcount=1 reference=0 +4-Leaked cluster 3021181 refcount=1 reference=0 +5-Leaked cluster 3021182 refcount=1 reference=0 +6-Leaked cluster 3021183 refcount=1 reference=0 +7-Leaked cluster 3021184 refcount=1 reference=0 +8-ERROR cluster 3102547 refcount=3 reference=4 +9-ERROR cluster 3111536 refcount=3 reference=4 +10-ERROR cluster 3113369 refcount=3 reference=4 +11-ERROR cluster 3235590 refcount=10 reference=11 +12-ERROR cluster 3235591 refcount=10 reference=11 +423-Warning: cluster offset=0xc000c00020000 is after the end of the image file, can't properly check refcounts. +424-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +425-Warning: cluster offset=0xc0001000c0000 is after the end of the image file, can't properly check refcounts. +426-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +427-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +428-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +429-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +430-Warning: cluster offset=0xc000c00010000 is after the end of the image file, can't properly check refcounts. +After a futher look in, I found two l2 entries point to the same cluster, and that was found in serval qcow2 image files of different vms. +Like this: +table entry conflict (with our qcow2 check +tool): +a table offset : 0x00000093f7080000 level : 2, l1 table entry 100, l2 table entry 7 +b table offset : 0x00000093f7080000 level : 2, l1 table entry 5, l2 table entry 7 +table entry conflict : +a table offset : 0x00000000a01e0000 level : 2, l1 table entry 100, l2 table entry 19 +b table offset : 0x00000000a01e0000 level : 2, l1 table entry 5, l2 table entry 19 +table entry conflict : +a table offset : 0x00000000a01d0000 level : 2, l1 table entry 100, l2 table entry 18 +b table offset : 0x00000000a01d0000 level : 2, l1 table entry 5, l2 table entry 18 +table entry conflict : +a table offset : 0x00000000a01c0000 level : 2, l1 table entry 100, l2 table entry 17 +b table offset : 0x00000000a01c0000 level : 2, l1 table entry 5, l2 table entry 17 +table entry conflict : +a table offset : 0x00000000a01b0000 level : 2, l1 table entry 100, l2 table entry 16 +b table offset : 0x00000000a01b0000 level : 2, l1 table entry 5, l2 table entry 16 +I think the problem is relate to the snapshot create, delete. But I cant reproduce it . +Can Anyone give a hint about how this happen? +Qemu version 2.0.1, I download the source code and make install it. +Qemu parameters: +/usr/bin/kvm -chardev socket,id=qmp,path=/var/run/qemu-server/5855899639838.qmp,server,nowait -mon chardev=qmp,mode=control -vnc :0,websocket,to=200 -enable-kvm -pidfile /var/run/qemu-server/5855899639838.pid -daemonize -name yfMailSvr-200.200.0.14 -smp sockets=1,cores=4 -cpu core2duo,hv_spinlocks=0xffff,hv_relaxed,hv_time,hv_vapic,+sse4.1,+sse4.2,+x2apic,+erms,+smep,+fsgsbase,+f16c,+dca,+pcid,+pdcm,+xtpr,+ht,+ss,+acpi,+ds -nodefaults -vga cirrus -k en-us -boot menu=on,splash-time=8000 -m 8192 -usb -drive if=none,id=drive-ide0,media=cdrom,aio=native -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0 -drive file=/sf/data/36b82a720d3a278001ba904e80c20c13e_ecf4bbbf3e94/images/host-ecf4bbbf3e94/784f3f08532a/yfMailSvr-200.200.0.14.vm/vm-disk-1.qcow2,if=none,id=drive-virtio1,cache=none,aio=native -device virtio-blk-pci,drive=drive-virtio1,id=virtio1,bus=pci.0,addr=0xb -drive file=/sf/data/36b82a720d3a278001ba904e80c20c13e_ecf4bbbf3e94/images/host-ecf4bbbf3e94/784f3f08532a/yfMailSvr-200.200.0.14.vm/vm-disk-2.qcow2,if=none,id=drive-virtio2,cache=none,aio=native -device virtio-blk-pci,drive=drive-virtio2,id=virtio2,bus=pci.0,addr=0xc,bootindex=101 -netdev type=tap,id=net0,ifname=585589963983800,script=/sf/etc/kvm/vtp-bridge,vhost=on,vhostforce=on -device virtio-net-pci,romfile=,mac=FE:FC:FE:F0:AB:BA,netdev=net0,bus=pci.0,addr=0x12,id=net0 -rtc driftfix=slew,clock=rt,base=localtime -global kvm-pit.lost_tick_policy=discard -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 +Thanks +Sangfor VT. +leijian + +Hi all, +There was a problem about qcow2 image file happened in my serval vms and I could not figure it out, +so have to ask for some help. +Here is the thing: +At first, I found there were some data corruption in a vm, so I did qemu-img check to all my vms. +parts of check report: +3-Leaked cluster 2926229 refcount=1 reference=0 +4-Leaked cluster 3021181 refcount=1 reference=0 +5-Leaked cluster 3021182 refcount=1 reference=0 +6-Leaked cluster 3021183 refcount=1 reference=0 +7-Leaked cluster 3021184 refcount=1 reference=0 +8-ERROR cluster 3102547 refcount=3 reference=4 +9-ERROR cluster 3111536 refcount=3 reference=4 +10-ERROR cluster 3113369 refcount=3 reference=4 +11-ERROR cluster 3235590 refcount=10 reference=11 +12-ERROR cluster 3235591 refcount=10 reference=11 +423-Warning: cluster offset=0xc000c00020000 is after the end of the image file, can't properly check refcounts. +424-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +425-Warning: cluster offset=0xc0001000c0000 is after the end of the image file, can't properly check refcounts. +426-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +427-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +428-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +429-Warning: cluster offset=0xc000c000c0000 is after the end of the image file, can't properly check refcounts. +430-Warning: cluster offset=0xc000c00010000 is after the end of the image file, can't properly check refcounts. +After a futher look in, I found two l2 entries point to the same cluster, and that was found in serval qcow2 image files of different vms. +Like this: +table entry conflict (with our qcow2 check +tool): +a table offset : 0x00000093f7080000 level : 2, l1 table entry 100, l2 table entry 7 +b table offset : 0x00000093f7080000 level : 2, l1 table entry 5, l2 table entry 7 +table entry conflict : +a table offset : 0x00000000a01e0000 level : 2, l1 table entry 100, l2 table entry 19 +b table offset : 0x00000000a01e0000 level : 2, l1 table entry 5, l2 table entry 19 +table entry conflict : +a table offset : 0x00000000a01d0000 level : 2, l1 table entry 100, l2 table entry 18 +b table offset : 0x00000000a01d0000 level : 2, l1 table entry 5, l2 table entry 18 +table entry conflict : +a table offset : 0x00000000a01c0000 level : 2, l1 table entry 100, l2 table entry 17 +b table offset : 0x00000000a01c0000 level : 2, l1 table entry 5, l2 table entry 17 +table entry conflict : +a table offset : 0x00000000a01b0000 level : 2, l1 table entry 100, l2 table entry 16 +b table offset : 0x00000000a01b0000 level : 2, l1 table entry 5, l2 table entry 16 +I think the problem is relate to the snapshot create, delete. But I cant reproduce it . +Can Anyone give a hint about how this happen? +Qemu version 2.0.1, I download the source code and make install it. +Qemu parameters: +/usr/bin/kvm -chardev socket,id=qmp,path=/var/run/qemu-server/5855899639838.qmp,server,nowait -mon chardev=qmp,mode=control -vnc :0,websocket,to=200 -enable-kvm -pidfile /var/run/qemu-server/5855899639838.pid -daemonize -name yfMailSvr-200.200.0.14 -smp sockets=1,cores=4 -cpu core2duo,hv_spinlocks=0xffff,hv_relaxed,hv_time,hv_vapic,+sse4.1,+sse4.2,+x2apic,+erms,+smep,+fsgsbase,+f16c,+dca,+pcid,+pdcm,+xtpr,+ht,+ss,+acpi,+ds -nodefaults -vga cirrus -k en-us -boot menu=on,splash-time=8000 -m 8192 -usb -drive if=none,id=drive-ide0,media=cdrom,aio=native -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0 -drive file=/sf/data/36b82a720d3a278001ba904e80c20c13e_ecf4bbbf3e94/images/host-ecf4bbbf3e94/784f3f08532a/yfMailSvr-200.200.0.14.vm/vm-disk-1.qcow2,if=none,id=drive-virtio1,cache=none,aio=native -device virtio-blk-pci,drive=drive-virtio1,id=virtio1,bus=pci.0,addr=0xb -drive file=/sf/data/36b82a720d3a278001ba904e80c20c13e_ecf4bbbf3e94/images/host-ecf4bbbf3e94/784f3f08532a/yfMailSvr-200.200.0.14.vm/vm-disk-2.qcow2,if=none,id=drive-virtio2,cache=none,aio=native -device virtio-blk-pci,drive=drive-virtio2,id=virtio2,bus=pci.0,addr=0xc,bootindex=101 -netdev type=tap,id=net0,ifname=585589963983800,script=/sf/etc/kvm/vtp-bridge,vhost=on,vhostforce=on -device virtio-net-pci,romfile=,mac=FE:FC:FE:F0:AB:BA,netdev=net0,bus=pci.0,addr=0x12,id=net0 -rtc driftfix=slew,clock=rt,base=localtime -global kvm-pit.lost_tick_policy=discard -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 +Thanks +Sangfor VT. +leijian + +Am 03.04.2015 um 12:04 hat leijian geschrieben: +> +Hi all, +> +> +There was a problem about qcow2 image file happened in my serval vms and I +> +could not figure it out, +> +so have to ask for some help. +> +[...] +> +I think the problem is relate to the snapshot create, delete. But I cant +> +reproduce it . +> +Can Anyone give a hint about how this happen? +How did you create/delete your snapshots? + +More specifically, did you take care to never access your image from +more than one process (except if both are read-only)? It happens +occasionally that people use 'qemu-img snapshot' while the VM is +running. This is wrong and can corrupt the image. + +Kevin + +On 04/07/2015 03:33 AM, Kevin Wolf wrote: +> +More specifically, did you take care to never access your image from +> +more than one process (except if both are read-only)? It happens +> +occasionally that people use 'qemu-img snapshot' while the VM is +> +running. This is wrong and can corrupt the image. +Since this has been done by more than one person, I'm wondering if there +is something we can do in the qcow2 format itself to make it harder for +the casual user to cause corruption. Maybe if we declare some bit or +extension header for an image open for writing, which other readers can +use as a warning ("this image is being actively modified; reading it may +fail"), and other writers can use to deny access ("another process is +already modifying this image"), where a writer should set that bit +before writing anything else in the file, then clear it on exit. Of +course, you'd need a way to override the bit to actively clear it to +recover from the case of a writer dying unexpectedly without resetting +it normally. And it won't help the case of a reader opening the file +first, followed by a writer, where the reader could still get thrown off +track. + +Or maybe we could document in the qcow2 format that all readers and +writers should attempt to obtain the appropriate flock() permissions [or +other appropriate advisory locking scheme] over the file header, so that +cooperating processes that both use advisory locking will know when the +file is in use by another process. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library +http://libvirt.org +signature.asc +Description: +OpenPGP digital signature + + +I created/deleted the snapshot by using qmp command "snapshot_blkdev_internal"/"snapshot_delete_blkdev_internal", and for avoiding the case you mentioned above, I have added the flock() permission in the qemu_open(). +Here is the test of doing qemu-img snapshot to a running vm: +Diskfile:/sf/data/36c81f660e38b3b001b183da50b477d89_f8bc123b3e74/images/host-f8bc123b3e74/4a8d8728fcdc/Devried30030.vm/vm-disk-1.qcow2 is used! errno=Resource temporarily unavailable +Does the two cluster entry happen to be the same because of the refcount of using cluster decrease to 0 unexpectedly and is allocated again? +If it was not accessing the image from more than one process, any other exceptions I can test for? +Thanks +leijian +From: +Eric Blake +Date: +2015-04-07 23:27 +To: +Kevin Wolf +; +leijian +CC: +qemu-devel +; +stefanha +Subject: +Re: [Qemu-devel] [Snapshot Bug?]Qcow2 meta data +corruption +On 04/07/2015 03:33 AM, Kevin Wolf wrote: +> More specifically, did you take care to never access your image from +> more than one process (except if both are read-only)? It happens +> occasionally that people use 'qemu-img snapshot' while the VM is +> running. This is wrong and can corrupt the image. +Since this has been done by more than one person, I'm wondering if there +is something we can do in the qcow2 format itself to make it harder for +the casual user to cause corruption. Maybe if we declare some bit or +extension header for an image open for writing, which other readers can +use as a warning ("this image is being actively modified; reading it may +fail"), and other writers can use to deny access ("another process is +already modifying this image"), where a writer should set that bit +before writing anything else in the file, then clear it on exit. Of +course, you'd need a way to override the bit to actively clear it to +recover from the case of a writer dying unexpectedly without resetting +it normally. And it won't help the case of a reader opening the file +first, followed by a writer, where the reader could still get thrown off +track. +Or maybe we could document in the qcow2 format that all readers and +writers should attempt to obtain the appropriate flock() permissions [or +other appropriate advisory locking scheme] over the file header, so that +cooperating processes that both use advisory locking will know when the +file is in use by another process. +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + diff --git a/results/classifier/118/unknown/393569 b/results/classifier/118/unknown/393569 new file mode 100644 index 00000000..9f2b41f4 --- /dev/null +++ b/results/classifier/118/unknown/393569 @@ -0,0 +1,107 @@ +mistranslation: 0.889 +register: 0.880 +user-level: 0.878 +semantic: 0.878 +hypervisor: 0.872 +peripherals: 0.860 +x86: 0.858 +risc-v: 0.857 +KVM: 0.851 +i386: 0.850 +ppc: 0.837 +boot: 0.835 +vnc: 0.835 +graphic: 0.833 +assembly: 0.829 +arm: 0.827 +permissions: 0.823 +virtual: 0.822 +device: 0.819 +performance: 0.817 +TCG: 0.812 +VMM: 0.811 +PID: 0.805 +architecture: 0.803 +kernel: 0.799 +debug: 0.792 +socket: 0.787 +network: 0.760 +files: 0.746 + +qemu cannot load multiple initramfs archives + +According to Documentation/early-userspace/buffer-format.txt, an initramfs can be populated from multiple cpio archives, which seems like it could be a really useful feature when using QEMU to boot Linux kernels directly, without installing them on the disk image. + +Unfortunately, QEMU does not support actually loading multiple files into the initrd space (which is also where initramfs archives go). It would be really nice if it did. + +I'm marking this as wishlist. Technically speaking, our bootload can support multiple initramfs' that are joined together. What we don't do today is generate one of these automagically from multiple -initrd options. This is a completely reasonable thing to do though. + +Linux initrd catting works by appending multiple cpio archives. Usually you pass gzip'ed cpio archives though. +So in order to support multiple -initrd with Linux kernels, we'd need to unpack all initrds, concatenate them and gzip them again so Linux is happy. + +I don't know if that's worth it. + +Multiboot supports multiple "modules" which are represented as -initrd in qemu. I'd rather see multiboot support in Linux than implementing cpio concatenating in qemu. + + Linux initrd catting works by appending multiple cpio +> archives. Usually you pass gzip'ed cpio archives though. So in +> order to support multiple -initrd with Linux kernels, we'd need to +> unpack all initrds, concatenate them and gzip them again so Linux is +> happy. + +That isn't what the Linux documentation says. The relevant portion of +Documentation/early-userspace/buffer-format.txt is: + +,---- +| The full format of the initramfs buffer is defined by the following +| grammar, where: +| * is used to indicate "0 or more occurrences of" +| (|) indicates alternatives +| + indicates concatenation +| GZIP() indicates the gzip(1) of the operand +| ALGN(n) means padding with null bytes to an n-byte boundary +| +| initramfs := ("\0" | cpio_archive | cpio_gzip_archive)* +| +| cpio_gzip_archive := GZIP(cpio_archive) +| +| cpio_archive := cpio_file* + (<nothing> | cpio_trailer) +| +| cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data +| +| cpio_trailer := ALGN(4) + cpio_header + "TRAILER!!!\0" + ALGN(4) +`---- + +That is, you can concatenate gzipped cpio archives together just fine, +as long as you align each one on a 4-byte boundary by padding the +previous one with NULs. + +> Multiboot supports multiple "modules" which are represented as +> -initrd in qemu. I'd rather see multiboot support in Linux than +> implementing cpio concatenating in qemu. + +QEMU has code for that? Where? I get all of two results from: + + % git log -Smultiboot + +-- both in the binary file named "pc-bios/openbios-sparc32" + +Anyway, even if QEMU does have code for that, why should Linux assume +that multiboot modules are necessarily cpio archives for initramfs? +(If that's not what you meant, what *did* you mean?) + + +Now that looks like a really useful feature. I only knew of cpio concatenating so far, not that Linux can handle multiple gzip'ed cpios. + +My multiboot patchset is on its way upstream. It should be in soon unless something breaks utterly ;-). After that you could write a patch that basically does a split by "," and reads several initrds. + +Or is this bug about a feature request because you won't do it? If so, I could take a look at it next time I'm fiddling with the Linux -kernel code. + +Well, I began an attempt to implement it, but the way I was going about it was touching way too much stuff, and I didn't know if the way I was doing it was even reasonable -- it involved replacing the single initrd name with a list of them, using some stuff from that queue.h reimplementation, and it was getting kind of hairy and touching a lot more code than I liked. + +Your way probably would be a bit easier to do, since it would mean that most of the code that passes around what it believes to be the one and only initrd name could continue to do so without change. + +Looking through old bug tickets... If I've got that right, there is multiboot support in QEMU nowadays, and we also have the possibility to load multiple files with the "loader" device ... is that enough, or is still something to be done here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/474968 b/results/classifier/118/unknown/474968 new file mode 100644 index 00000000..ea20a4e8 --- /dev/null +++ b/results/classifier/118/unknown/474968 @@ -0,0 +1,87 @@ +user-level: 0.831 +graphic: 0.820 +network: 0.820 +permissions: 0.818 +architecture: 0.813 +semantic: 0.804 +risc-v: 0.794 +peripherals: 0.793 +debug: 0.787 +kernel: 0.778 +KVM: 0.770 +PID: 0.762 +vnc: 0.762 +device: 0.760 +register: 0.751 +virtual: 0.750 +performance: 0.749 +mistranslation: 0.746 +socket: 0.733 +assembly: 0.729 +arm: 0.725 +ppc: 0.725 +x86: 0.717 +hypervisor: 0.701 +TCG: 0.700 +VMM: 0.697 +boot: 0.638 +files: 0.633 +i386: 0.632 + +kvm smb server hogs cpu guest freeze + +Binary package hint: qemu-kvm + +kvm hogs the CPU reproducibly. I installed an Ubuntu using KVM. I run the machine with -net nic,model=rtl8139,macaddr=f0:00:BA:12:34:56 -net user,hostfwd=tcp::2223-:22,smb=/tmp/share, sshed into the machine and typed "telnet 10.0.2.4 139" to try whether the SMB server works. KVM then hogs the CPU. + +ProblemType: Bug +Architecture: amd64 +Date: Thu Nov 5 01:23:09 2009 +DistroRelease: Ubuntu 9.10 +KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UID PID PPID C SZ RSS PSR STIME TTY TIME CMD +MachineType: LENOVO 766636G +Package: kvm 1:84+dfsg-0ubuntu16+0.11.0+0ubuntu6.3 +PccardctlIdent: + Socket 0: + no product info available +PccardctlStatus: + Socket 0: + no card +ProcCmdLine: root=/dev/mapper/cryptroot source=UUID=9c3d5596-27c6-4fd5-bfcd-fa8eef6f1230 ro quiet splash crashkernel=384M-2G:64M,2G-:128M +SourcePackage: qemu-kvm +Uname: Linux 2.6.32-999-generic x86_64 +dmi.bios.date: 07/01/2008 +dmi.bios.vendor: LENOVO +dmi.bios.version: 7NETB6WW (2.16 ) +dmi.board.name: 766636G +dmi.board.vendor: LENOVO +dmi.board.version: Not Available +dmi.chassis.asset.tag: No Asset Information +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Not Available +dmi.modalias: dmi:bvnLENOVO:bvr7NETB6WW(2.16):bd07/01/2008:svnLENOVO:pn766636G:pvrThinkPadX61s:rvnLENOVO:rn766636G:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: +dmi.product.name: 766636G +dmi.product.version: ThinkPad X61s +dmi.sys.vendor: LENOVO + + + +Thanks for your bug report and for your contribution to ubuntu. Does kvm hogs the CPU if you're not connecting to the smb server? How much memory is allocated to the guest? + +No it does not hog the CPU if I'm not triggering it the way I described. I run the machine with 512 megs. + +I was able to reproduce this in the way described, marking confirmed. + +I'm totally not familiar with the smb option, having never used it. I'm lowering the priority from Medium -> Low, since smb is not one of the most critical kvm features. + +I'm also forwarding the bug upstream. Anthony, this bug is totally reproducible on qemu-kvm 0.12.3, as described in the initial report. Can you confirm it against upstream code? Are the invocations/options correct? Is this expected to work? + +Triaging old bug tickets... Can you still reproduce this behavior with the latest version, or has the problem been fixed now? + +There hasn't been a reply to my question in the last comment within months, so I assume nobody cares about this anymore. So I'm closing this ticket now... + +Clearing old bugs: No more occurring in any of my recent KVMs, setting this old bug to incomplete. + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/118/unknown/478 b/results/classifier/118/unknown/478 new file mode 100644 index 00000000..720600f9 --- /dev/null +++ b/results/classifier/118/unknown/478 @@ -0,0 +1,429 @@ +hypervisor: 0.910 +performance: 0.906 +register: 0.904 +permissions: 0.899 +device: 0.894 +mistranslation: 0.888 +KVM: 0.875 +user-level: 0.872 +debug: 0.871 +peripherals: 0.868 +files: 0.867 +virtual: 0.864 +TCG: 0.863 +risc-v: 0.862 +arm: 0.855 +VMM: 0.854 +x86: 0.853 +network: 0.851 +semantic: 0.846 +architecture: 0.845 +graphic: 0.845 +vnc: 0.839 +assembly: 0.837 +socket: 0.834 +boot: 0.827 +kernel: 0.827 +PID: 0.811 +ppc: 0.808 +i386: 0.792 + +Loss of network trafic when virtual iommu is enabled +Steps to reproduce: +1. Setup the hypervisor +- Vt-x and Vt-d present +- IOMMU enabled on the kernel command line (iommu=force intel_iommu=on) +- OpenvSwitch started with DPDK and IOMMU support +```shell +ovs-vsctl --no-wait set Open_vSwitch . other_config:vhost-iommu-support=true +ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true +``` +- One OVS bridge with DPDK enabled +```shell +ovs-vsctl add-br br_dpdk -- set bridge br_dpdk datapath_type=netdev +``` +- VM1 makes use of a DPDK port without virtualized IOMMU +- VM2 makes use of a DPDK port with virtualized IOMMU +- Add a virtual port (DPDPK) for VM1, +```shell +ovs-vsctl add-port br_dpdk dpdk1 -- set Interface dpdk1 \ + type=dpdkvhostuserclient options:vhost-server-path=/var/run/openvswitch/dpdk1 +``` +- Add a virtual port (DPDPK) for VM2, +```shell +ovs-vsctl add-port br_dpdk dpdk2 -- set Interface dpdk2 \ + type=dpdkvhostuserclient options:vhost-server-path=/var/run/openvswitch/dpdk2 +``` + +2. Start VM1. This VM is used to generate traffic toward VM2 +- VM1 is started. The way it is started has no impact on the outcome of the test. +- It declares a vhost-user interface (server mode) with dpdk1 as the source. +- The guest OS makes use of virtio-pci to handle its network interface. +- Its interface is having the IP 192.168.3.10/24 + +3. Start VM2. This VM shows the defect +- VM2 is started. +- It declares an iommu device and a vhost-user network interface (server mode) with +dpdk2 as the source. +- The vhost-user interface enables iommu and the ats service. +- It uses the Q35 chipset, it has a PCI topology that ensures that the network interface is its in own IOMMU group +- The VM is started this way: +```shell +qemu-system-x86_64 + -enable-kvm \ + -name guest=debian-iommu,debug-threads=on \ + -machine pc-q35-3.1,accel=kvm,usb=off,dump-guest-core=off,\ +mem-merge=off,kernel_irqchip=split \ + -cpu IvyBridge-IBRS,ss=on,movbe=on,hypervisor=on,arat=on,\ +tsc_adjust=on,mpx=on,rdseed=on,smap=on,clflushopt=on,sha-ni=on,\ +umip=on,ssbd=on,xsaveopt=on,xsavec=on,xgetbv1=on,xsaves=on,pdpe1gb=on,\ +3dnowprefetch=on,avx=off,f16c=off \ + -m 4096 \ + -mem-prealloc \ + -overcommit mem-lock=on \ + -smp 2,sockets=1,cores=2,threads=1 \ + -object memory-backend-file,id=ram-node0,\ +mem-path=/dev/hugepages/libvirt/qemu/2-debian-iommu,\ +share=yes,size=4294967296 \ + -numa node,nodeid=0,cpus=0-1,memdev=ram-node0 \ + -uuid 65847f47-3454-4576-ab6c-6a1c75041ea7 \ + -display none \ + -no-user-config \ + -nodefaults \ + -rtc base=utc \ + -no-shutdown \ + -global ICH9-LPC.disable_s3=1 \ + -global ICH9-LPC.disable_s4=1 \ + -boot strict=on \ + -device intel-iommu,intremap=on,caching-mode=on,eim=off,device-iotlb=on \ + -device pcie-root-port,port=0x8,chassis=1,id=pci.1,\ +bus=pcie.0,multifunction=off,addr=0x1 \ + -device pcie-root-port,port=0x10,chassis=2,id=pci.2,\ +bus=pcie.0,multifunction=off,addr=0x2 \ + -device pcie-root-port,port=0x18,chassis=3,id=pci.3,\ +bus=pcie.0,multifunction=off,addr=0x3 \ + -device pcie-root-port,port=0x20,chassis=4,id=pci.4,\ +bus=pcie.0,multifunction=off,addr=0x4 \ + -device pcie-root-port,port=0x28,chassis=5,id=pci.5,\ +bus=pcie.0,multifunction=off,addr=0x5 \ + -device pcie-root-port,port=0x30,chassis=6,id=pci.6,\ +bus=pcie.0,multifunction=off,addr=0x6 \ + -device pcie-root-port,port=0x38,chassis=7,id=pci.7,\ +bus=pcie.0,multifunction=off,addr=0x7 \ + -device qemu-xhci,id=usb,bus=pci.4,addr=0x0 \ + -drive file=/var/lib/libvirt/images/backing-storage/\ +debian-iommu/debian-iommu-0.qcow2,format=qcow2,if=none,\ +id=drive-virtio-disk0,cache=directsync \ + -device virtio-blk-pci,scsi=off,bus=pci.5,addr=0x0,\ +drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=off \ +\ + -chardev socket,id=charnet0,\ +path=/var/run/openvswitch/dpdk2,server=on \ + -netdev vhost-user,chardev=charnet0,id=hostnet0 \ + -device virtio-net-pci,mrg_rxbuf=on,netdev=hostnet0,\ +id=net0,mac=52:54:00:c2:bf:aa,bus=pci.1,addr=0x0,iommu_platform=on,ats=on \ +\ + -chardev pty,id=charserial0 \ + -device isa-serial,chardev=charserial0,id=serial0 \ +\ + -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,\ +resourcecontrol=deny \ + -msg timestamp=on +``` + +- the guest OS kernel has IOMMU enabled (iommu=true intel_iommu=on) + +4. The DPDK application is started in VM2 +- the network interface is bound to the vfio driver +```shell +# echo 0000:01:00.0 > /sys/bus/pci/drivers/virtio-pci/unbind +# echo vfio-pci > /sys/bus/pci/devices/0000:01:00.0/driver_override +# echo 0000:01:00.0 > /sys/bus/pci/drivers/vfio-pci/bind +# echo 512 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages +``` + +- the dpdk-testpmd is used to start a forwarding between the network +interface and a tap device +```shell +dpdk-testpmd --pci-whitelist "01:00.0" --iova-mode va --legacy-mem --socket-mem 500 --vdev=net_tap0 + +EAL: Detected 2 lcore(s) +EAL: Detected 1 NUMA nodes +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: No free hugepages reported in hugepages-1048576kB +EAL: Probing VFIO support... +EAL: VFIO support initialized +EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clo! +EAL: PCI device 0000:01:00.0 on NUMA socket -1 +EAL: Invalid NUMA socket, default to 0 +EAL: probe driver: 1af4:1041 net_virtio +EAL: using IOMMU type 1 (Type 1) +rte_pmd_tap_probe(): Initializing pmd_tap for net_tap0 as dtap%d +[ 47.283172] tun: Universal TUN/TAP device driver, 1.6 +testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=155456, size=2176, sock0 +testpmd: preferred mempool ops selected: ring_mp_mc +Configuring Port 0 (socket 0) +EAL: Error disabling MSI-X interrupts for fd 267 +Port 0: 52:54:00:C2:BF:AA +Configuring Port 1 (socket 0) +Port 1: CE:61:2A:67:F4:B8 +Checking link statuses... +[ 47.562560] device dtap0 entered promiscuous mode + +No commandline core given, start packet forwarding +io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support enabled, MPe +Logical Core 1 (socket 0) forwards packets on 2 streams: + RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01 + RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 + + io packet forwarding packets/burst=32 + nb forwarding cores=1 - nb forwarding ports=2 + port 0: RX queue number: 1 Tx queue number: 1 + Rx offloads=0x0 Tx offloads=0x0 + RX queue: 0 + RX desc=0 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + RX Offloads=0x0 + TX queue: 0 + TX desc=0 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX offloads=0x0 - TX RS bit threshold=0 + port 1: RX queue number: 1 Tx queue number: 1 + Rx offloads=0x0 Tx offloads=0x0 + RX queue: 0 + RX desc=0 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + RX Offloads=0x0 + TX queue: 0 + TX desc=0 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX offloads=0x0 - TX RS bit threshold=0 +Press enter to exit +``` + +- An IP is set on the dtap0 interface + +```shell +^Z +# ip a a 192.168.3.20/24 dev dtap0 +# fg +``` + +5. The traffic is initiated from VM1 +- from the VM1 console a ping the VM2 is started and is working fine. + +```shell +# ping 192.168.3.20 +PING 192.168.3.20 (192.168.3.20) 56(84) bytes of data. +64 bytes from 192.168.3.20: icmp_seq=1 ttl=64 time=0.320 ms +64 bytes from 192.168.3.20: icmp_seq=2 ttl=64 time=0.172 ms +64 bytes from 192.168.3.20: icmp_seq=3 ttl=64 time=0.163 ms +^C +--- 192.168.3.20 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 4ms +rtt min/avg/max/mdev = 0.163/0.218/0.320/0.072 ms +``` +- from the VM1 console a UDP iperf is started and is working fine (no server-side iperf is started) +```shell +# iperf -c 192.168.3.20 -u +------------------------------------------------------------ +Client connecting to 192.168.3.20, UDP port 5001 +Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust) +UDP buffer size: 208 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.3.10 port 49124 connected with 192.168.3.20 port 5001 +read failed: Connection refused +[ 3] WARNING: did not receive ack of last datagram after 1 tries. +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec +[ 3] Sent 892 datagrams +``` +- from the VM2 console the <Enter> key is pressed +```shell +Telling cores to stop... +Waiting for lcores to finish... + + ---------------------- Forward statistics for port 0 ---------------------- + RX-packets: 904 RX-dropped: 0 RX-total: 904 + TX-packets: 37 TX-dropped: 0 TX-total: 37 + ---------------------------------------------------------------------------- + + ---------------------- Forward statistics for port 1 ---------------------- + RX-packets: 37 RX-dropped: 0 RX-total: 37 + TX-packets: 904 TX-dropped: 0 TX-total: 904 + ---------------------------------------------------------------------------- + + +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++ + RX-packets: 941 RX-dropped: 0 RX-total: 941 + TX-packets: 941 TX-dropped: 0 TX-total: 941 + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +Done. + +Stopping port 0... +Stopping ports... +Done + +Stopping port 1... +Stopping ports... +Done + +Shutting down port 0... +Closing ports... +EAL: Error disabling MSI-X interrupts for fd 267 +Done + +Shutting down port 1... +Closing ports... +Done + +Bye... + +``` + +- the guest OS is rebooted (the QEMU emulator is not restarted) +```shell +# shutdown -r now +``` + +6. After reboot, impossible to resume the network traffic +- the same setup is applied (bind the interface to the vfio driver, add enough huge pages, start the dpdk-testpmd program, add an ip to the tap interface). The dpdk-testpmd output shows: +```shell +EAL: Detected 2 lcore(s) +EAL: Detected 1 NUMA nodes +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: No free hugepages reported in hugepages-1048576kB +EAL: Probing VFIO support... +EAL: VFIO support initialized +EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clo! +EAL: PCI device 0000:01:00.0 on NUMA socket -1 +EAL: Invalid NUMA socket, default to 0 +EAL: probe driver: 1af4:1041 net_virtio +EAL: using IOMMU type 1 (Type 1) +rte_pmd_tap_probe(): Initializing pmd_tap for net_tap0 as dtap%d +[ 37.865360] tun: Universal TUN/TAP device driver, 1.6 +testpmd: create a new mbuf pool <mbuf_pool_socket_0>: n=155456, size=2176, sock0 +testpmd: preferred mempool ops selected: ring_mp_mc +Configuring Port 0 (socket 0) +EAL: Error disabling MSI-X interrupts for fd 267 +Port 0: 52:54:00:C2:BF:AA +Configuring Port 1 (socket 0) +Port 1: 0A:78:00:1F:D6:CB +Checking link statuses... +[ 38.151800] device dtap0 entered promiscuous mode + +No commandline core given, start packet forwarding +io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support enabled, MPe +Logical Core 1 (socket 0) forwards packets on 2 streams: + RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01 + RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 + + io packet forwarding packets/burst=32 + nb forwarding cores=1 - nb forwarding ports=2 + port 0: RX queue number: 1 Tx queue number: 1 + Rx offloads=0x0 Tx offloads=0x0 + RX queue: 0 + RX desc=0 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + RX Offloads=0x0 + TX queue: 0 + TX desc=0 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX offloads=0x0 - TX RS bit threshold=0 + port 1: RX queue number: 1 Tx queue number: 1 + Rx offloads=0x0 Tx offloads=0x0 + RX queue: 0 + RX desc=0 - RX free threshold=0 + RX threshold registers: pthresh=0 hthresh=0 wthresh=0 + RX Offloads=0x0 + TX queue: 0 + TX desc=0 - TX free threshold=0 + TX threshold registers: pthresh=0 hthresh=0 wthresh=0 + TX offloads=0x0 - TX RS bit threshold=0 +Press enter to exit +``` + +- From the VM2 console, any attempt to send pings or the engage in UDP iperf will fail +```shell +# ping 192.168.3.20 +PING 192.168.3.20 (192.168.3.20) 56(84) bytes of data. +From 192.168.3.10 icmp_seq=1 Destination Host Unreachable +From 192.168.3.10 icmp_seq=2 Destination Host Unreachable +From 192.168.3.10 icmp_seq=3 Destination Host Unreachable +From 192.168.3.10 icmp_seq=4 Destination Host Unreachable +From 192.168.3.10 icmp_seq=5 Destination Host Unreachable +From 192.168.3.10 icmp_seq=6 Destination Host Unreachable +From 192.168.3.10 icmp_seq=7 Destination Host Unreachable +From 192.168.3.10 icmp_seq=8 Destination Host Unreachable +From 192.168.3.10 icmp_seq=9 Destination Host Unreachable +From 192.168.3.10 icmp_seq=10 Destination Host Unreachable +From 192.168.3.10 icmp_seq=11 Destination Host Unreachable +From 192.168.3.10 icmp_seq=12 Destination Host Unreachable +^C +--- 192.168.3.20 ping statistics --- +13 packets transmitted, 0 received, +12 errors, 100% packet loss, time 327ms + +# iperf -c 192.168.3.20 -u +------------------------------------------------------------ +Client connecting to 192.168.3.20, UDP port 5001 +Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust) +UDP buffer size: 208 KByte (default) +------------------------------------------------------------ +[ 3] local 192.168.3.10 port 54228 connected with 192.168.3.20 port 5001 +[ 3] WARNING: did not receive ack of last datagram after 10 tries. +[ ID] Interval Transfer Bandwidth +[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec +[ 3] Sent 892 datagrams +``` + +- from the VM2 console the <Enter> key is pressed +```shell +Telling cores to stop... +Waiting for lcores to finish... + + ---------------------- Forward statistics for port 0 ---------------------- + RX-packets: 0 RX-dropped: 0 RX-total: 0 + TX-packets: 10 TX-dropped: 0 TX-total: 10 + ---------------------------------------------------------------------------- + + ---------------------- Forward statistics for port 1 ---------------------- + RX-packets: 10 RX-dropped: 0 RX-total: 10 + TX-packets: 0 TX-dropped: 0 TX-total: 0 + ---------------------------------------------------------------------------- + + +++++++++++++++ Accumulated forward statistics for all ports+++++++++++++++ + RX-packets: 10 RX-dropped: 0 RX-total: 10 + TX-packets: 10 TX-dropped: 0 TX-total: 10 + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +Done. + +Stopping port 0... +Stopping ports... +Done + +Stopping port 1... +Stopping ports... +Done + +Shutting down port 0... +Closing ports... +EAL: Error disabling MSI-X interrupts for fd 267 +Done + +Shutting down port 1... +Closing ports... +Done + +Bye... +``` +Additional information: +1. How to resume the network traffic + +- If VM2 is fully restarted (the QEMU processed is restarted), and the setup is reapplied, +the trafic with VM1 is restored. + +2. Alternate cases +- Not systematically, it also happens that the trafic is definitively lost only by stopping and then restarting dpdk-testpmd in VM2 + +- I also met the case while running another DPDK application that is making use of multithreading: one thread is receiving data from the network interface and pushing it to the tap interface, while the other thread is receiving data from the tap interface and pushing it to the network interface. No reboot of the guest OS, no interruption of the DPDK application, the traffic is just flowing for less than a minute until it is definitively lost. diff --git a/results/classifier/118/unknown/57756589 b/results/classifier/118/unknown/57756589 new file mode 100644 index 00000000..ac4a5687 --- /dev/null +++ b/results/classifier/118/unknown/57756589 @@ -0,0 +1,1446 @@ +peripherals: 0.875 +hypervisor: 0.863 +mistranslation: 0.861 +register: 0.858 +architecture: 0.856 +device: 0.853 +vnc: 0.851 +virtual: 0.845 +permissions: 0.842 +assembly: 0.841 +performance: 0.839 +ppc: 0.838 +semantic: 0.835 +TCG: 0.833 +VMM: 0.833 +arm: 0.828 +boot: 0.827 +user-level: 0.826 +graphic: 0.824 +network: 0.822 +socket: 0.820 +PID: 0.819 +KVM: 0.817 +kernel: 0.817 +files: 0.816 +x86: 0.814 +debug: 0.803 +i386: 0.782 +risc-v: 0.755 + +[Qemu-devel] 答复: Re: 答复: Re: 答复: Re: [BUG]COLO failover hang + +amost like wikiï¼but panic in Primary Node. + + + + +setp: + +1 + +Primary Node. + +x86_64-softmmu/qemu-system-x86_64 -enable-kvm -boot c -m 2048 -smp 2 -qmp stdio +-vnc :7 -name primary -cpu qemu64,+kvmclock -device piix3-usb-uhci -usb +-usbdevice tablet\ + + -drive +if=virtio,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1, + + +children.0.file.filename=/mnt/sdd/pure_IMG/linux/redhat/rhel_6.5_64_2U_ide,children.0.driver=qcow2 + -S \ + + -netdev +tap,id=hn1,vhost=off,script=/etc/qemu-ifup2,downscript=/etc/qemu-ifdown2 \ + + -device e1000,id=e1,netdev=hn1,mac=52:a4:00:12:78:67 \ + + -netdev +tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ + + -device e1000,id=e0,netdev=hn0,mac=52:a4:00:12:78:66 \ + + -chardev socket,id=mirror0,host=9.61.1.8,port=9003,server,nowait -chardev +socket,id=compare1,host=9.61.1.8,port=9004,server,nowait \ + + -chardev socket,id=compare0,host=9.61.1.8,port=9001,server,nowait -chardev +socket,id=compare0-0,host=9.61.1.8,port=9001 \ + + -chardev socket,id=compare_out,host=9.61.1.8,port=9005,server,nowait \ + + -chardev socket,id=compare_out0,host=9.61.1.8,port=9005 \ + + -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \ + + -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out +-object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \ + + -object +colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,outdev=compare_out0 + +2 Second node: + +x86_64-softmmu/qemu-system-x86_64 -boot c -m 2048 -smp 2 -qmp stdio -vnc :7 +-name secondary -enable-kvm -cpu qemu64,+kvmclock -device piix3-usb-uhci -usb +-usbdevice tablet\ + + -drive +if=none,id=colo-disk0,file.filename=/mnt/sdd/pure_IMG/linux/redhat/rhel_6.5_64_2U_ide,driver=qcow2,node-name=node0 + \ + + -drive +if=virtio,id=active-disk0,driver=replication,mode=secondary,file.driver=qcow2,top-id=active-disk0,file.file.filename=/mnt/ramfstest/active_disk.img,file.backing.driver=qcow2,file.backing.file.filename=/mnt/ramfstest/hidden_disk.img,file.backing.backing=colo-disk0 + \ + + -netdev +tap,id=hn1,vhost=off,script=/etc/qemu-ifup2,downscript=/etc/qemu-ifdown2 \ + + -device e1000,id=e1,netdev=hn1,mac=52:a4:00:12:78:67 \ + + -netdev +tap,id=hn0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ + + -device e1000,netdev=hn0,mac=52:a4:00:12:78:66 -chardev +socket,id=red0,host=9.61.1.8,port=9003 \ + + -chardev socket,id=red1,host=9.61.1.8,port=9004 \ + + -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \ + + -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \ + + -object filter-rewriter,id=rew0,netdev=hn0,queue=all -incoming tcp:0:8888 + +3 Secondary node: + +{'execute':'qmp_capabilities'} + +{ 'execute': 'nbd-server-start', + + 'arguments': {'addr': {'type': 'inet', 'data': {'host': '9.61.1.7', 'port': +'8889'} } } + +} + +{'execute': 'nbd-server-add', 'arguments': {'device': 'colo-disk0', 'writable': +true } } + +4:Primary Nodeï¼ + +{'execute':'qmp_capabilities'} + + +{ 'execute': 'human-monitor-command', + + 'arguments': {'command-line': 'drive_add -n buddy +driver=replication,mode=primary,file.driver=nbd,file.host=9.61.1.7,file.port=8889,file.export=colo-disk0,node-name=node0'}} + +{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'colo-disk0', 'node': +'node0' } } + +{ 'execute': 'migrate-set-capabilities', + + 'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } +] } } + +{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:9.61.1.7:8888' } } + + + + +then can see two runing VMs, whenever you make changes to PVM, SVM will be +synced. + + + + +5ï¼Primary Nodeï¼ + +echo c ï¼ /proc/sysrq-trigger + + + + +ï¼ï¼Secondary node: + +{ 'execute': 'nbd-server-stop' } + +{ "execute": "x-colo-lost-heartbeat" } + + + + +then can see the Secondary node hang at recvmsg recvmsg . + + + + + + + + + + + + +åå§é®ä»¶ + + + +åä»¶äººï¼ address@hidden +æ¶ä»¶äººï¼ç广10165992 address@hidden +æéäººï¼ address@hidden address@hidden +æ¥ æ ï¼2017å¹´03æ21æ¥ 16:27 +主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: [BUG]COLO failover hang + + + + + +Hi, + +On 2017/3/21 16:10, address@hidden wrote: +ï¼ Thank youã +ï¼ +ï¼ I have test areadyã +ï¼ +ï¼ When the Primary Node panic,the Secondary Node qemu hang at the same placeã +ï¼ +ï¼ Incorrding +http://wiki.qemu-project.org/Features/COLO +ï¼kill Primary Node qemu +will not produce the problem,but Primary Node panic canã +ï¼ +ï¼ I think due to the feature of channel does not support +QIO_CHANNEL_FEATURE_SHUTDOWN. +ï¼ +ï¼ + +Yes, you are right, when we do failover for primary/secondary VM, we will +shutdown the related +fd in case it is stuck in the read/write fd. + +It seems that you didn't follow the above introduction exactly to do the test. +Could you +share your test procedures ? Especially the commands used in the test. + +Thanks, +Hailiang + +ï¼ when failover,channel_shutdown could not shut down the channel. +ï¼ +ï¼ +ï¼ so the colo_process_incoming_thread will hang at recvmsg. +ï¼ +ï¼ +ï¼ I test a patch: +ï¼ +ï¼ +ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ +ï¼ +ï¼ index 13966f1..d65a0ea 100644 +ï¼ +ï¼ +ï¼ --- a/migration/socket.c +ï¼ +ï¼ +ï¼ +++ b/migration/socket.c +ï¼ +ï¼ +ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ +ï¼ +ï¼ } +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ trace_migration_socket_incoming_accepted() +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming") +ï¼ +ï¼ +ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ +ï¼ +ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ +ï¼ +ï¼ QIO_CHANNEL(sioc)) +ï¼ +ï¼ +ï¼ object_unref(OBJECT(sioc)) +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ My test will not hang any more. +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ åå§é®ä»¶ +ï¼ +ï¼ +ï¼ +ï¼ åä»¶äººï¼ address@hidden +ï¼ æ¶ä»¶äººï¼ç广10165992 address@hidden +ï¼ æéäººï¼ address@hidden address@hidden +ï¼ æ¥ æ ï¼2017å¹´03æ21æ¥ 15:58 +ï¼ ä¸» é¢ ï¼Re: [Qemu-devel] çå¤: Re: [BUG]COLO failover hang +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ Hi,Wang. +ï¼ +ï¼ You can test this branch: +ï¼ +ï¼ +https://github.com/coloft/qemu/tree/colo-v5.1-developing-COLO-frame-v21-with-shared-disk +ï¼ +ï¼ and please follow wiki ensure your own configuration correctly. +ï¼ +ï¼ +http://wiki.qemu-project.org/Features/COLO +ï¼ +ï¼ +ï¼ Thanks +ï¼ +ï¼ Zhang Chen +ï¼ +ï¼ +ï¼ On 03/21/2017 03:27 PM, address@hidden wrote: +ï¼ ï¼ +ï¼ ï¼ hi. +ï¼ ï¼ +ï¼ ï¼ I test the git qemu master have the same problem. +ï¼ ï¼ +ï¼ ï¼ (gdb) bt +ï¼ ï¼ +ï¼ ï¼ #0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, +ï¼ ï¼ niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 +ï¼ ï¼ +ï¼ ï¼ #1 0x00007f658e4aa0c2 in qio_channel_read +ï¼ ï¼ (address@hidden, address@hidden "", +ï¼ ï¼ address@hidden, address@hidden) at io/channel.c:114 +ï¼ ï¼ +ï¼ ï¼ #2 0x00007f658e3ea990 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ buf=0x7f65907cb838 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ +ï¼ ï¼ #3 0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at +ï¼ ï¼ migration/qemu-file.c:295 +ï¼ ï¼ +ï¼ ï¼ #4 0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, +ï¼ ï¼ address@hidden) at migration/qemu-file.c:555 +ï¼ ï¼ +ï¼ ï¼ #5 0x00007f658e3ea34b in qemu_get_byte (address@hidden) at +ï¼ ï¼ migration/qemu-file.c:568 +ï¼ ï¼ +ï¼ ï¼ #6 0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ migration/qemu-file.c:648 +ï¼ ï¼ +ï¼ ï¼ #7 0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, +ï¼ ï¼ address@hidden) at migration/colo.c:244 +ï¼ ï¼ +ï¼ ï¼ #8 0x00007f658e3e681e in colo_receive_check_message (f=ï¼optimized +ï¼ ï¼ outï¼, address@hidden, +ï¼ ï¼ address@hidden) +ï¼ ï¼ +ï¼ ï¼ at migration/colo.c:264 +ï¼ ï¼ +ï¼ ï¼ #9 0x00007f658e3e740e in colo_process_incoming_thread +ï¼ ï¼ (opaque=0x7f658eb30360 ï¼mis_current.31286ï¼) at migration/colo.c:577 +ï¼ ï¼ +ï¼ ï¼ #10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ +ï¼ ï¼ #11 0x00007f65881983ed in clone () from /lib64/libc.so.6 +ï¼ ï¼ +ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ +ï¼ ï¼ $2 = 0x7f658ff7d5c0 "migration-socket-incoming" +ï¼ ï¼ +ï¼ ï¼ (gdb) p ioc-ï¼features Do not support QIO_CHANNEL_FEATURE_SHUTDOWN +ï¼ ï¼ +ï¼ ï¼ $3 = 0 +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ (gdb) bt +ï¼ ï¼ +ï¼ ï¼ #0 socket_accept_incoming_migration (ioc=0x7fdcceeafa90, +ï¼ ï¼ condition=G_IO_IN, opaque=0x7fdcceeafa90) at migration/socket.c:137 +ï¼ ï¼ +ï¼ ï¼ #1 0x00007fdcc6966350 in g_main_dispatch (context=ï¼optimized outï¼) at +ï¼ ï¼ gmain.c:3054 +ï¼ ï¼ +ï¼ ï¼ #2 g_main_context_dispatch (context=ï¼optimized outï¼, +ï¼ ï¼ address@hidden) at gmain.c:3630 +ï¼ ï¼ +ï¼ ï¼ #3 0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213 +ï¼ ï¼ +ï¼ ï¼ #4 os_host_main_loop_wait (timeout=ï¼optimized outï¼) at +ï¼ ï¼ util/main-loop.c:258 +ï¼ ï¼ +ï¼ ï¼ #5 main_loop_wait (address@hidden) at +ï¼ ï¼ util/main-loop.c:506 +ï¼ ï¼ +ï¼ ï¼ #6 0x00007fdccb526187 in main_loop () at vl.c:1898 +ï¼ ï¼ +ï¼ ï¼ #7 main (argc=ï¼optimized outï¼, argv=ï¼optimized outï¼, envp=ï¼optimized +ï¼ ï¼ outï¼) at vl.c:4709 +ï¼ ï¼ +ï¼ ï¼ (gdb) p ioc-ï¼features +ï¼ ï¼ +ï¼ ï¼ $1 = 6 +ï¼ ï¼ +ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ +ï¼ ï¼ $2 = 0x7fdcce1b1ab0 "migration-socket-listener" +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ May be socket_accept_incoming_migration should +ï¼ ï¼ call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)?? +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ thank you. +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ åå§é®ä»¶ +ï¼ ï¼ address@hidden +ï¼ ï¼ address@hidden +ï¼ ï¼ address@hidden@huawei.comï¼ +ï¼ ï¼ *æ¥ æ ï¼*2017å¹´03æ16æ¥ 14:46 +ï¼ ï¼ *主 é¢ ï¼**Re: [Qemu-devel] COLO failover hang* +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ On 03/15/2017 05:06 PM, wangguang wrote: +ï¼ ï¼ ï¼ am testing QEMU COLO feature described here [QEMU +ï¼ ï¼ ï¼ Wiki]( +http://wiki.qemu-project.org/Features/COLO +). +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ When the Primary Node panic,the Secondary Node qemu hang. +ï¼ ï¼ ï¼ hang at recvmsg in qio_channel_socket_readv. +ï¼ ï¼ ï¼ And I run { 'execute': 'nbd-server-stop' } and { "execute": +ï¼ ï¼ ï¼ "x-colo-lost-heartbeat" } in Secondary VM's +ï¼ ï¼ ï¼ monitor,the Secondary Node qemu still hang at recvmsg . +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ I found that the colo in qemu is not complete yet. +ï¼ ï¼ ï¼ Do the colo have any plan for development? +ï¼ ï¼ +ï¼ ï¼ Yes, We are developing. You can see some of patch we pushing. +ï¼ ï¼ +ï¼ ï¼ ï¼ Has anyone ever run it successfully? Any help is appreciated! +ï¼ ï¼ +ï¼ ï¼ In our internal version can run it successfully, +ï¼ ï¼ The failover detail you can ask Zhanghailiang for help. +ï¼ ï¼ Next time if you have some question about COLO, +ï¼ ï¼ please cc me and zhanghailiang address@hidden +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ Thanks +ï¼ ï¼ Zhang Chen +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ centos7.2+qemu2.7.50 +ï¼ ï¼ ï¼ (gdb) bt +ï¼ ï¼ ï¼ #0 0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0 +ï¼ ï¼ ï¼ #1 0x00007f3e0332b738 in qio_channel_socket_readv (ioc=ï¼optimized outï¼, +ï¼ ï¼ ï¼ iov=ï¼optimized outï¼, niov=ï¼optimized outï¼, fds=0x0, nfds=0x0, errp=0x0) at +ï¼ ï¼ ï¼ io/channel-socket.c:497 +ï¼ ï¼ ï¼ #2 0x00007f3e03329472 in qio_channel_read (address@hidden, +ï¼ ï¼ ï¼ address@hidden "", address@hidden, +ï¼ ï¼ ï¼ address@hidden) at io/channel.c:97 +ï¼ ï¼ ï¼ #3 0x00007f3e032750e0 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ ï¼ buf=0x7f3e05910f38 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ ï¼ #4 0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at +ï¼ ï¼ ï¼ migration/qemu-file.c:257 +ï¼ ï¼ ï¼ #5 0x00007f3e03274a41 in qemu_peek_byte (address@hidden, +ï¼ ï¼ ï¼ address@hidden) at migration/qemu-file.c:510 +ï¼ ï¼ ï¼ #6 0x00007f3e03274aab in qemu_get_byte (address@hidden) at +ï¼ ï¼ ï¼ migration/qemu-file.c:523 +ï¼ ï¼ ï¼ #7 0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ ï¼ migration/qemu-file.c:603 +ï¼ ï¼ ï¼ #8 0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00, +ï¼ ï¼ ï¼ address@hidden) at migration/colo..c:215 +ï¼ ï¼ ï¼ #9 0x00007f3e0327250d in colo_wait_handle_message (errp=0x7f3d62bfaa48, +ï¼ ï¼ ï¼ checkpoint_request=ï¼synthetic pointerï¼, f=ï¼optimized outï¼) at +ï¼ ï¼ ï¼ migration/colo.c:546 +ï¼ ï¼ ï¼ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at +ï¼ ï¼ ï¼ migration/colo.c:649 +ï¼ ï¼ ï¼ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ ï¼ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc.so.6 +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ -- +ï¼ ï¼ ï¼ View this message in context: +http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html +ï¼ ï¼ ï¼ Sent from the Developer mailing list archive at Nabble.com. +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ -- +ï¼ ï¼ Thanks +ï¼ ï¼ Zhang Chen +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ +ï¼ ï¼ +ï¼ + +diff --git a/migration/socket.c b/migration/socket.c + + +index 13966f1..d65a0ea 100644 + + +--- a/migration/socket.c + + ++++ b/migration/socket.c + + +@@ -147,8 +147,9 @@ static gboolean socket_accept_incoming_migration(QIOChannel +*ioc, + + + } + + + + + + trace_migration_socket_incoming_accepted() + + + + + + qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming") + + ++ qio_channel_set_feature(QIO_CHANNEL(sioc), QIO_CHANNEL_FEATURE_SHUTDOWN) + + + migration_channel_process_incoming(migrate_get_current(), + + + QIO_CHANNEL(sioc)) + + + object_unref(OBJECT(sioc)) + + + + +Is this patch ok? + +I have test it . The test could not hang any more. + + + + + + + + + + + + +åå§é®ä»¶ + + + +åä»¶äººï¼ address@hidden +æ¶ä»¶äººï¼ address@hidden address@hidden +æéäººï¼ address@hidden address@hidden address@hidden +æ¥ æ ï¼2017å¹´03æ22æ¥ 09:11 +主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: [BUG]COLO failover hang + + + + + +On 2017/3/21 19:56, Dr. David Alan Gilbert wrote: +ï¼ * Hailiang Zhang (address@hidden) wrote: +ï¼ï¼ Hi, +ï¼ï¼ +ï¼ï¼ Thanks for reporting this, and i confirmed it in my test, and it is a bug. +ï¼ï¼ +ï¼ï¼ Though we tried to call qemu_file_shutdown() to shutdown the related fd, in +ï¼ï¼ case COLO thread/incoming thread is stuck in read/write() while do failover, +ï¼ï¼ but it didn't take effect, because all the fd used by COLO (also migration) +ï¼ï¼ has been wrapped by qio channel, and it will not call the shutdown API if +ï¼ï¼ we didn't qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN). +ï¼ï¼ +ï¼ï¼ Cc: Dr. David Alan Gilbert address@hidden +ï¼ï¼ +ï¼ï¼ I doubted migration cancel has the same problem, it may be stuck in write() +ï¼ï¼ if we tried to cancel migration. +ï¼ï¼ +ï¼ï¼ void fd_start_outgoing_migration(MigrationState *s, const char *fdname, +Error **errp) +ï¼ï¼ { +ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(ioc), "migration-fd-outgoing") +ï¼ï¼ migration_channel_connect(s, ioc, NULL) +ï¼ï¼ ... ... +ï¼ï¼ We didn't call qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) above, +ï¼ï¼ and the +ï¼ï¼ migrate_fd_cancel() +ï¼ï¼ { +ï¼ï¼ ... ... +ï¼ï¼ if (s-ï¼state == MIGRATION_STATUS_CANCELLING && f) { +ï¼ï¼ qemu_file_shutdown(f) --ï¼ This will not take effect. No ? +ï¼ï¼ } +ï¼ï¼ } +ï¼ +ï¼ (cc'd in Daniel Berrange). +ï¼ I see that we call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN) +at the +ï¼ top of qio_channel_socket_new so I think that's safe isn't it? +ï¼ + +Hmm, you are right, this problem is only exist for the migration incoming fd, +thanks. + +ï¼ Dave +ï¼ +ï¼ï¼ Thanks, +ï¼ï¼ Hailiang +ï¼ï¼ +ï¼ï¼ On 2017/3/21 16:10, address@hidden wrote: +ï¼ï¼ï¼ Thank youã +ï¼ï¼ï¼ +ï¼ï¼ï¼ I have test areadyã +ï¼ï¼ï¼ +ï¼ï¼ï¼ When the Primary Node panic,the Secondary Node qemu hang at the same placeã +ï¼ï¼ï¼ +ï¼ï¼ï¼ Incorrding +http://wiki.qemu-project.org/Features/COLO +ï¼kill Primary Node +qemu will not produce the problem,but Primary Node panic canã +ï¼ï¼ï¼ +ï¼ï¼ï¼ I think due to the feature of channel does not support +QIO_CHANNEL_FEATURE_SHUTDOWN. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ when failover,channel_shutdown could not shut down the channel. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ so the colo_process_incoming_thread will hang at recvmsg. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ I test a patch: +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ index 13966f1..d65a0ea 100644 +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ --- a/migration/socket.c +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +++ b/migration/socket.c +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ } +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ trace_migration_socket_incoming_accepted() +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming") +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ QIO_CHANNEL(sioc)) +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ object_unref(OBJECT(sioc)) +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ My test will not hang any more. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ åå§é®ä»¶ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ åä»¶äººï¼ address@hidden +ï¼ï¼ï¼ æ¶ä»¶äººï¼ç广10165992 address@hidden +ï¼ï¼ï¼ æéäººï¼ address@hidden address@hidden +ï¼ï¼ï¼ æ¥ æ ï¼2017å¹´03æ21æ¥ 15:58 +ï¼ï¼ï¼ 主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: [BUG]COLO failover hang +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ Hi,Wang. +ï¼ï¼ï¼ +ï¼ï¼ï¼ You can test this branch: +ï¼ï¼ï¼ +ï¼ï¼ï¼ +https://github.com/coloft/qemu/tree/colo-v5.1-developing-COLO-frame-v21-with-shared-disk +ï¼ï¼ï¼ +ï¼ï¼ï¼ and please follow wiki ensure your own configuration correctly. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +http://wiki.qemu-project.org/Features/COLO +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ Thanks +ï¼ï¼ï¼ +ï¼ï¼ï¼ Zhang Chen +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ On 03/21/2017 03:27 PM, address@hidden wrote: +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ hi. +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ I test the git qemu master have the same problem. +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, +ï¼ï¼ï¼ ï¼ niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #1 0x00007f658e4aa0c2 in qio_channel_read +ï¼ï¼ï¼ ï¼ (address@hidden, address@hidden "", +ï¼ï¼ï¼ ï¼ address@hidden, address@hidden) at io/channel.c:114 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #2 0x00007f658e3ea990 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ï¼ï¼ ï¼ buf=0x7f65907cb838 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ï¼ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #3 0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at +ï¼ï¼ï¼ ï¼ migration/qemu-file.c:295 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #4 0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, +ï¼ï¼ï¼ ï¼ address@hidden) at migration/qemu-file.c:555 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #5 0x00007f658e3ea34b in qemu_get_byte (address@hidden) at +ï¼ï¼ï¼ ï¼ migration/qemu-file.c:568 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #6 0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at +ï¼ï¼ï¼ ï¼ migration/qemu-file.c:648 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #7 0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, +ï¼ï¼ï¼ ï¼ address@hidden) at migration/colo.c:244 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #8 0x00007f658e3e681e in colo_receive_check_message (f=ï¼optimized +ï¼ï¼ï¼ ï¼ outï¼, address@hidden, +ï¼ï¼ï¼ ï¼ address@hidden) +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ at migration/colo.c:264 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #9 0x00007f658e3e740e in colo_process_incoming_thread +ï¼ï¼ï¼ ï¼ (opaque=0x7f658eb30360 ï¼mis_current.31286ï¼) at migration/colo.c:577 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #11 0x00007f65881983ed in clone () from /lib64/libc.so.6 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ $2 = 0x7f658ff7d5c0 "migration-socket-incoming" +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features Do not support QIO_CHANNEL_FEATURE_SHUTDOWN +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ $3 = 0 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #0 socket_accept_incoming_migration (ioc=0x7fdcceeafa90, +ï¼ï¼ï¼ ï¼ condition=G_IO_IN, opaque=0x7fdcceeafa90) at migration/socket.c:137 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #1 0x00007fdcc6966350 in g_main_dispatch (context=ï¼optimized outï¼) at +ï¼ï¼ï¼ ï¼ gmain.c:3054 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #2 g_main_context_dispatch (context=ï¼optimized outï¼, +ï¼ï¼ï¼ ï¼ address@hidden) at gmain.c:3630 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #3 0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #4 os_host_main_loop_wait (timeout=ï¼optimized outï¼) at +ï¼ï¼ï¼ ï¼ util/main-loop.c:258 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #5 main_loop_wait (address@hidden) at +ï¼ï¼ï¼ ï¼ util/main-loop.c:506 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #6 0x00007fdccb526187 in main_loop () at vl.c:1898 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #7 main (argc=ï¼optimized outï¼, argv=ï¼optimized outï¼, envp=ï¼optimized +ï¼ï¼ï¼ ï¼ outï¼) at vl.c:4709 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ $1 = 6 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ $2 = 0x7fdcce1b1ab0 "migration-socket-listener" +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ May be socket_accept_incoming_migration should +ï¼ï¼ï¼ ï¼ call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)?? +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ thank you. +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ åå§é®ä»¶ +ï¼ï¼ï¼ ï¼ address@hidden +ï¼ï¼ï¼ ï¼ address@hidden +ï¼ï¼ï¼ ï¼ address@hidden@huawei.comï¼ +ï¼ï¼ï¼ ï¼ *æ¥ æ ï¼*2017å¹´03æ16æ¥ 14:46 +ï¼ï¼ï¼ ï¼ *主 é¢ ï¼**Re: [Qemu-devel] COLO failover hang* +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ On 03/15/2017 05:06 PM, wangguang wrote: +ï¼ï¼ï¼ ï¼ ï¼ am testing QEMU COLO feature described here [QEMU +ï¼ï¼ï¼ ï¼ ï¼ Wiki]( +http://wiki.qemu-project.org/Features/COLO +). +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ When the Primary Node panic,the Secondary Node qemu hang. +ï¼ï¼ï¼ ï¼ ï¼ hang at recvmsg in qio_channel_socket_readv. +ï¼ï¼ï¼ ï¼ ï¼ And I run { 'execute': 'nbd-server-stop' } and { "execute": +ï¼ï¼ï¼ ï¼ ï¼ "x-colo-lost-heartbeat" } in Secondary VM's +ï¼ï¼ï¼ ï¼ ï¼ monitor,the Secondary Node qemu still hang at recvmsg . +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ I found that the colo in qemu is not complete yet. +ï¼ï¼ï¼ ï¼ ï¼ Do the colo have any plan for development? +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ Yes, We are developing. You can see some of patch we pushing. +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ Has anyone ever run it successfully? Any help is appreciated! +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ In our internal version can run it successfully, +ï¼ï¼ï¼ ï¼ The failover detail you can ask Zhanghailiang for help. +ï¼ï¼ï¼ ï¼ Next time if you have some question about COLO, +ï¼ï¼ï¼ ï¼ please cc me and zhanghailiang address@hidden +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ Thanks +ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ centos7.2+qemu2.7.50 +ï¼ï¼ï¼ ï¼ ï¼ (gdb) bt +ï¼ï¼ï¼ ï¼ ï¼ #0 0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0 +ï¼ï¼ï¼ ï¼ ï¼ #1 0x00007f3e0332b738 in qio_channel_socket_readv (ioc=ï¼optimized outï¼, +ï¼ï¼ï¼ ï¼ ï¼ iov=ï¼optimized outï¼, niov=ï¼optimized outï¼, fds=0x0, nfds=0x0, errp=0x0) +at +ï¼ï¼ï¼ ï¼ ï¼ io/channel-socket.c:497 +ï¼ï¼ï¼ ï¼ ï¼ #2 0x00007f3e03329472 in qio_channel_read (address@hidden, +ï¼ï¼ï¼ ï¼ ï¼ address@hidden "", address@hidden, +ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at io/channel.c:97 +ï¼ï¼ï¼ ï¼ ï¼ #3 0x00007f3e032750e0 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ï¼ï¼ ï¼ ï¼ buf=0x7f3e05910f38 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ï¼ï¼ ï¼ ï¼ #4 0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at +ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:257 +ï¼ï¼ï¼ ï¼ ï¼ #5 0x00007f3e03274a41 in qemu_peek_byte (address@hidden, +ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/qemu-file.c:510 +ï¼ï¼ï¼ ï¼ ï¼ #6 0x00007f3e03274aab in qemu_get_byte (address@hidden) at +ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:523 +ï¼ï¼ï¼ ï¼ ï¼ #7 0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at +ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:603 +ï¼ï¼ï¼ ï¼ ï¼ #8 0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00, +ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/colo.c:215 +ï¼ï¼ï¼ ï¼ ï¼ #9 0x00007f3e0327250d in colo_wait_handle_message (errp=0x7f3d62bfaa48, +ï¼ï¼ï¼ ï¼ ï¼ checkpoint_request=ï¼synthetic pointerï¼, f=ï¼optimized outï¼) at +ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:546 +ï¼ï¼ï¼ ï¼ ï¼ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at +ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:649 +ï¼ï¼ï¼ ï¼ ï¼ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ï¼ï¼ ï¼ ï¼ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc..so.6 +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ -- +ï¼ï¼ï¼ ï¼ ï¼ View this message in context: +http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html +ï¼ï¼ï¼ ï¼ ï¼ Sent from the Developer mailing list archive at Nabble.com. +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ -- +ï¼ï¼ï¼ ï¼ Thanks +ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ +ï¼ï¼ +ï¼ -- +ï¼ Dr. David Alan Gilbert / address@hidden / Manchester, UK +ï¼ +ï¼ . +ï¼ + +Hi, + +On 2017/3/22 9:42, address@hidden wrote: +diff --git a/migration/socket.c b/migration/socket.c + + +index 13966f1..d65a0ea 100644 + + +--- a/migration/socket.c + + ++++ b/migration/socket.c + + +@@ -147,8 +147,9 @@ static gboolean socket_accept_incoming_migration(QIOChannel +*ioc, + + + } + + + + + + trace_migration_socket_incoming_accepted() + + + + + + qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming") + + ++ qio_channel_set_feature(QIO_CHANNEL(sioc), QIO_CHANNEL_FEATURE_SHUTDOWN) + + + migration_channel_process_incoming(migrate_get_current(), + + + QIO_CHANNEL(sioc)) + + + object_unref(OBJECT(sioc)) + + + + +Is this patch ok? +Yes, i think this works, but a better way maybe to call +qio_channel_set_feature() +in qio_channel_socket_accept(), we didn't set the SHUTDOWN feature for the +socket accept fd, +Or fix it by this: + +diff --git a/io/channel-socket.c b/io/channel-socket.c +index f546c68..ce6894c 100644 +--- a/io/channel-socket.c ++++ b/io/channel-socket.c +@@ -330,9 +330,8 @@ qio_channel_socket_accept(QIOChannelSocket *ioc, + Error **errp) + { + QIOChannelSocket *cioc; +- +- cioc = QIO_CHANNEL_SOCKET(object_new(TYPE_QIO_CHANNEL_SOCKET)); +- cioc->fd = -1; ++ ++ cioc = qio_channel_socket_new(); + cioc->remoteAddrLen = sizeof(ioc->remoteAddr); + cioc->localAddrLen = sizeof(ioc->localAddr); + + +Thanks, +Hailiang +I have test it . The test could not hang any more. + + + + + + + + + + + + +åå§é®ä»¶ + + + +åä»¶äººï¼ address@hidden +æ¶ä»¶äººï¼ address@hidden address@hidden +æéäººï¼ address@hidden address@hidden address@hidden +æ¥ æ ï¼2017å¹´03æ22æ¥ 09:11 +主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: [BUG]COLO failover hang + + + + + +On 2017/3/21 19:56, Dr. David Alan Gilbert wrote: +ï¼ * Hailiang Zhang (address@hidden) wrote: +ï¼ï¼ Hi, +ï¼ï¼ +ï¼ï¼ Thanks for reporting this, and i confirmed it in my test, and it is a bug. +ï¼ï¼ +ï¼ï¼ Though we tried to call qemu_file_shutdown() to shutdown the related fd, in +ï¼ï¼ case COLO thread/incoming thread is stuck in read/write() while do failover, +ï¼ï¼ but it didn't take effect, because all the fd used by COLO (also migration) +ï¼ï¼ has been wrapped by qio channel, and it will not call the shutdown API if +ï¼ï¼ we didn't qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN). +ï¼ï¼ +ï¼ï¼ Cc: Dr. David Alan Gilbert address@hidden +ï¼ï¼ +ï¼ï¼ I doubted migration cancel has the same problem, it may be stuck in write() +ï¼ï¼ if we tried to cancel migration. +ï¼ï¼ +ï¼ï¼ void fd_start_outgoing_migration(MigrationState *s, const char *fdname, +Error **errp) +ï¼ï¼ { +ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(ioc), "migration-fd-outgoing") +ï¼ï¼ migration_channel_connect(s, ioc, NULL) +ï¼ï¼ ... ... +ï¼ï¼ We didn't call qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) above, +ï¼ï¼ and the +ï¼ï¼ migrate_fd_cancel() +ï¼ï¼ { +ï¼ï¼ ... ... +ï¼ï¼ if (s-ï¼state == MIGRATION_STATUS_CANCELLING && f) { +ï¼ï¼ qemu_file_shutdown(f) --ï¼ This will not take effect. No ? +ï¼ï¼ } +ï¼ï¼ } +ï¼ +ï¼ (cc'd in Daniel Berrange). +ï¼ I see that we call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN) +at the +ï¼ top of qio_channel_socket_new so I think that's safe isn't it? +ï¼ + +Hmm, you are right, this problem is only exist for the migration incoming fd, +thanks. + +ï¼ Dave +ï¼ +ï¼ï¼ Thanks, +ï¼ï¼ Hailiang +ï¼ï¼ +ï¼ï¼ On 2017/3/21 16:10, address@hidden wrote: +ï¼ï¼ï¼ Thank youã +ï¼ï¼ï¼ +ï¼ï¼ï¼ I have test areadyã +ï¼ï¼ï¼ +ï¼ï¼ï¼ When the Primary Node panic,the Secondary Node qemu hang at the same placeã +ï¼ï¼ï¼ +ï¼ï¼ï¼ Incorrding +http://wiki.qemu-project.org/Features/COLO +ï¼kill Primary Node +qemu will not produce the problem,but Primary Node panic canã +ï¼ï¼ï¼ +ï¼ï¼ï¼ I think due to the feature of channel does not support +QIO_CHANNEL_FEATURE_SHUTDOWN. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ when failover,channel_shutdown could not shut down the channel. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ so the colo_process_incoming_thread will hang at recvmsg. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ I test a patch: +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ index 13966f1..d65a0ea 100644 +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ --- a/migration/socket.c +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +++ b/migration/socket.c +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ } +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ trace_migration_socket_incoming_accepted() +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming") +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ QIO_CHANNEL(sioc)) +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ object_unref(OBJECT(sioc)) +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ My test will not hang any more. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ åå§é®ä»¶ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ åä»¶äººï¼ address@hidden +ï¼ï¼ï¼ æ¶ä»¶äººï¼ç广10165992 address@hidden +ï¼ï¼ï¼ æéäººï¼ address@hidden address@hidden +ï¼ï¼ï¼ æ¥ æ ï¼2017å¹´03æ21æ¥ 15:58 +ï¼ï¼ï¼ 主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: [BUG]COLO failover hang +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ Hi,Wang. +ï¼ï¼ï¼ +ï¼ï¼ï¼ You can test this branch: +ï¼ï¼ï¼ +ï¼ï¼ï¼ +https://github.com/coloft/qemu/tree/colo-v5.1-developing-COLO-frame-v21-with-shared-disk +ï¼ï¼ï¼ +ï¼ï¼ï¼ and please follow wiki ensure your own configuration correctly. +ï¼ï¼ï¼ +ï¼ï¼ï¼ +http://wiki.qemu-project.org/Features/COLO +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ Thanks +ï¼ï¼ï¼ +ï¼ï¼ï¼ Zhang Chen +ï¼ï¼ï¼ +ï¼ï¼ï¼ +ï¼ï¼ï¼ On 03/21/2017 03:27 PM, address@hidden wrote: +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ hi. +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ I test the git qemu master have the same problem. +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, +ï¼ï¼ï¼ ï¼ niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #1 0x00007f658e4aa0c2 in qio_channel_read +ï¼ï¼ï¼ ï¼ (address@hidden, address@hidden "", +ï¼ï¼ï¼ ï¼ address@hidden, address@hidden) at io/channel.c:114 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #2 0x00007f658e3ea990 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ï¼ï¼ ï¼ buf=0x7f65907cb838 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ï¼ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #3 0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at +ï¼ï¼ï¼ ï¼ migration/qemu-file.c:295 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #4 0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, +ï¼ï¼ï¼ ï¼ address@hidden) at migration/qemu-file.c:555 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #5 0x00007f658e3ea34b in qemu_get_byte (address@hidden) at +ï¼ï¼ï¼ ï¼ migration/qemu-file.c:568 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #6 0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at +ï¼ï¼ï¼ ï¼ migration/qemu-file.c:648 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #7 0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, +ï¼ï¼ï¼ ï¼ address@hidden) at migration/colo.c:244 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #8 0x00007f658e3e681e in colo_receive_check_message (f=ï¼optimized +ï¼ï¼ï¼ ï¼ outï¼, address@hidden, +ï¼ï¼ï¼ ï¼ address@hidden) +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ at migration/colo.c:264 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #9 0x00007f658e3e740e in colo_process_incoming_thread +ï¼ï¼ï¼ ï¼ (opaque=0x7f658eb30360 ï¼mis_current.31286ï¼) at migration/colo.c:577 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #11 0x00007f65881983ed in clone () from /lib64/libc.so.6 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ $2 = 0x7f658ff7d5c0 "migration-socket-incoming" +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features Do not support QIO_CHANNEL_FEATURE_SHUTDOWN +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ $3 = 0 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #0 socket_accept_incoming_migration (ioc=0x7fdcceeafa90, +ï¼ï¼ï¼ ï¼ condition=G_IO_IN, opaque=0x7fdcceeafa90) at migration/socket.c:137 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #1 0x00007fdcc6966350 in g_main_dispatch (context=ï¼optimized outï¼) at +ï¼ï¼ï¼ ï¼ gmain.c:3054 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #2 g_main_context_dispatch (context=ï¼optimized outï¼, +ï¼ï¼ï¼ ï¼ address@hidden) at gmain.c:3630 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #3 0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #4 os_host_main_loop_wait (timeout=ï¼optimized outï¼) at +ï¼ï¼ï¼ ï¼ util/main-loop.c:258 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #5 main_loop_wait (address@hidden) at +ï¼ï¼ï¼ ï¼ util/main-loop.c:506 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #6 0x00007fdccb526187 in main_loop () at vl.c:1898 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ #7 main (argc=ï¼optimized outï¼, argv=ï¼optimized outï¼, envp=ï¼optimized +ï¼ï¼ï¼ ï¼ outï¼) at vl.c:4709 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ $1 = 6 +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ $2 = 0x7fdcce1b1ab0 "migration-socket-listener" +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ May be socket_accept_incoming_migration should +ï¼ï¼ï¼ ï¼ call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)?? +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ thank you. +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ åå§é®ä»¶ +ï¼ï¼ï¼ ï¼ address@hidden +ï¼ï¼ï¼ ï¼ address@hidden +ï¼ï¼ï¼ ï¼ address@hidden@huawei.comï¼ +ï¼ï¼ï¼ ï¼ *æ¥ æ ï¼*2017å¹´03æ16æ¥ 14:46 +ï¼ï¼ï¼ ï¼ *主 é¢ ï¼**Re: [Qemu-devel] COLO failover hang* +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ On 03/15/2017 05:06 PM, wangguang wrote: +ï¼ï¼ï¼ ï¼ ï¼ am testing QEMU COLO feature described here [QEMU +ï¼ï¼ï¼ ï¼ ï¼ Wiki]( +http://wiki.qemu-project.org/Features/COLO +). +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ When the Primary Node panic,the Secondary Node qemu hang. +ï¼ï¼ï¼ ï¼ ï¼ hang at recvmsg in qio_channel_socket_readv. +ï¼ï¼ï¼ ï¼ ï¼ And I run { 'execute': 'nbd-server-stop' } and { "execute": +ï¼ï¼ï¼ ï¼ ï¼ "x-colo-lost-heartbeat" } in Secondary VM's +ï¼ï¼ï¼ ï¼ ï¼ monitor,the Secondary Node qemu still hang at recvmsg . +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ I found that the colo in qemu is not complete yet. +ï¼ï¼ï¼ ï¼ ï¼ Do the colo have any plan for development? +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ Yes, We are developing. You can see some of patch we pushing. +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ Has anyone ever run it successfully? Any help is appreciated! +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ In our internal version can run it successfully, +ï¼ï¼ï¼ ï¼ The failover detail you can ask Zhanghailiang for help. +ï¼ï¼ï¼ ï¼ Next time if you have some question about COLO, +ï¼ï¼ï¼ ï¼ please cc me and zhanghailiang address@hidden +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ Thanks +ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ centos7.2+qemu2.7.50 +ï¼ï¼ï¼ ï¼ ï¼ (gdb) bt +ï¼ï¼ï¼ ï¼ ï¼ #0 0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0 +ï¼ï¼ï¼ ï¼ ï¼ #1 0x00007f3e0332b738 in qio_channel_socket_readv (ioc=ï¼optimized outï¼, +ï¼ï¼ï¼ ï¼ ï¼ iov=ï¼optimized outï¼, niov=ï¼optimized outï¼, fds=0x0, nfds=0x0, errp=0x0) +at +ï¼ï¼ï¼ ï¼ ï¼ io/channel-socket.c:497 +ï¼ï¼ï¼ ï¼ ï¼ #2 0x00007f3e03329472 in qio_channel_read (address@hidden, +ï¼ï¼ï¼ ï¼ ï¼ address@hidden "", address@hidden, +ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at io/channel.c:97 +ï¼ï¼ï¼ ï¼ ï¼ #3 0x00007f3e032750e0 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ï¼ï¼ ï¼ ï¼ buf=0x7f3e05910f38 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ï¼ï¼ ï¼ ï¼ #4 0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at +ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:257 +ï¼ï¼ï¼ ï¼ ï¼ #5 0x00007f3e03274a41 in qemu_peek_byte (address@hidden, +ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/qemu-file.c:510 +ï¼ï¼ï¼ ï¼ ï¼ #6 0x00007f3e03274aab in qemu_get_byte (address@hidden) at +ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:523 +ï¼ï¼ï¼ ï¼ ï¼ #7 0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at +ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:603 +ï¼ï¼ï¼ ï¼ ï¼ #8 0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00, +ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/colo.c:215 +ï¼ï¼ï¼ ï¼ ï¼ #9 0x00007f3e0327250d in colo_wait_handle_message (errp=0x7f3d62bfaa48, +ï¼ï¼ï¼ ï¼ ï¼ checkpoint_request=ï¼synthetic pointerï¼, f=ï¼optimized outï¼) at +ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:546 +ï¼ï¼ï¼ ï¼ ï¼ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at +ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:649 +ï¼ï¼ï¼ ï¼ ï¼ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ï¼ï¼ ï¼ ï¼ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc..so.6 +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ -- +ï¼ï¼ï¼ ï¼ ï¼ View this message in context: +http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html +ï¼ï¼ï¼ ï¼ ï¼ Sent from the Developer mailing list archive at Nabble.com. +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ -- +ï¼ï¼ï¼ ï¼ Thanks +ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ ï¼ +ï¼ï¼ï¼ +ï¼ï¼ +ï¼ -- +ï¼ Dr. David Alan Gilbert / address@hidden / Manchester, UK +ï¼ +ï¼ . +ï¼ + diff --git a/results/classifier/118/unknown/592 b/results/classifier/118/unknown/592 new file mode 100644 index 00000000..ad00ba09 --- /dev/null +++ b/results/classifier/118/unknown/592 @@ -0,0 +1,138 @@ +ppc: 0.884 +vnc: 0.884 +TCG: 0.880 +graphic: 0.879 +i386: 0.873 +VMM: 0.872 +KVM: 0.871 +peripherals: 0.861 +permissions: 0.857 +performance: 0.842 +boot: 0.839 +x86: 0.839 +register: 0.817 +architecture: 0.807 +semantic: 0.806 +files: 0.804 +user-level: 0.803 +assembly: 0.801 +device: 0.794 +debug: 0.780 +arm: 0.779 +virtual: 0.779 +hypervisor: 0.769 +PID: 0.743 +socket: 0.729 +kernel: 0.729 +risc-v: 0.720 +network: 0.703 +mistranslation: 0.695 + +CloudLinux / CageFS - guest-fsfreeze hangs system +Description of problem: +Since CloudLinux provides CageFS (virtualized file system), each time guest-fsfreeze for Proxmox backup, the system is hangs up and become unavailable. It's caused by cagefs-skeleton mount points: + +``` +sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) +proc on /proc type proc (rw,nosuid,nodev,noexec,relatime,gid=1002,hidepid=2) +devtmpfs on /dev type devtmpfs (rw,nosuid,size=3993656k,nr_inodes=998414,mode=755) +securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) +tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) +devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) +tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) +tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) +cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) +pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) +configfs on /sys/kernel/config type configfs (rw,relatime) +/dev/sda2 on / type ext4 (rw,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=34,pipe_ino=10005,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10005) +mqueue on /dev/mqueue type mqueue (rw,relatime) +hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) +debugfs on /sys/kernel/debug type debugfs (rw,relatime) +fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) +/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered) +/usr/tmpDSK on /tmp type ext4 (rw,nosuid,noexec,relatime,discard,data=ordered) +/usr/tmpDSK on /var/tmp type ext4 (rw,nosuid,noexec,relatime,discard,data=ordered) +cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer) +cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices) +cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,relatime,cpuacct,cpu) +cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset) +cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory) +/dev/sda2 on /usr/share/cagefs-skeleton type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +devpts on /usr/share/cagefs-skeleton/dev/pts type devpts (rw,nosuid,relatime,gid=5,mode=620,ptmxmode=000) +/dev/sda2 on /usr/share/cagefs-skeleton/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/include type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/apache/domlogs type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/lib64 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/perl type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/php type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/3rdparty/share type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/Cpanel type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/Whostmgr type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/base type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/cgi-priv type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/cpaddons type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/hooks type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/htdocs type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/img-sys type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/install type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/lang type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/lib type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/libexec type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/locale type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/php type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/scripts type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/share type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/shared type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/sys_cpanel/boxtrapper-message type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/var type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/whostmgr type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/local/cpanel/whostmgr/docroot/cgi/softaculous type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.nodejs type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/l.v.e-manager/cl.python type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/locale type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/man type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/terminfo type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/vim type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/usr/share/zoneinfo type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/cpanel/ea4 type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/mysql type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/proxyexec/cagefs.sock type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lib/spamassassin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +tmpfs on /usr/share/cagefs-skeleton/run/dbus type tmpfs (rw,nosuid,mode=755) +tmpfs on /usr/share/cagefs-skeleton/run/nscd type tmpfs (rw,nosuid,mode=755) +/dev/sda2 on /usr/share/cagefs-skeleton/var/softaculous type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/spool/at type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/www/cgi-bin type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/www/html type ext4 (rw,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/suphp/sbin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php73/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php73/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php74/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php74/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php80/root/usr/bin type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/opt/cpanel/ea-php80/root/etc type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +/dev/sda2 on /usr/share/cagefs-skeleton/var/lve/lveinfo.ver.cagefs type ext4 (ro,nosuid,relatime,data=ordered,jqfmt=vfsv1,usrjquota=quota.user) +proc on /usr/share/cagefs-skeleton/proc type proc (rw,nosuid,relatime,gid=1002,hidepid=2) +systemd-1 on /usr/share/cagefs-skeleton/proc/sys/fs/binfmt_misc type autofs (rw,nosuid,relatime,fd=34,pipe_ino=10005,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10005) +tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=800880k,mode=700) +``` + +Is there anyway qemu-guest-agent can handle this? I saw a lot of users faced this problem since CloudLinux becomes more popular after RHEL halted future CentOS releases. + +CloudLinux has an option to umount/mount cagefs-skeleton, maybe it's something can be implemented - https://docs.cloudlinux.com/command-line_tools/ + +The same issue happens when JailShell is enabled on cPanel servers (OVH reported about) - https://docs.ovh.com/ca/en/vps/cpanel_auto_backup/ + +Thank you for your time. +Steps to reproduce: +1. Manually start backup for the VM with qemu-agent enabled. +2. The backup process stuck at "INFO: issuing guest-agent 'fs-freeze' command" +3. The VM become unavailable, you can only unlock it and force reset. diff --git a/results/classifier/118/unknown/70294255 b/results/classifier/118/unknown/70294255 new file mode 100644 index 00000000..f35af887 --- /dev/null +++ b/results/classifier/118/unknown/70294255 @@ -0,0 +1,1086 @@ +risc-v: 0.863 +mistranslation: 0.862 +assembly: 0.861 +PID: 0.859 +semantic: 0.858 +socket: 0.858 +device: 0.857 +user-level: 0.857 +graphic: 0.857 +arm: 0.856 +debug: 0.854 +permissions: 0.854 +architecture: 0.851 +performance: 0.850 +kernel: 0.848 +network: 0.846 +register: 0.842 +vnc: 0.837 +files: 0.832 +virtual: 0.832 +hypervisor: 0.828 +peripherals: 0.819 +boot: 0.811 +i386: 0.811 +KVM: 0.806 +x86: 0.803 +ppc: 0.800 +TCG: 0.792 +VMM: 0.784 + +[Qemu-devel] 答复: Re: 答复: Re: 答复: Re: 答复: Re: [BUG]COLO failover hang + +hi: + +yes.it is better. + +And should we delete + + + + +#ifdef WIN32 + + QIO_CHANNEL(cioc)-ï¼event = CreateEvent(NULL, FALSE, FALSE, NULL) + +#endif + + + + +in qio_channel_socket_acceptï¼ + +qio_channel_socket_new already have it. + + + + + + + + + + + + +åå§é®ä»¶ + + + +åä»¶äººï¼ address@hidden +æ¶ä»¶äººï¼ç广10165992 +æéäººï¼ address@hidden address@hidden address@hidden address@hidden +æ¥ æ ï¼2017å¹´03æ22æ¥ 15:03 +主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: çå¤: Re: [BUG]COLO failover hang + + + + + +Hi, + +On 2017/3/22 9:42, address@hidden wrote: +ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ +ï¼ +ï¼ index 13966f1..d65a0ea 100644 +ï¼ +ï¼ +ï¼ --- a/migration/socket.c +ï¼ +ï¼ +ï¼ +++ b/migration/socket.c +ï¼ +ï¼ +ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ +ï¼ +ï¼ } +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ trace_migration_socket_incoming_accepted() +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming") +ï¼ +ï¼ +ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ +ï¼ +ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ +ï¼ +ï¼ QIO_CHANNEL(sioc)) +ï¼ +ï¼ +ï¼ object_unref(OBJECT(sioc)) +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ Is this patch ok? +ï¼ + +Yes, i think this works, but a better way maybe to call +qio_channel_set_feature() +in qio_channel_socket_accept(), we didn't set the SHUTDOWN feature for the +socket accept fd, +Or fix it by this: + +diff --git a/io/channel-socket.c b/io/channel-socket.c +index f546c68..ce6894c 100644 +--- a/io/channel-socket.c ++++ b/io/channel-socket.c +@@ -330,9 +330,8 @@ qio_channel_socket_accept(QIOChannelSocket *ioc, + Error **errp) + { + QIOChannelSocket *cioc +- +- cioc = QIO_CHANNEL_SOCKET(object_new(TYPE_QIO_CHANNEL_SOCKET)) +- cioc-ï¼fd = -1 ++ ++ cioc = qio_channel_socket_new() + cioc-ï¼remoteAddrLen = sizeof(ioc-ï¼remoteAddr) + cioc-ï¼localAddrLen = sizeof(ioc-ï¼localAddr) + + +Thanks, +Hailiang + +ï¼ I have test it . The test could not hang any more. +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ åå§é®ä»¶ +ï¼ +ï¼ +ï¼ +ï¼ åä»¶äººï¼ address@hidden +ï¼ æ¶ä»¶äººï¼ address@hidden address@hidden +ï¼ æéäººï¼ address@hidden address@hidden address@hidden +ï¼ æ¥ æ ï¼2017å¹´03æ22æ¥ 09:11 +ï¼ ä¸» é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: [BUG]COLO failover hang +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ On 2017/3/21 19:56, Dr. David Alan Gilbert wrote: +ï¼ ï¼ * Hailiang Zhang (address@hidden) wrote: +ï¼ ï¼ï¼ Hi, +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Thanks for reporting this, and i confirmed it in my test, and it is a bug. +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Though we tried to call qemu_file_shutdown() to shutdown the related fd, in +ï¼ ï¼ï¼ case COLO thread/incoming thread is stuck in read/write() while do +failover, +ï¼ ï¼ï¼ but it didn't take effect, because all the fd used by COLO (also migration) +ï¼ ï¼ï¼ has been wrapped by qio channel, and it will not call the shutdown API if +ï¼ ï¼ï¼ we didn't qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN). +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Cc: Dr. David Alan Gilbert address@hidden +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ I doubted migration cancel has the same problem, it may be stuck in write() +ï¼ ï¼ï¼ if we tried to cancel migration. +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ void fd_start_outgoing_migration(MigrationState *s, const char *fdname, +Error **errp) +ï¼ ï¼ï¼ { +ï¼ ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(ioc), "migration-fd-outgoing") +ï¼ ï¼ï¼ migration_channel_connect(s, ioc, NULL) +ï¼ ï¼ï¼ ... ... +ï¼ ï¼ï¼ We didn't call qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) above, +ï¼ ï¼ï¼ and the +ï¼ ï¼ï¼ migrate_fd_cancel() +ï¼ ï¼ï¼ { +ï¼ ï¼ï¼ ... ... +ï¼ ï¼ï¼ if (s-ï¼state == MIGRATION_STATUS_CANCELLING && f) { +ï¼ ï¼ï¼ qemu_file_shutdown(f) --ï¼ This will not take effect. No ? +ï¼ ï¼ï¼ } +ï¼ ï¼ï¼ } +ï¼ ï¼ +ï¼ ï¼ (cc'd in Daniel Berrange). +ï¼ ï¼ I see that we call qio_channel_set_feature(ioc, +QIO_CHANNEL_FEATURE_SHUTDOWN) at the +ï¼ ï¼ top of qio_channel_socket_new so I think that's safe isn't it? +ï¼ ï¼ +ï¼ +ï¼ Hmm, you are right, this problem is only exist for the migration incoming fd, +thanks. +ï¼ +ï¼ ï¼ Dave +ï¼ ï¼ +ï¼ ï¼ï¼ Thanks, +ï¼ ï¼ï¼ Hailiang +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ On 2017/3/21 16:10, address@hidden wrote: +ï¼ ï¼ï¼ï¼ Thank youã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I have test areadyã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ When the Primary Node panic,the Secondary Node qemu hang at the same +placeã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Incorrding +http://wiki.qemu-project.org/Features/COLO +ï¼kill Primary Node +qemu will not produce the problem,but Primary Node panic canã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I think due to the feature of channel does not support +QIO_CHANNEL_FEATURE_SHUTDOWN. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ when failover,channel_shutdown could not shut down the channel. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ so the colo_process_incoming_thread will hang at recvmsg. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I test a patch: +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ index 13966f1..d65a0ea 100644 +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ --- a/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +++ b/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ } +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ trace_migration_socket_incoming_accepted() +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), +"migration-socket-incoming") +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ QIO_CHANNEL(sioc)) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ object_unref(OBJECT(sioc)) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ My test will not hang any more. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ åå§é®ä»¶ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ åä»¶äººï¼ address@hidden +ï¼ ï¼ï¼ï¼ æ¶ä»¶äººï¼ç广10165992 address@hidden +ï¼ ï¼ï¼ï¼ æéäººï¼ address@hidden address@hidden +ï¼ ï¼ï¼ï¼ æ¥ æ ï¼2017å¹´03æ21æ¥ 15:58 +ï¼ ï¼ï¼ï¼ 主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: [BUG]COLO failover hang +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Hi,Wang. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ You can test this branch: +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +https://github.com/coloft/qemu/tree/colo-v5.1-developing-COLO-frame-v21-with-shared-disk +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ and please follow wiki ensure your own configuration correctly. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +http://wiki.qemu-project.org/Features/COLO +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Thanks +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ On 03/21/2017 03:27 PM, address@hidden wrote: +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ hi. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ I test the git qemu master have the same problem. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, +ï¼ ï¼ï¼ï¼ ï¼ niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #1 0x00007f658e4aa0c2 in qio_channel_read +ï¼ ï¼ï¼ï¼ ï¼ (address@hidden, address@hidden "", +ï¼ ï¼ï¼ï¼ ï¼ address@hidden, address@hidden) at io/channel.c:114 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #2 0x00007f658e3ea990 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ buf=0x7f65907cb838 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #3 0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:295 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #4 0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at migration/qemu-file.c:555 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #5 0x00007f658e3ea34b in qemu_get_byte (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:568 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #6 0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:648 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #7 0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at migration/colo.c:244 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #8 0x00007f658e3e681e in colo_receive_check_message (f=ï¼optimized +ï¼ ï¼ï¼ï¼ ï¼ outï¼, address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ at migration/colo.c:264 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #9 0x00007f658e3e740e in colo_process_incoming_thread +ï¼ ï¼ï¼ï¼ ï¼ (opaque=0x7f658eb30360 ï¼mis_current.31286ï¼) at migration/colo.c:577 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #11 0x00007f65881983ed in clone () from /lib64/libc.so.6 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $2 = 0x7f658ff7d5c0 "migration-socket-incoming" +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features Do not support QIO_CHANNEL_FEATURE_SHUTDOWN +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $3 = 0 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #0 socket_accept_incoming_migration (ioc=0x7fdcceeafa90, +ï¼ ï¼ï¼ï¼ ï¼ condition=G_IO_IN, opaque=0x7fdcceeafa90) at migration/socket.c:137 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #1 0x00007fdcc6966350 in g_main_dispatch (context=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ gmain.c:3054 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #2 g_main_context_dispatch (context=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at gmain.c:3630 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #3 0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #4 os_host_main_loop_wait (timeout=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ util/main-loop.c:258 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #5 main_loop_wait (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ util/main-loop.c:506 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #6 0x00007fdccb526187 in main_loop () at vl.c:1898 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #7 main (argc=ï¼optimized outï¼, argv=ï¼optimized outï¼, envp=ï¼optimized +ï¼ ï¼ï¼ï¼ ï¼ outï¼) at vl.c:4709 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $1 = 6 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $2 = 0x7fdcce1b1ab0 "migration-socket-listener" +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ May be socket_accept_incoming_migration should +ï¼ ï¼ï¼ï¼ ï¼ call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)?? +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ thank you. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ åå§é®ä»¶ +ï¼ ï¼ï¼ï¼ ï¼ address@hidden +ï¼ ï¼ï¼ï¼ ï¼ address@hidden +ï¼ ï¼ï¼ï¼ ï¼ address@hidden@huawei.comï¼ +ï¼ ï¼ï¼ï¼ ï¼ *æ¥ æ ï¼*2017å¹´03æ16æ¥ 14:46 +ï¼ ï¼ï¼ï¼ ï¼ *主 é¢ ï¼**Re: [Qemu-devel] COLO failover hang* +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ On 03/15/2017 05:06 PM, wangguang wrote: +ï¼ ï¼ï¼ï¼ ï¼ ï¼ am testing QEMU COLO feature described here [QEMU +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Wiki]( +http://wiki.qemu-project.org/Features/COLO +). +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ When the Primary Node panic,the Secondary Node qemu hang. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ hang at recvmsg in qio_channel_socket_readv. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ And I run { 'execute': 'nbd-server-stop' } and { "execute": +ï¼ ï¼ï¼ï¼ ï¼ ï¼ "x-colo-lost-heartbeat" } in Secondary VM's +ï¼ ï¼ï¼ï¼ ï¼ ï¼ monitor,the Secondary Node qemu still hang at recvmsg . +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ I found that the colo in qemu is not complete yet. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Do the colo have any plan for development? +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ Yes, We are developing. You can see some of patch we pushing. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Has anyone ever run it successfully? Any help is appreciated! +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ In our internal version can run it successfully, +ï¼ ï¼ï¼ï¼ ï¼ The failover detail you can ask Zhanghailiang for help. +ï¼ ï¼ï¼ï¼ ï¼ Next time if you have some question about COLO, +ï¼ ï¼ï¼ï¼ ï¼ please cc me and zhanghailiang address@hidden +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ Thanks +ï¼ ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ centos7.2+qemu2.7.50 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #0 0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #1 0x00007f3e0332b738 in qio_channel_socket_readv (ioc=ï¼optimized +outï¼, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ iov=ï¼optimized outï¼, niov=ï¼optimized outï¼, fds=0x0, nfds=0x0, +errp=0x0) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ io/channel-socket.c:497 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #2 0x00007f3e03329472 in qio_channel_read (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden "", address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at io/channel.c:97 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #3 0x00007f3e032750e0 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ buf=0x7f3e05910f38 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #4 0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:257 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #5 0x00007f3e03274a41 in qemu_peek_byte (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/qemu-file.c:510 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #6 0x00007f3e03274aab in qemu_get_byte (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:523 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #7 0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:603 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #8 0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/colo.c:215 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #9 0x00007f3e0327250d in colo_wait_handle_message +(errp=0x7f3d62bfaa48, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ checkpoint_request=ï¼synthetic pointerï¼, f=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:546 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:649 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc..so.6 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ -- +ï¼ ï¼ï¼ï¼ ï¼ ï¼ View this message in context: +http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Sent from the Developer mailing list archive at Nabble.com. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ -- +ï¼ ï¼ï¼ï¼ ï¼ Thanks +ï¼ ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ +ï¼ ï¼ -- +ï¼ ï¼ Dr. David Alan Gilbert / address@hidden / Manchester, UK +ï¼ ï¼ +ï¼ ï¼ . +ï¼ ï¼ +ï¼ + +On 2017/3/22 16:09, address@hidden wrote: +hi: + +yes.it is better. + +And should we delete +Yes, you are right. +#ifdef WIN32 + + QIO_CHANNEL(cioc)-ï¼event = CreateEvent(NULL, FALSE, FALSE, NULL) + +#endif + + + + +in qio_channel_socket_acceptï¼ + +qio_channel_socket_new already have it. + + + + + + + + + + + + +åå§é®ä»¶ + + + +åä»¶äººï¼ address@hidden +æ¶ä»¶äººï¼ç广10165992 +æéäººï¼ address@hidden address@hidden address@hidden address@hidden +æ¥ æ ï¼2017å¹´03æ22æ¥ 15:03 +主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: çå¤: Re: [BUG]COLO failover hang + + + + + +Hi, + +On 2017/3/22 9:42, address@hidden wrote: +ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ +ï¼ +ï¼ index 13966f1..d65a0ea 100644 +ï¼ +ï¼ +ï¼ --- a/migration/socket.c +ï¼ +ï¼ +ï¼ +++ b/migration/socket.c +ï¼ +ï¼ +ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ +ï¼ +ï¼ } +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ trace_migration_socket_incoming_accepted() +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), "migration-socket-incoming") +ï¼ +ï¼ +ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ +ï¼ +ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ +ï¼ +ï¼ QIO_CHANNEL(sioc)) +ï¼ +ï¼ +ï¼ object_unref(OBJECT(sioc)) +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ Is this patch ok? +ï¼ + +Yes, i think this works, but a better way maybe to call +qio_channel_set_feature() +in qio_channel_socket_accept(), we didn't set the SHUTDOWN feature for the +socket accept fd, +Or fix it by this: + +diff --git a/io/channel-socket.c b/io/channel-socket.c +index f546c68..ce6894c 100644 +--- a/io/channel-socket.c ++++ b/io/channel-socket.c +@@ -330,9 +330,8 @@ qio_channel_socket_accept(QIOChannelSocket *ioc, + Error **errp) + { + QIOChannelSocket *cioc +- +- cioc = QIO_CHANNEL_SOCKET(object_new(TYPE_QIO_CHANNEL_SOCKET)) +- cioc-ï¼fd = -1 ++ ++ cioc = qio_channel_socket_new() + cioc-ï¼remoteAddrLen = sizeof(ioc-ï¼remoteAddr) + cioc-ï¼localAddrLen = sizeof(ioc-ï¼localAddr) + + +Thanks, +Hailiang + +ï¼ I have test it . The test could not hang any more. +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ åå§é®ä»¶ +ï¼ +ï¼ +ï¼ +ï¼ åä»¶äººï¼ address@hidden +ï¼ æ¶ä»¶äººï¼ address@hidden address@hidden +ï¼ æéäººï¼ address@hidden address@hidden address@hidden +ï¼ æ¥ æ ï¼2017å¹´03æ22æ¥ 09:11 +ï¼ ä¸» é¢ ï¼Re: [Qemu-devel] çå¤: Re: çå¤: Re: [BUG]COLO failover hang +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ +ï¼ On 2017/3/21 19:56, Dr. David Alan Gilbert wrote: +ï¼ ï¼ * Hailiang Zhang (address@hidden) wrote: +ï¼ ï¼ï¼ Hi, +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Thanks for reporting this, and i confirmed it in my test, and it is a bug. +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Though we tried to call qemu_file_shutdown() to shutdown the related fd, in +ï¼ ï¼ï¼ case COLO thread/incoming thread is stuck in read/write() while do +failover, +ï¼ ï¼ï¼ but it didn't take effect, because all the fd used by COLO (also migration) +ï¼ ï¼ï¼ has been wrapped by qio channel, and it will not call the shutdown API if +ï¼ ï¼ï¼ we didn't qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN). +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ Cc: Dr. David Alan Gilbert address@hidden +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ I doubted migration cancel has the same problem, it may be stuck in write() +ï¼ ï¼ï¼ if we tried to cancel migration. +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ void fd_start_outgoing_migration(MigrationState *s, const char *fdname, +Error **errp) +ï¼ ï¼ï¼ { +ï¼ ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(ioc), "migration-fd-outgoing") +ï¼ ï¼ï¼ migration_channel_connect(s, ioc, NULL) +ï¼ ï¼ï¼ ... ... +ï¼ ï¼ï¼ We didn't call qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) above, +ï¼ ï¼ï¼ and the +ï¼ ï¼ï¼ migrate_fd_cancel() +ï¼ ï¼ï¼ { +ï¼ ï¼ï¼ ... ... +ï¼ ï¼ï¼ if (s-ï¼state == MIGRATION_STATUS_CANCELLING && f) { +ï¼ ï¼ï¼ qemu_file_shutdown(f) --ï¼ This will not take effect. No ? +ï¼ ï¼ï¼ } +ï¼ ï¼ï¼ } +ï¼ ï¼ +ï¼ ï¼ (cc'd in Daniel Berrange). +ï¼ ï¼ I see that we call qio_channel_set_feature(ioc, +QIO_CHANNEL_FEATURE_SHUTDOWN) at the +ï¼ ï¼ top of qio_channel_socket_new so I think that's safe isn't it? +ï¼ ï¼ +ï¼ +ï¼ Hmm, you are right, this problem is only exist for the migration incoming fd, +thanks. +ï¼ +ï¼ ï¼ Dave +ï¼ ï¼ +ï¼ ï¼ï¼ Thanks, +ï¼ ï¼ï¼ Hailiang +ï¼ ï¼ï¼ +ï¼ ï¼ï¼ On 2017/3/21 16:10, address@hidden wrote: +ï¼ ï¼ï¼ï¼ Thank youã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I have test areadyã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ When the Primary Node panic,the Secondary Node qemu hang at the same +placeã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Incorrding +http://wiki.qemu-project.org/Features/COLO +ï¼kill Primary Node +qemu will not produce the problem,but Primary Node panic canã +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I think due to the feature of channel does not support +QIO_CHANNEL_FEATURE_SHUTDOWN. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ when failover,channel_shutdown could not shut down the channel. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ so the colo_process_incoming_thread will hang at recvmsg. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ I test a patch: +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ diff --git a/migration/socket.c b/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ index 13966f1..d65a0ea 100644 +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ --- a/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +++ b/migration/socket.c +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ @@ -147,8 +147,9 @@ static gboolean +socket_accept_incoming_migration(QIOChannel *ioc, +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ } +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ trace_migration_socket_incoming_accepted() +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ qio_channel_set_name(QIO_CHANNEL(sioc), +"migration-socket-incoming") +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ + qio_channel_set_feature(QIO_CHANNEL(sioc), +QIO_CHANNEL_FEATURE_SHUTDOWN) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ migration_channel_process_incoming(migrate_get_current(), +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ QIO_CHANNEL(sioc)) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ object_unref(OBJECT(sioc)) +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ My test will not hang any more. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ åå§é®ä»¶ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ åä»¶äººï¼ address@hidden +ï¼ ï¼ï¼ï¼ æ¶ä»¶äººï¼ç广10165992 address@hidden +ï¼ ï¼ï¼ï¼ æéäººï¼ address@hidden address@hidden +ï¼ ï¼ï¼ï¼ æ¥ æ ï¼2017å¹´03æ21æ¥ 15:58 +ï¼ ï¼ï¼ï¼ 主 é¢ ï¼Re: [Qemu-devel] çå¤: Re: [BUG]COLO failover hang +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Hi,Wang. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ You can test this branch: +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +https://github.com/coloft/qemu/tree/colo-v5.1-developing-COLO-frame-v21-with-shared-disk +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ and please follow wiki ensure your own configuration correctly. +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +http://wiki.qemu-project.org/Features/COLO +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Thanks +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ï¼ On 03/21/2017 03:27 PM, address@hidden wrote: +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ hi. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ I test the git qemu master have the same problem. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #0 qio_channel_socket_readv (ioc=0x7f65911b4e50, iov=0x7f64ef3fd880, +ï¼ ï¼ï¼ï¼ ï¼ niov=1, fds=0x0, nfds=0x0, errp=0x0) at io/channel-socket.c:461 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #1 0x00007f658e4aa0c2 in qio_channel_read +ï¼ ï¼ï¼ï¼ ï¼ (address@hidden, address@hidden "", +ï¼ ï¼ï¼ï¼ ï¼ address@hidden, address@hidden) at io/channel.c:114 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #2 0x00007f658e3ea990 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ buf=0x7f65907cb838 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #3 0x00007f658e3e97fc in qemu_fill_buffer (f=0x7f65907cb800) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:295 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #4 0x00007f658e3ea2e1 in qemu_peek_byte (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at migration/qemu-file.c:555 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #5 0x00007f658e3ea34b in qemu_get_byte (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:568 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #6 0x00007f658e3ea552 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ migration/qemu-file.c:648 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #7 0x00007f658e3e66e5 in colo_receive_message (f=0x7f65907cb800, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at migration/colo.c:244 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #8 0x00007f658e3e681e in colo_receive_check_message (f=ï¼optimized +ï¼ ï¼ï¼ï¼ ï¼ outï¼, address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ at migration/colo.c:264 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #9 0x00007f658e3e740e in colo_process_incoming_thread +ï¼ ï¼ï¼ï¼ ï¼ (opaque=0x7f658eb30360 ï¼mis_current.31286ï¼) at migration/colo.c:577 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #10 0x00007f658be09df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #11 0x00007f65881983ed in clone () from /lib64/libc.so.6 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $2 = 0x7f658ff7d5c0 "migration-socket-incoming" +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features Do not support QIO_CHANNEL_FEATURE_SHUTDOWN +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $3 = 0 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #0 socket_accept_incoming_migration (ioc=0x7fdcceeafa90, +ï¼ ï¼ï¼ï¼ ï¼ condition=G_IO_IN, opaque=0x7fdcceeafa90) at migration/socket.c:137 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #1 0x00007fdcc6966350 in g_main_dispatch (context=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ gmain.c:3054 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #2 g_main_context_dispatch (context=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ address@hidden) at gmain.c:3630 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #3 0x00007fdccb8a6dcc in glib_pollfds_poll () at util/main-loop.c:213 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #4 os_host_main_loop_wait (timeout=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ util/main-loop.c:258 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #5 main_loop_wait (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ util/main-loop.c:506 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #6 0x00007fdccb526187 in main_loop () at vl.c:1898 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ #7 main (argc=ï¼optimized outï¼, argv=ï¼optimized outï¼, envp=ï¼optimized +ï¼ ï¼ï¼ï¼ ï¼ outï¼) at vl.c:4709 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼features +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $1 = 6 +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ (gdb) p ioc-ï¼name +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ $2 = 0x7fdcce1b1ab0 "migration-socket-listener" +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ May be socket_accept_incoming_migration should +ï¼ ï¼ï¼ï¼ ï¼ call qio_channel_set_feature(ioc, QIO_CHANNEL_FEATURE_SHUTDOWN)?? +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ thank you. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ åå§é®ä»¶ +ï¼ ï¼ï¼ï¼ ï¼ address@hidden +ï¼ ï¼ï¼ï¼ ï¼ address@hidden +ï¼ ï¼ï¼ï¼ ï¼ address@hidden@huawei.comï¼ +ï¼ ï¼ï¼ï¼ ï¼ *æ¥ æ ï¼*2017å¹´03æ16æ¥ 14:46 +ï¼ ï¼ï¼ï¼ ï¼ *主 é¢ ï¼**Re: [Qemu-devel] COLO failover hang* +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ On 03/15/2017 05:06 PM, wangguang wrote: +ï¼ ï¼ï¼ï¼ ï¼ ï¼ am testing QEMU COLO feature described here [QEMU +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Wiki]( +http://wiki.qemu-project.org/Features/COLO +). +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ When the Primary Node panic,the Secondary Node qemu hang. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ hang at recvmsg in qio_channel_socket_readv. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ And I run { 'execute': 'nbd-server-stop' } and { "execute": +ï¼ ï¼ï¼ï¼ ï¼ ï¼ "x-colo-lost-heartbeat" } in Secondary VM's +ï¼ ï¼ï¼ï¼ ï¼ ï¼ monitor,the Secondary Node qemu still hang at recvmsg . +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ I found that the colo in qemu is not complete yet. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Do the colo have any plan for development? +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ Yes, We are developing. You can see some of patch we pushing. +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Has anyone ever run it successfully? Any help is appreciated! +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ In our internal version can run it successfully, +ï¼ ï¼ï¼ï¼ ï¼ The failover detail you can ask Zhanghailiang for help. +ï¼ ï¼ï¼ï¼ ï¼ Next time if you have some question about COLO, +ï¼ ï¼ï¼ï¼ ï¼ please cc me and zhanghailiang address@hidden +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ Thanks +ï¼ ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ centos7.2+qemu2.7.50 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ (gdb) bt +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #0 0x00007f3e00cc86ad in recvmsg () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #1 0x00007f3e0332b738 in qio_channel_socket_readv (ioc=ï¼optimized +outï¼, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ iov=ï¼optimized outï¼, niov=ï¼optimized outï¼, fds=0x0, nfds=0x0, +errp=0x0) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ io/channel-socket.c:497 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #2 0x00007f3e03329472 in qio_channel_read (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden "", address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at io/channel.c:97 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #3 0x00007f3e032750e0 in channel_get_buffer (opaque=ï¼optimized outï¼, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ buf=0x7f3e05910f38 "", pos=ï¼optimized outï¼, size=32768) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file-channel.c:78 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #4 0x00007f3e0327412c in qemu_fill_buffer (f=0x7f3e05910f00) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:257 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #5 0x00007f3e03274a41 in qemu_peek_byte (address@hidden, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/qemu-file.c:510 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #6 0x00007f3e03274aab in qemu_get_byte (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:523 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #7 0x00007f3e03274cb2 in qemu_get_be32 (address@hidden) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/qemu-file.c:603 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #8 0x00007f3e03271735 in colo_receive_message (f=0x7f3e05910f00, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ address@hidden) at migration/colo.c:215 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #9 0x00007f3e0327250d in colo_wait_handle_message +(errp=0x7f3d62bfaa48, +ï¼ ï¼ï¼ï¼ ï¼ ï¼ checkpoint_request=ï¼synthetic pointerï¼, f=ï¼optimized outï¼) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:546 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #10 colo_process_incoming_thread (opaque=0x7f3e067245e0) at +ï¼ ï¼ï¼ï¼ ï¼ ï¼ migration/colo.c:649 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #11 0x00007f3e00cc1df3 in start_thread () from /lib64/libpthread.so.0 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ #12 0x00007f3dfc9c03ed in clone () from /lib64/libc..so.6 +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ -- +ï¼ ï¼ï¼ï¼ ï¼ ï¼ View this message in context: +http://qemu.11.n7.nabble.com/COLO-failover-hang-tp473250.html +ï¼ ï¼ï¼ï¼ ï¼ ï¼ Sent from the Developer mailing list archive at Nabble.com. +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ -- +ï¼ ï¼ï¼ï¼ ï¼ Thanks +ï¼ ï¼ï¼ï¼ ï¼ Zhang Chen +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ ï¼ +ï¼ ï¼ï¼ï¼ +ï¼ ï¼ï¼ +ï¼ ï¼ -- +ï¼ ï¼ Dr. David Alan Gilbert / address@hidden / Manchester, UK +ï¼ ï¼ +ï¼ ï¼ . +ï¼ ï¼ +ï¼ + diff --git a/results/classifier/118/unknown/721 b/results/classifier/118/unknown/721 new file mode 100644 index 00000000..307b49f4 --- /dev/null +++ b/results/classifier/118/unknown/721 @@ -0,0 +1,60 @@ +user-level: 0.886 +risc-v: 0.877 +TCG: 0.829 +mistranslation: 0.829 +VMM: 0.826 +hypervisor: 0.818 +virtual: 0.816 +vnc: 0.811 +x86: 0.807 +KVM: 0.807 +peripherals: 0.801 +debug: 0.800 +network: 0.800 +architecture: 0.800 +ppc: 0.787 +semantic: 0.778 +permissions: 0.776 +assembly: 0.776 +register: 0.774 +arm: 0.774 +i386: 0.770 +files: 0.767 +device: 0.766 +graphic: 0.760 +performance: 0.760 +kernel: 0.755 +socket: 0.747 +PID: 0.747 +boot: 0.733 + +Build failed at libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o +Steps to reproduce: +1. Download and build from source + +``` +wget https://download.qemu.org/qemu-6.1.0.tar.xz +tar xvJf qemu-6.1.0.tar.xz +cd qemu-6.1.0 +./configure +make +``` +Additional information: +``` +[2150/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_dirtyrate.c.o +[2151/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_ram.c.o +[2152/9644] Compiling C object libqemu-alpha-softmmu.fa.p/target_alpha_fpu_helper.c.o +[2153/9644] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_translate-all.c.o +[2154/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_target.c.o +[2155/9644] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o +FAILED: libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o +gcc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/valgrind -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/intel/Sources/qemu-6.1.0/linux-headers -isystem linux-headers -iquote . -iquote /home/intel/Sources/qemu-6.1.0 -iquote /home/intel/Sources/qemu-6.1.0/include -iquote /home/intel/Sources/qemu-6.1.0/disas/libvixl -iquote /home/intel/Sources/qemu-6.1.0/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -g -O3 -feliminate-unused-debug-types -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -Wformat -Wformat-security -m64 -fasynchronous-unwind-tables -Wp,-D_REENTRANT -ftree-loop-distribute-patterns -Wl,-z -Wl,now -Wl,-z -Wl,relro -fno-semantic-interposition -ffat-lto-objects -fno-trapping-math -Wl,-sort-common -Wl,--enable-new-dtags -mtune=skylake -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o -MF libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o.d -o libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o -c ../accel/tcg/cputlb.c +during GIMPLE pass: fab +In file included from /home/intel/Sources/qemu-6.1.0/include/qemu/osdep.h:37, + from ../accel/tcg/cputlb.c:20: +../accel/tcg/atomic_common.c.inc: In function ‘helper_atomic_fetch_andb’: +/home/intel/Sources/qemu-6.1.0/include/exec/helper-head.h:21:27: internal compiler error: in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3245 + 21 | #define HELPER(name) glue(helper_, name) + | ^~~~~~~ +/home/intel/Sources/qemu-6.1.0/include/qemu/compiler.h:35:21: note: in definition of macro ‘xglue’ + 35 | #define xglue(x, y) x diff --git a/results/classifier/118/unknown/723 b/results/classifier/118/unknown/723 new file mode 100644 index 00000000..80b77426 --- /dev/null +++ b/results/classifier/118/unknown/723 @@ -0,0 +1,61 @@ +user-level: 0.883 +permissions: 0.841 +files: 0.821 +vnc: 0.818 +VMM: 0.815 +TCG: 0.808 +mistranslation: 0.804 +ppc: 0.804 +risc-v: 0.804 +virtual: 0.802 +register: 0.802 +boot: 0.791 +x86: 0.785 +hypervisor: 0.782 +debug: 0.780 +performance: 0.779 +arm: 0.778 +device: 0.778 +KVM: 0.765 +graphic: 0.763 +architecture: 0.759 +semantic: 0.754 +assembly: 0.752 +kernel: 0.751 +network: 0.744 +peripherals: 0.744 +socket: 0.743 +i386: 0.728 +PID: 0.721 + +multiple displays VGA + qxl forces Spice mouse-mode=server and breaks usb-tablet/seamless mode +Description of problem: +qxl causes a totally unexpected mouse conflict with the default VGA in OSX Catalina and newer guests using AppleVirtualGraphics.kext + +usb-tablet is unusable - only clicks are received +usb-mouse works but grabs focus +Steps to reproduce: +1. install and run OSX guest +2. connect to Spice port +3. can't move mouse if usb-tablet is used. usb-mouse pointer but is grabbed +4. removing qxl fixed the issue for me. Mouse is seamless/not grabbed now +5. added -spice agent-mouse=on just in case +Additional information: +qmp from broken shows mouse-mode server. Working guests show mouse-mode client + +``` +{ "execute": "query-spice" } +... "mouse-mode": "server"}} +``` +- spice works with multiple displays in OSX if both are VGA but I had the same focus problem, will need to recheck because Qemu 6.1 seems stuck on mouse-mode=server. + + +Working VGA +``` +/usr/bin/qemu-system-x86_64 -name macos-big-sur,process=macos-big-sur -pidfile macos-big-sur/macos-big-sur.pid -enable-kvm -machine q35,smm=off,vmport=off -device isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal\(c\)AppleComputerInc -no-hpet -global kvm-pit.lost_tick_policy=discard -cpu host,kvm=on,vendor=GenuineIntel,+hypervisor,+invtsc,+kvm_pv_eoi,+kvm_pv_unhalt -smp cores=2,threads=1,sockets=1 -m 8G -device virtio-balloon -smbios type=2,manufacturer="Wimpys World",product=Quickemu,version=2.3.1,serial=jvzclfjbeyq.pbz,location=wimpysworld.com,asset=macos-big-sur -device VGA,vgamem_mb=128 -display none -device usb-ehci,id=input -device usb-kbd,bus=input.0 -device usb-tablet,bus=input.0 -rtc base=localtime,clock=host,driftfix=slew -spice disable-ticketing=on,agent-mouse=on,port=5930 -device virtio-serial-pci -chardev socket,id=agent0,path=macos-big-sur/macos-big-sur-agent.sock,server=on,wait=off -device virtserialport,chardev=agent0,name=org.qemu.guest_agent.0 -device virtio-rng-pci,rng=rng0 -object rng-random,id=rng0,filename=/dev/urandom -chardev socket,id=monitor0,path=macos-big-sur/macos-big-sur-monitor.sock,server=on,wait=off -mon chardev=monitor0,id=monitor,mode=control -monitor none -serial mon:stdio -audiodev spice,id=audio0 -device ich9-intel-hda -device hda-duplex,audiodev=audio0 -device virtio-net,netdev=nic -netdev user,hostname=macos-big-sur,hostfwd=tcp::22220-:22,id=nic -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=macos-big-sur/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=macos-big-sur/OVMF_VARS-1024x768.fd -device ahci,id=ahci -device ide-hd,bus=ahci.0,drive=BootLoader,bootindex=0 -drive id=BootLoader,if=none,format=qcow2,file=macos-big-sur/OpenCore.qcow2 -device virtio-blk-pci,drive=SystemDisk -drive id=SystemDisk,if=none,format=qcow2,file=macos-big-sur/disk.qcow2 -device qemu-xhci,id=spicepass -chardev spicevmc,id=usbredirchardev1,name=usbredir -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 -chardev spicevmc,id=usbredirchardev2,name=usbredir -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 -chardev spicevmc,id=usbredirchardev3,name=usbredir -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 -device usb-ccid -chardev spicevmc,id=ccid,name=smartcard -device ccid-card-passthru,chardev=ccid -device virtio-serial-pci -chardev spiceport,id=webdav0,name=org.spice-space.webdav.0 -device virtserialport,chardev=webdav0,name=org.spice-space.webdav.0 -fsdev local,id=fsdev0,path=/home/jmorrison/Public,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,mount_tag=Public-jmorrison +``` + +Broken usb-tablet qxl +``` +/usr/bin/qemu-system-x86_64 -name macos-big-sur,process=macos-big-sur -pidfile macos-big-sur/macos-big-sur.pid -enable-kvm -machine q35,smm=off,vmport=off -device isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal\(c\)AppleComputerInc -no-hpet -global kvm-pit.lost_tick_policy=discard -cpu host,kvm=on,vendor=GenuineIntel,+hypervisor,+invtsc,+kvm_pv_eoi,+kvm_pv_unhalt -smp cores=2,threads=1,sockets=1 -m 8G -device virtio-balloon -smbios type=2,manufacturer="Wimpys World",product=Quickemu,version=2.3.1,serial=jvzclfjbeyq.pbz,location=wimpysworld.com,asset=macos-big-sur -device qxl -display none -device usb-ehci,id=input -device usb-kbd,bus=input.0 -device usb-tablet,bus=input.0 -rtc base=localtime,clock=host,driftfix=slew -spice disable-ticketing=on,port=5930 -device virtio-serial-pci -chardev socket,id=agent0,path=macos-big-sur/macos-big-sur-agent.sock,server=on,wait=off -device virtserialport,chardev=agent0,name=org.qemu.guest_agent.0 -device virtio-rng-pci,rng=rng0 -object rng-random,id=rng0,filename=/dev/urandom -chardev socket,id=monitor0,path=macos-big-sur/macos-big-sur-monitor.sock,server=on,wait=off -mon chardev=monitor0,id=monitor,mode=control -monitor none -serial mon:stdio -audiodev spice,id=audio0 -device ich9-intel-hda -device hda-duplex,audiodev=audio0 -device virtio-net,netdev=nic -netdev user,hostname=macos-big-sur,hostfwd=tcp::22220-:22,id=nic -global driver=cfi.pflash01,property=secure,value=on -drive if=pflash,format=raw,unit=0,file=macos-big-sur/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=macos-big-sur/OVMF_VARS-1024x768.fd -device ahci,id=ahci -device ide-hd,bus=ahci.0,drive=BootLoader,bootindex=0 -drive id=BootLoader,if=none,format=qcow2,file=macos-big-sur/OpenCore.qcow2 -device virtio-blk-pci,drive=SystemDisk -drive id=SystemDisk,if=none,format=qcow2,file=macos-big-sur/disk.qcow2 -device qemu-xhci,id=spicepass -chardev spicevmc,id=usbredirchardev1,name=usbredir -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1 -chardev spicevmc,id=usbredirchardev2,name=usbredir -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2 -chardev spicevmc,id=usbredirchardev3,name=usbredir -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3 -device usb-ccid -chardev spicevmc,id=ccid,name=smartcard -device ccid-card-passthru,chardev=ccid -device virtio-serial-pci -chardev spiceport,id=webdav0,name=org.spice-space.webdav.0 -device virtserialport,chardev=webdav0,name=org.spice-space.webdav.0 -fsdev local,id=fsdev0,path=/home/jmorrison/Public,security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,mount_tag=Public-jmorrison +``` diff --git a/results/classifier/118/unknown/727 b/results/classifier/118/unknown/727 new file mode 100644 index 00000000..b540c9bf --- /dev/null +++ b/results/classifier/118/unknown/727 @@ -0,0 +1,186 @@ +hypervisor: 0.838 +permissions: 0.829 +device: 0.822 +files: 0.819 +peripherals: 0.818 +architecture: 0.794 +debug: 0.792 +user-level: 0.789 +virtual: 0.783 +performance: 0.781 +TCG: 0.781 +ppc: 0.780 +kernel: 0.777 +register: 0.776 +vnc: 0.776 +assembly: 0.774 +mistranslation: 0.772 +x86: 0.770 +KVM: 0.769 +VMM: 0.762 +PID: 0.758 +arm: 0.757 +semantic: 0.744 +risc-v: 0.735 +graphic: 0.725 +socket: 0.723 +boot: 0.702 +network: 0.664 +i386: 0.653 + +VHDX is corrupted on expansion +Description of problem: +Fresh VHDX corrupts with data loss upon copying data into it. +Steps to reproduce: +1. Create new dynamic vhdx file of about 93Gib (unexpanded, starting size is small ~205Mib, freshly created and NTFS formatted in windows.) +2. Connect drive using qemu-nbd to /dev/nbd0 +3. Ensure partition using gdisk +4. format partition with ntfs/ExFAT volume +5. mount volume +6. copy/rsync data of about 85Gib of data into the mounted volume +7. unmount volume +8. disconnect /dev/nbd0 +9. reconnect /dev/nbd0 +10. attempt mount, sometimes mount may fail if corrupted +11. If mount succeeds, verify data/all-files using some method like sha256sum. Some data is likely to fail + +Given the amount of data I am rsync-ing into the volume, there is very high chance of corruption. + +The corruption is not apparent until **disconnection and reconnection** of virtual-disk. Simply unmounting and remounting without disconnecting is unlikely to cause one to suspect corruption. + +If the expanded corrupted volume is again disconnected, reconnected, reformatted and data is again re-copied onto it, then the volume is less likely to experience a corruption, perhaps because new block allocation is not required. + +Errors vary and include: +- sometimes mount fails +- sometimes ls -l output is garbled +- sometimes one cannot cd into a directory +- several consecutive errors in shasum256 start midway through the file-list processing. Error is shown as if rsync failed and files do not exist. + ``` + sha256sum: ./201207/IMG_2406.JPG: No such file or directory + ./201207/IMG_2406.JPG: FAILED open or read + ``` +- Doing chdsk on windows may just create FOUND.000/FILE0000.CHK files. +Additional information: +See comment https://gitlab.com/qemu-project/qemu/-/issues/136#note_731044761 from where this all began. Some summary included here. + +``` +[root@sirius a16]# uname -a +Linux sirius 5.15.0-60.fc35.x86_64 #1 SMP Tue Nov 2 15:38:03 IST 2021 x86_64 x86_64 x86_64 GNU/Linux + +[root@sirius ~]# qemu-system-x86_64 --version +QEMU emulator version 6.1.0 (qemu-6.1.0-10.fc35) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +[root@sirius ~]# cat /etc/mtab | grep -E "a16|a17" | grep ntfs3 +/dev/sda16 /mnt/a16 ExFAT rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro 0 0 +/dev/sda17 /mnt/a17 ntfs3 rw,relatime,uid=0,gid=0,iocharset=utf8 0 0 + +[root@sirius ~]# uname -a # self-built rpmbuild kernel from fedora rawhide kernel-src rpm +Linux sirius 5.15.0-60.fc35.x86_64 #1 SMP Tue Nov 2 15:38:03 IST 2021 x86_64 x86_64 x86_64 GNU/Linux +``` + +Test/Activity being done: About 85Gib of data is copied onto a size 93Gib VHDX on host-FS ntfs3 with guest-FS ntfs3. +``` +Prefer windows method: Inside windows-10, using powershell command New-VHD, one may a 93Gib VHDX + New-VHD -Path I:\gkpics01.vhdx -SizeBytes 99723771904 -Dynamic + Then attach disk and format volume inside to ntfs. +or Alternatively, Linux method (less preferred) + qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904 + qemu-img create -f vhdx -o subformat=dynamic /mnt/a16/gkpics01.vhdx 99723771904 +: +sync ; sleep 1 ; qemu-nbd -c /dev/nbd0 /mnt/a16/gkpics01.vhdx +: +create appropriate partitions on /dev/nbd0 if not already partitioned +gdisk /dev/nbd0 +: +format volume with filesystem ntfs, or ext4 etc if not already formatted +mkfs -t ntfs -Q -L fs_gkpics01 /dev/nbd0p2 +: +mount partition +sync ; sleep 1 ; mount -t ntfs3 /dev/nbd0p2 /mnt/t1 +: +do copy/rsync etc +( fl="photos001" ; src="/mnt/c13" ; dst="/mnt/t1" ; cd "$src" ;rsync -avH "$fl" "$dst" ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "rsync $src/$fl" ) +: +sync ; sleep 1 ; umount /mnt/t1 +: +sync ; sleep 1 ; blockdev --flushbufs /dev/nbd0 ; sleep 2 ; qemu-nbd -d /dev/nbd0 ; sleep 1 ; sync +: +sync ; sleep 1 ; qemu-nbd -c /dev/nbd0 /mnt/a16/gkpics01.vhdx +: +sync ; sleep 1 ; mount -t ntfs3 /dev/nbd0p2 /mnt/t1 +: +do ls-l/verify/sha256sum-c etc +( fl="photos001" ; rtpt="/mnt/t1" ; cd "${rtpt}/${fl}" ; sdate=`date` ; echo "$sdate" ; sha256sum -c "$rtpt/$fl/find.CHECKSUM" --quiet ; echo "$sdate" ; date ; sudo -u gana DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus DISPLAY=:0.0 -- notify-send "$src/$fl" "checksum $src/$fl" ) +``` + +In the below list detailing under what circumstance corruption occurs + +- Format: kernel-version/ disk-attaching-sw/ hostFS/ VDISK/ guestFS with any parameters in parenthesis. +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ntfs3/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ntfs3/VHDX/ext4 +- Corruption does happen with kernel-5.15.0-60/guestfish-1.46.0(backend=direct)/ntfs3/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.0-60/guestfish-1.46.0(backend=libvirt-7.6.0-3)/ntfs3/VHDX/ntfs3 +- Corruption does happen on host-FS **ExFAT too** with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.0-60/qemu-6.0.0-10/ExFAT/VHDX/ntfs3 +- Corruption does happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/VHDX/ntfs3g-fuseblk +- Corruption does happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/VHDX(created by qemu-img)/ntfs3g-fuseblk + ``` Failed to mount '/dev/nbd0p2': Input/output error NTFS is either inconsistent, or there is a hardware fault,``` +- Corruption does **not** happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/qcow2/ext4 +- Corruption does **not** happen with kernel-5.14.18-300/qemu-6.0.0-12/ExFAT/qcow2/ntfs3g-fuseblk +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(cache=none,aio=threads)/ntfs3 +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(cache=none,aio=io_uring)/ntfs3 +- VHDX fixed disk grows in size. Filed as different bug: https://gitlab.com/qemu-project/qemu/-/issues/806 + - Corruption **does happen** with kernel-5.15.0-60/qemu-6.1.0-10/ExFAT/VHDX(fixed)/ntfs3 + A fixed vhdx disk should not grow in size. It is as if the blocks are added to a vhdx-journal instead of overwriting preallocated blocks. +- Corruption does happen with kernel-5.15.0-60/qemu-6.1.0-10/ext4/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.2-200/**qemu-6.2.0-rc1**/ExFAT/VHDX/ntfs3 +- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VMDK**(v4,monolithicSparse)/ntfs3 +- Corruption does not happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/VMDK(compat6,monolithicSparse)/ntfs3 +- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VDI**/ntfs3 +- Corruption does **not** happen with kernel-5.15.2-200/qemu-6.2.0-rc1/ExFAT/**VPC**(dynamic)/ntfs3 +- Corruption does happen with kernel-5.15.2-200/**qemu-5.2.0-8**/ExFAT/VHDX/ntfs3 +- Corruption does happen with kernel-5.15.2-200/**qemu-4.2.1-1**/ExFAT/VHDX/ntfs3 +- Corruption does happen with vhdx-file is on 2Tb NTFS 1Tb partition of **external USB HDD** 2Tb, with kernel-5.15.2-200/qemu-6.2.0-rc1/ntfs3/VHDX/ntfs3 +- Corruption does happen when using src is on ntfs3 partition on external USB drive, which is **generated synthetic data (sgdata)** sgdata/kernel-5.15.2-200/qemu-6.2.0-rc1/ExFat/VHDX/ntfs3 +- Corruption does happen when starting with qemu-img created vhdx image with sgdata/kernel-5.15.2-200/qemu-6.2.0-rc1/ExFat/VHDX(created by qemu-img)/ext4 superblock mount fail +- Corruption does happen older fc34-kernel on Fedora-35, sgdata/kernel-5.13.19-200/qemu-6.2.0-rc2/ExFAT/VHDX/ntfs3g-fuseblk , different, fewer files 3 small files affected +- Corruption does happen with older fc32-kernel on Fedora-35, sgdata/kernel-5.11.22-100/qemu-6.2.0-rc2/ExFAT/VHDX/ntfs3g-fuseblk , fewer files, different, but same as above 3 small files affected, +- Corruption does happen with older fc32-kernel on Fedora-35, sgdata/kernel-5.11.22-100/qemu-6.2.0-rc2/ExFAT/VHDX/ext4 +- Corruption does happen with self-built 5.10 LTS kernel on Fedora-35, sgdata/kernel-5.10.90-200/qemu-6.2.0-1/ExFAT/VHDX/ext4 (sgdata accessed using ntfs-fuseblk) +- As the host kernel invoking qemu-nbd, these kernels showed less errors than if they were run inside a VM as a guest. If run as a guest VM, These kernels, 5.15.4 and above, may also have kernel bugs https://bugzilla.kernel.org/show_bug.cgi?id=215460 or https://bugzilla.kernel.org/show_bug.cgi?id=215563 resulting in additional compounded errors in the failure test results, even in raw-img and qcow2(fixed). + - Corruption does happen with sgdata/kernel-5.15.4-201/qemu-6.2.0-rc1/ExFAT/VHDX(created by qemu-img)/ext4 + - Corruption does happen with sgdata/kernel-5.15.4-201/**qemu-6.2.0-rc2**/ExFAT/VHDX(created by qemu-img)/ext4 + - Corruption does not happen with synthetic-data sgdata/kernel-5.15.4-201/qemu-6.2.0-rc2/ExFAT/VMDK(created by qemu-img)/ext4 + - Corruption does happen with sgdata/kernel-5.15.5-200/qemu-6.2.0-rc2/ExFAT/VHDX(created by qemu-img)/ext4 + - Corruption does not happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin-qemu-6.2.0-0.rc2/ExFAT/vmdk/ntfs3 + - Corruption does not happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin/ExFAT/vmdk-nbd-vddkplugin/ntfs3 + - Corruption does happen with sgdata/kernel-5.15.4-201/nbdkit-1.28.2-nbdplugin-qemu-6.2.0-0.rc2/ExFAT/VHDX/ntfs3 + - Corruption does happen with sgdata/kernel-5.15.6-200 to kernel-5.15.13-200 /qemu-6.2.0-0.rc2/ExFAT/VHDX/ntfs3 +- On Windows-10, these tests may possibly be different bug. Also causes system-wide DiskIO stuck in addition to corruption https://github.com/cloudbase/wnbd/issues/63 + - Corruption does happen with sgdata/**WIN10**-21H2-19044-1415/**WNBD**-0.2.2-4-g10c1fbe/qemu-6.2.0-rc4/ExFAT/VHDX/NTFS + - Corruption **does happen** with sgdata/**WIN10**-21H2-19044-1415/**WNBD**-0.2.2-4-g10c1fbe/qemu-6.2.0-rc4/ExFAT/**qcow2**/NTFS +- Possibly different bug, on Windows-10, corruption of virtual-disk from inside VM, no nbd . Maybe https://bugzilla.kernel.org/show_bug.cgi?id=215460 or https://bugzilla.kernel.org/show_bug.cgi?id=215563 + - Win10-21H2-19044-1415/WHPX/ExFAT/qemu-6.2.0-rc4/alpine-linux-3.15/kernel-5.15.4/VHDX/ntfs3 + - Win10-21H2-19044-1415/WHPX/ExFAT/qemu-6.2.0-rc4/alpine-linux-3.15/kernel-5.15.4/**qcow2**/ext4 +- Corruption does **not** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/**qcow2(dyn)**/ntfs3 data-src: VHDX(dyn)/ntfs3/sgdata +- Corruption does **not** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/qcow2(dyn)/ntfs3 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata +- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/**VHDX**/ntfs3 data-src: VHDX(dyn)/ntfs3/sgdata +- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/Fedora-Rawhide-202208/kernel-5.17.0-0.rc3.89/ExFAT/VHDX/ext4 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata +- Corruption **does** happen with Fedora-35/kernel-5.17.0-0.rc3.89(SB)/qemu-6.2.0-2/**Rocky-8.5-Workstation-20211114.iso**/**kernel-4.18.0-348.el8.0.2.x86_64**/ExFAT/VHDX/ext4 data-src: VHDX(dyn)/**ntfs-fuseblk**/sgdata + +ExFAT filesystem was considered because it does not have concept of sparse files eliminating that factor from troubleshooting. Furthermore, it may be incorrect to suspect NTFS3, ExFAT or NTFS3g-fuseblk only because they are new/recently mainstreamed filesystems, as there aren't any intense/complex filesystem operations. The filesystem is experiencing only though-put and files are simply copied into it without further operations. Furthermore, ext4 also experiences corruption if on VHDX. + +It just seems to me the VHDX support implementation has bugs, corrupts and hence is not reliable. + +The qemu test-suite needs test-cases added for testing for vhdx-stress and vhdx-throughput . + +More troubleshooting test results are summarized in https://gitlab.com/qemu-project/qemu/-/issues/727#note_745711084 + +Chief suspect files +- ~~kernel: nbd: [drivers/block/nbd.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/block/nbd.c)~~ can be made to happen via VM +- ~~kernel: ntfs3~~ no ntfs3 partition required +- ~~kernel 5.x series~~ bug exists in 4.18.0.348 +- ~~qemu: block~~ doesn't happen to other virtual-disk formats (raw,qcow2) +- qemu/VM : seems to happen only when using qemu-nbd or inside qemu-VM +- qemu: [block/vhdx.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx.c) , [block/vhdx_log.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx-log.c) , [block/vhdx-endian.c](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx-endian.c) , [block/vhdx.h](https://gitlab.com/qemu-project/qemu/-/blob/master/block/vhdx.h), diff --git a/results/classifier/118/unknown/80615920 b/results/classifier/118/unknown/80615920 new file mode 100644 index 00000000..6a7c5a54 --- /dev/null +++ b/results/classifier/118/unknown/80615920 @@ -0,0 +1,373 @@ +user-level: 0.849 +risc-v: 0.809 +KVM: 0.803 +mistranslation: 0.800 +TCG: 0.785 +x86: 0.779 +peripherals: 0.777 +i386: 0.773 +vnc: 0.768 +ppc: 0.768 +hypervisor: 0.764 +VMM: 0.759 +performance: 0.758 +permissions: 0.758 +register: 0.756 +architecture: 0.755 +files: 0.751 +boot: 0.750 +virtual: 0.749 +device: 0.748 +assembly: 0.747 +debug: 0.746 +arm: 0.744 +kernel: 0.738 +semantic: 0.737 +network: 0.732 +socket: 0.732 +graphic: 0.730 +PID: 0.727 + +[BUG] accel/tcg: cpu_exec_longjmp_cleanup: assertion failed: (cpu == current_cpu) + +It seems there is a bug in SIGALRM handling when 486 system emulates x86_64 +code. + +This code: + +#include <stdio.h> +#include <stdlib.h> +#include <pthread.h> +#include <signal.h> +#include <unistd.h> + +pthread_t thread1, thread2; + +// Signal handler for SIGALRM +void alarm_handler(int sig) { + // Do nothing, just wake up the other thread +} + +// Thread 1 function +void* thread1_func(void* arg) { + // Set up the signal handler for SIGALRM + signal(SIGALRM, alarm_handler); + + // Wait for 5 seconds + sleep(1); + + // Send SIGALRM signal to thread 2 + pthread_kill(thread2, SIGALRM); + + return NULL; +} + +// Thread 2 function +void* thread2_func(void* arg) { + // Wait for the SIGALRM signal + pause(); + + printf("Thread 2 woke up!\n"); + + return NULL; +} + +int main() { + // Create thread 1 + if (pthread_create(&thread1, NULL, thread1_func, NULL) != 0) { + fprintf(stderr, "Failed to create thread 1\n"); + return 1; + } + + // Create thread 2 + if (pthread_create(&thread2, NULL, thread2_func, NULL) != 0) { + fprintf(stderr, "Failed to create thread 2\n"); + return 1; + } + + // Wait for both threads to finish + pthread_join(thread1, NULL); + pthread_join(thread2, NULL); + + return 0; +} + + +Fails with this -strace log (there are also unsupported syscalls 334 and 435, +but it seems it doesn't affect the code much): + +... +736 rt_sigaction(SIGALRM,0x000000001123ec20,0x000000001123ecc0) = 0 +736 clock_nanosleep(CLOCK_REALTIME,0,{tv_sec = 1,tv_nsec = 0},{tv_sec = +1,tv_nsec = 0}) +736 rt_sigprocmask(SIG_BLOCK,0x00000000109fad20,0x0000000010800b38,8) = 0 +736 Unknown syscall 435 +736 +clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID| + ... +736 rt_sigprocmask(SIG_SETMASK,0x0000000010800b38,NULL,8) +736 set_robust_list(0x11a419a0,0) = -1 errno=38 (Function not implemented) +736 rt_sigprocmask(SIG_SETMASK,0x0000000011a41fb0,NULL,8) = 0 + = 0 +736 pause(0,0,2,277186368,0,295966400) +736 +futex(0x000000001123f990,FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,738,NULL,NULL,0) + = 0 +736 rt_sigprocmask(SIG_BLOCK,0x00000000109fad20,0x000000001123ee88,8) = 0 +736 getpid() = 736 +736 tgkill(736,739,SIGALRM) = 0 + = -1 errno=4 (Interrupted system call) +--- SIGALRM {si_signo=SIGALRM, si_code=SI_TKILL, si_pid=736, si_uid=0} --- +0x48874a != 0x3c69e10 +736 rt_sigprocmask(SIG_SETMASK,0x000000001123ee88,NULL,8) = 0 +** +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +(cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +failed: (cpu == current_cpu) +0x48874a != 0x3c69e10 +** +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +(cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +failed: (cpu == current_cpu) +# + +The code fails either with or without -singlestep, the command line: + +/usr/bin/qemu-x86_64 -L /opt/x86_64 -strace -singlestep /opt/x86_64/alarm.bin + +Source code of QEMU 8.1.1 was modified with patch "[PATCH] qemu/timer: Don't +use RDTSC on i486" [1], +with added few ioctls (not relevant) and cpu_exec_longjmp_cleanup() now prints +current pointers of +cpu and current_cpu (line "0x48874a != 0x3c69e10"). + +config.log (built as a part of buildroot, basically the minimal possible +configuration for running x86_64 on 486): + +# Configured with: +'/mnt/hd_8tb_p1/p1/home/crossgen/buildroot_486_2/output/build/qemu-8.1.1/configure' + '--prefix=/usr' +'--cross-prefix=/mnt/hd_8tb_p1/p1/home/crossgen/buildroot_486_2/output/host/bin/i486-buildroot-linux-gnu-' + '--audio-drv-list=' +'--python=/mnt/hd_8tb_p1/p1/home/crossgen/buildroot_486_2/output/host/bin/python3' + +'--ninja=/mnt/hd_8tb_p1/p1/home/crossgen/buildroot_486_2/output/host/bin/ninja' +'--disable-alsa' '--disable-bpf' '--disable-brlapi' '--disable-bsd-user' +'--disable-cap-ng' '--disable-capstone' '--disable-containers' +'--disable-coreaudio' '--disable-curl' '--disable-curses' +'--disable-dbus-display' '--disable-docs' '--disable-dsound' '--disable-hvf' +'--disable-jack' '--disable-libiscsi' '--disable-linux-aio' +'--disable-linux-io-uring' '--disable-malloc-trim' '--disable-membarrier' +'--disable-mpath' '--disable-netmap' '--disable-opengl' '--disable-oss' +'--disable-pa' '--disable-rbd' '--disable-sanitizers' '--disable-selinux' +'--disable-sparse' '--disable-strip' '--disable-vde' '--disable-vhost-crypto' +'--disable-vhost-user-blk-server' '--disable-virtfs' '--disable-whpx' +'--disable-xen' '--disable-attr' '--disable-kvm' '--disable-vhost-net' +'--disable-download' '--disable-hexagon-idef-parser' '--disable-system' +'--enable-linux-user' '--target-list=x86_64-linux-user' '--disable-vhost-user' +'--disable-slirp' '--disable-sdl' '--disable-fdt' '--enable-trace-backends=nop' +'--disable-tools' '--disable-guest-agent' '--disable-fuse' +'--disable-fuse-lseek' '--disable-seccomp' '--disable-libssh' +'--disable-libusb' '--disable-vnc' '--disable-nettle' '--disable-numa' +'--disable-pipewire' '--disable-spice' '--disable-usb-redir' +'--disable-install-blobs' + +Emulation of the same x86_64 code with qemu 6.2.0 installed on another x86_64 +native machine works fine. + +[1] +https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg05387.html +Best regards, +Petr + +On Sat, 25 Nov 2023 at 13:09, Petr Cvek <petrcvekcz@gmail.com> wrote: +> +> +It seems there is a bug in SIGALRM handling when 486 system emulates x86_64 +> +code. +486 host is pretty well out of support currently. Can you reproduce +this on a less ancient host CPU type ? + +> +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +> +(cpu == current_cpu) +> +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +assertion failed: (cpu == current_cpu) +> +0x48874a != 0x3c69e10 +> +** +> +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +> +(cpu == current_cpu) +> +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +assertion failed: (cpu == current_cpu) +What compiler version do you build QEMU with? That +assert is there because we have seen some buggy compilers +in the past which don't correctly preserve the variable +value as the setjmp/longjmp spec requires them to. + +thanks +-- PMM + +Dne 27. 11. 23 v 10:37 Peter Maydell napsal(a): +> +On Sat, 25 Nov 2023 at 13:09, Petr Cvek <petrcvekcz@gmail.com> wrote: +> +> +> +> It seems there is a bug in SIGALRM handling when 486 system emulates x86_64 +> +> code. +> +> +486 host is pretty well out of support currently. Can you reproduce +> +this on a less ancient host CPU type ? +> +It seems it only fails when the code is compiled for i486. QEMU built with the +same compiler with -march=i586 and above runs on the same physical hardware +without a problem. All -march= variants were executed on ryzen 3600. + +> +> ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +> +> failed: (cpu == current_cpu) +> +> Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +> assertion failed: (cpu == current_cpu) +> +> 0x48874a != 0x3c69e10 +> +> ** +> +> ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +> +> failed: (cpu == current_cpu) +> +> Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +> assertion failed: (cpu == current_cpu) +> +> +What compiler version do you build QEMU with? That +> +assert is there because we have seen some buggy compilers +> +in the past which don't correctly preserve the variable +> +value as the setjmp/longjmp spec requires them to. +> +i486 and i586+ code variants were compiled with GCC 13.2.0 (more exactly, +slackware64 current multilib distribution). + +i486 binary which runs on the real 486 is also GCC 13.2.0 and installed as a +part of the buildroot crosscompiler (about two week old git snapshot). + +> +thanks +> +-- PMM +best regards, +Petr + +On 11/25/23 07:08, Petr Cvek wrote: +ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion failed: +(cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +failed: (cpu == current_cpu) +# + +The code fails either with or without -singlestep, the command line: + +/usr/bin/qemu-x86_64 -L /opt/x86_64 -strace -singlestep /opt/x86_64/alarm.bin + +Source code of QEMU 8.1.1 was modified with patch "[PATCH] qemu/timer: Don't use +RDTSC on i486" [1], +with added few ioctls (not relevant) and cpu_exec_longjmp_cleanup() now prints +current pointers of +cpu and current_cpu (line "0x48874a != 0x3c69e10"). +If you try this again with 8.2-rc2, you should not see an assertion failure. +You should see instead + +QEMU internal SIGILL {code=ILLOPC, addr=0x12345678} +which I think more accurately summarizes the situation of attempting RDTSC on hardware +that does not support it. +r~ + +Dne 29. 11. 23 v 15:25 Richard Henderson napsal(a): +> +On 11/25/23 07:08, Petr Cvek wrote: +> +> ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: assertion +> +> failed: (cpu == current_cpu) +> +> Bail out! ERROR:../accel/tcg/cpu-exec.c:546:cpu_exec_longjmp_cleanup: +> +> assertion failed: (cpu == current_cpu) +> +> # +> +> +> +> The code fails either with or without -singlestep, the command line: +> +> +> +> /usr/bin/qemu-x86_64 -L /opt/x86_64 -strace -singlestep +> +> /opt/x86_64/alarm.bin +> +> +> +> Source code of QEMU 8.1.1 was modified with patch "[PATCH] qemu/timer: Don't +> +> use RDTSC on i486" [1], +> +> with added few ioctls (not relevant) and cpu_exec_longjmp_cleanup() now +> +> prints current pointers of +> +> cpu and current_cpu (line "0x48874a != 0x3c69e10"). +> +> +> +If you try this again with 8.2-rc2, you should not see an assertion failure. +> +You should see instead +> +> +QEMU internal SIGILL {code=ILLOPC, addr=0x12345678} +> +> +which I think more accurately summarizes the situation of attempting RDTSC on +> +hardware that does not support it. +> +> +Compilation of vanilla qemu v8.2.0-rc2 with -march=i486 by GCC 13.2.0 and +running the resulting binary on ryzen still leads to: + +** +ERROR:../accel/tcg/cpu-exec.c:533:cpu_exec_longjmp_cleanup: assertion failed: +(cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:533:cpu_exec_longjmp_cleanup: assertion +failed: (cpu == current_cpu) +Aborted + +> +> +r~ +Petr + diff --git a/results/classifier/118/unknown/810 b/results/classifier/118/unknown/810 new file mode 100644 index 00000000..8494efec --- /dev/null +++ b/results/classifier/118/unknown/810 @@ -0,0 +1,101 @@ +risc-v: 0.913 +device: 0.895 +hypervisor: 0.889 +graphic: 0.881 +register: 0.874 +i386: 0.872 +x86: 0.861 +TCG: 0.860 +VMM: 0.860 +peripherals: 0.860 +vnc: 0.859 +user-level: 0.856 +virtual: 0.852 +assembly: 0.851 +KVM: 0.851 +debug: 0.850 +semantic: 0.848 +arm: 0.843 +performance: 0.842 +permissions: 0.839 +architecture: 0.837 +ppc: 0.836 +PID: 0.822 +kernel: 0.813 +boot: 0.792 +mistranslation: 0.751 +socket: 0.749 +files: 0.742 +network: 0.727 + +i386/sev: Crash in pc_system_parse_ovmf_flash caused by bad firmware file +Description of problem: +A specially-crafted flash file can cause the `memcpy()` call in +`pc_system_parse_ovmf_flash` (`hw/i386/pc_sysfw_ovmf.c`) to READ out-of-bounds +memory, because there's no check on the `tot_len` field which is read +from the flash file. In such case, `ptr - tot_len` will point to a +memory location *below* `flash_ptr` (hence the out-of-bounds read). + +This path is only taken when SEV is enabled (which requires +KVM and x86_64). +Steps to reproduce: +1. Create `bad_ovmf.fd` using the following python script: + ``` + from uuid import UUID + OVMF_TABLE_FOOTER_GUID = "96b582de-1fb2-45f7-baea-a366c55a082d" + b = bytearray(4096) + b[4046:4048] = b'\xff\xff' # tot_len field + b[4048:4064] = UUID("{" + OVMF_TABLE_FOOTER_GUID + "}").bytes_le + with open("bad_ovmf.fd", "wb") as f: + f.write(b) + ``` +2. Build QEMU with `--enable-sanitizers` +3. Start QEMU with SEV and the bad flash file: + ``` + qemu-system-x86_64 -enable-kvm -cpu host -machine q35 \ + -drive if=pflash,format=raw,unit=0,file=bad_ovmf.fd,readonly=on \ + -machine confidential-guest-support=sev0 \ + -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x0 + ``` +4. QEMU crashes with: `SUMMARY: AddressSanitizer: stack-buffer-underflow` +Additional information: +Crash example: + +``` +$ sudo build/qemu-system-x86_64 -enable-kvm -cpu host -machine q35 \ + -drive if=pflash,format=raw,unit=0,file=bad_ovmf.fd,readonly=on \ + -machine confidential-guest-support=sev0 \ + -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x0 +==523314==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +================================================================= +==523314==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7f05305fb180 at pc 0x7f0548d89480 bp 0x7ffed44a1980 sp 0x7ffed44a1128 +READ of size 65517 at 0x7f05305fb180 thread T0 + #0 0x7f0548d8947f (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f) + #1 0x556127c3331e in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 + #2 0x556127c3331e in pc_system_parse_ovmf_flash ../hw/i386/pc_sysfw_ovmf.c:82 + #3 0x556127c21a0c in pc_system_flash_map ../hw/i386/pc_sysfw.c:203 + #4 0x556127c21a0c in pc_system_firmware_init ../hw/i386/pc_sysfw.c:258 + #5 0x556127c1ddd9 in pc_memory_init ../hw/i386/pc.c:902 + #6 0x556127bdc387 in pc_q35_init ../hw/i386/pc_q35.c:207 + #7 0x5561273bfdd6 in machine_run_board_init ../hw/core/machine.c:1181 + #8 0x556127f77de1 in qemu_init_board ../softmmu/vl.c:2652 + #9 0x556127f77de1 in qmp_x_exit_preconfig ../softmmu/vl.c:2740 + #10 0x556127f7f24d in qemu_init ../softmmu/vl.c:3775 + #11 0x556126f947ac in main ../softmmu/main.c:49 + #12 0x7f05470e80b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) + #13 0x556126fa639d in _start (/home/dmurik/git/qemu/build/qemu-system-x86_64+0x2a5739d) + +Address 0x7f05305fb180 is located in stack of thread T3 at offset 0 in frame + #0 0x556128a96f1f in qemu_sem_timedwait ../util/qemu-thread-posix.c:293 + + + This frame has 1 object(s): + [32, 48) 'ts' (line 295) <== Memory access at offset 0 partially underflows this variable +HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork + (longjmp and C++ exceptions *are* supported) +Thread T3 created by T0 here: + #0 0x7f0548d28805 in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a805) + #1 0x556128a97ecf in qemu_thread_create ../util/qemu-thread-posix.c:596 + +SUMMARY: AddressSanitizer: stack-buffer-underflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x9b47f) +``` diff --git a/results/classifier/118/unknown/818647 b/results/classifier/118/unknown/818647 new file mode 100644 index 00000000..b9cbea1f --- /dev/null +++ b/results/classifier/118/unknown/818647 @@ -0,0 +1,353 @@ +permissions: 0.931 +register: 0.917 +device: 0.912 +hypervisor: 0.895 +user-level: 0.885 +debug: 0.873 +assembly: 0.869 +risc-v: 0.866 +boot: 0.859 +arm: 0.857 +mistranslation: 0.855 +semantic: 0.851 +TCG: 0.850 +graphic: 0.849 +peripherals: 0.849 +PID: 0.844 +virtual: 0.838 +kernel: 0.837 +vnc: 0.834 +socket: 0.824 +x86: 0.821 +i386: 0.820 +performance: 0.804 +ppc: 0.802 +files: 0.799 +KVM: 0.777 +architecture: 0.777 +network: 0.772 +VMM: 0.735 + +Getting segmentation fault when trying to boot FreeBSD + +wkoszek@wkoszek:~/bin/qemu/qemu$ git log | head -1 +commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5 + +wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ qemu-system-sparc64 --version +QEMU emulator version 0.15.50, Copyright (c) 2003-2008 Fabrice Bellard + +wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ uname -a +Linux wkoszek 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:05:41 UTC 2011 i686 i686 i386 GNU/Linux + +Qemu built with default settings (./configure --prefix=<path> && make && make install) + +I run FreeBSD ISO image: +/home/wkoszek/bin/qemu-dynamic/bin/qemu-system-sparc64 -m 1024 -cdrom ~/Pulpit/iso/FreeBSD-7.4-RELEASE-sparc64-bootonly.iso -hda ~/Pulpit/iso/freebsd_sparc64.qcow2 -nographic -boot d + +Configuration device id QEMU version 1 machine id 0 +kernel cmdline +CPUs: 1 x SUNW,UltraSPARC-IIi +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 + Type 'help' for detailed information +Trying cdrom:f... +Not a bootable ELF image +Loading a.out image... +Loaded 7680 bytes +entry point is 0x4000 + +Jumping to entry point 0000000000004000 for type 0000000000000005... +switching to new context: entry point 0x4000 stack 0x00000000ffe86b49 + +>> FreeBSD/sparc64 boot block + Boot path: cdrom:f + Boot loader: /boot/loader +Consoles: Open Firmware console + +Booting with sun4u support. +Boot path set to cdrom:a + +FreeBSD/sparc64 bootstrap loader, Revision 1.0 +(<email address hidden>, Fri Feb 18 05:38:31 UTC 2011) +bootpath="cdrom:a" +Loading /boot/defaults/loader.conf +/boot/kernel/kernel data=0x8d1f48+0x82f88 syms=[0x8+0x88ec0+0x8+0x76966] +| +Unimplemented service milliseconds ([0] -- [1]) +Hit [Enter] to boot immediately, or any other key for command prompt. +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) +Unimplemented service milliseconds ([0] -- [1]) + +I press CTRL + C and I get out of the looped warning about "unimplemented service". Then I see: + +Type '?' for a list of commands, 'help' for more detailed help. +OK boot +jumping to kernel entry at 0xc0078000. +BOOTUnhandled Exception 0x0000000000000034 +PC = 0x00000000c0637454 NPC = 0x00000000c0637458 + +I wanted to start FreeBSD debugging here - I pressed 'CTRL+A c', I was dropped to the monitor. + +FRom the monitor I typed: + +Stopping execution +QEMU 0.15.50 monitor - type 'help' for more information +(qemu) x 0xc0078000 +00000000c0078000: Cannot access memory +(qemu) x 0x00000000c0637454 +00000000c0637454: Cannot access memory +(qemu) x 0x00000000c0637458 +00000000c0637458: Cannot access memory +(qemu) xp 0xc0078000 +Segmentation fault + +IMO it shouldn't have crashed. + +On Sat, Jul 30, 2011 at 9:13 PM, Wojciech Koszek +<email address hidden> wrote: +> Public bug reported: +> +> wkoszek@wkoszek:~/bin/qemu/qemu$ git log | head -1 +> commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5 +> +> wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ qemu-system-sparc64 --version +> QEMU emulator version 0.15.50, Copyright (c) 2003-2008 Fabrice Bellard +> +> wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ uname -a +> Linux wkoszek 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:05:41 UTC 2011 i686 i686 i386 GNU/Linux +> +> Qemu built with default settings (./configure --prefix=<path> && make && +> make install) +> +> I run FreeBSD ISO image: +> /home/wkoszek/bin/qemu-dynamic/bin/qemu-system-sparc64 -m 1024 -cdrom ~/Pulpit/iso/FreeBSD-7.4-RELEASE-sparc64-bootonly.iso -hda ~/Pulpit/iso/freebsd_sparc64.qcow2 -nographic -boot d +> +> Configuration device id QEMU version 1 machine id 0 +> kernel cmdline +> CPUs: 1 x SUNW,UltraSPARC-IIi +> UUID: 00000000-0000-0000-0000-000000000000 +> Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 +> Type 'help' for detailed information +> Trying cdrom:f... +> Not a bootable ELF image +> Loading a.out image... +> Loaded 7680 bytes +> entry point is 0x4000 +> +> Jumping to entry point 0000000000004000 for type 0000000000000005... +> switching to new context: entry point 0x4000 stack 0x00000000ffe86b49 +> +>>> FreeBSD/sparc64 boot block +> Boot path: cdrom:f +> Boot loader: /boot/loader +> Consoles: Open Firmware console +> +> Booting with sun4u support. +> Boot path set to cdrom:a +> +> FreeBSD/sparc64 bootstrap loader, Revision 1.0 +> (<email address hidden>, Fri Feb 18 05:38:31 UTC 2011) +> bootpath="cdrom:a" +> Loading /boot/defaults/loader.conf +> /boot/kernel/kernel data=0x8d1f48+0x82f88 syms=[0x8+0x88ec0+0x8+0x76966] +> | +> Unimplemented service milliseconds ([0] -- [1]) +> Hit [Enter] to boot immediately, or any other key for command prompt. +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> Unimplemented service milliseconds ([0] -- [1]) +> +> I press CTRL + C and I get out of the looped warning about +> "unimplemented service". Then I see: +> +> Type '?' for a list of commands, 'help' for more detailed help. +> OK boot +> jumping to kernel entry at 0xc0078000. +> BOOTUnhandled Exception 0x0000000000000034 +> PC = 0x00000000c0637454 NPC = 0x00000000c0637458 +> +> I wanted to start FreeBSD debugging here - I pressed 'CTRL+A c', I was +> dropped to the monitor. +> +> FRom the monitor I typed: +> +> Stopping execution +> QEMU 0.15.50 monitor - type 'help' for more information +> (qemu) x 0xc0078000 +> 00000000c0078000: Cannot access memory +> (qemu) x 0x00000000c0637454 +> 00000000c0637454: Cannot access memory +> (qemu) x 0x00000000c0637458 +> 00000000c0637458: Cannot access memory +> (qemu) xp 0xc0078000 +> Segmentation fault +> +> IMO it shouldn't have crashed. + +Right. + +FYI: the virtual to physical translations can be examined (before the +exception printout) with 'info tlb': +jumping to kernel entry at 0xc0078000. +QEMU 0.15.50 monitor - type 'help' for more information +(qemu) info tlb +MMU contexts: Primary: 0, Secondary: 0 +DMMU dump +[00] VA: ffe00000, PA: 7e80000, 512k, priv, RW, locked, ctx 0 local +[01] VA: ffe80000, PA: 7f00000, 512k, priv, RW, locked, ctx 0 local +[02] VA: fff00000, PA: 7f80000, 512k, priv, RW, locked, ctx 0 local +[03] VA: ffd00000, PA: 1fff0000000, 512k, priv, RO, locked, ctx 0 local +[04] VA: ffd80000, PA: 1fff0080000, 512k, priv, RO, locked, ctx 0 local +[05] VA: c864e000, PA: 580c000, 8k, priv, RW, unlocked, ctx 0 local +[06] VA: fe000000, PA: 1ff00800000, 4M, priv, RW, locked, ctx 0 local +[07] VA: fe400000, PA: 1ff00c00000, 4M, priv, RW, locked, ctx 0 local +[08] VA: bfc00000, PA: 0, 4M, priv, RW, locked, ctx 0 local +[09] VA: c8658000, PA: 5814000, 8k, priv, RW, unlocked, ctx 0 local +[10] VA: c4080000, PA: 5480000, 8k, priv, RW, unlocked, ctx 0 local +[11] VA: c4082000, PA: 5482000, 8k, priv, RW, unlocked, ctx 0 local +[12] VA: c4084000, PA: 5484000, 8k, priv, RW, unlocked, ctx 0 local +[13] VA: c4086000, PA: 5486000, 8k, priv, RW, unlocked, ctx 0 local +[14] VA: c4088000, PA: 5488000, 8k, priv, RW, unlocked, ctx 0 local +[15] VA: fffff80005a52000, PA: 5800000, 4M, user, RW, unlocked, ctx 0 local +[16] VA: c3fc8000, PA: 53c8000, 8k, priv, RW, unlocked, ctx 0 local +[17] VA: c3fca000, PA: 53ca000, 8k, priv, RW, unlocked, ctx 0 local +[18] VA: c3fcc000, PA: 53cc000, 8k, priv, RW, unlocked, ctx 0 local +[19] VA: c3fce000, PA: 53ce000, 8k, priv, RW, unlocked, ctx 0 local +[20] VA: c3fd0000, PA: 53d0000, 8k, priv, RW, unlocked, ctx 0 local +[21] VA: c3fd2000, PA: 53d2000, 8k, priv, RW, unlocked, ctx 0 local +[22] VA: c3fd4000, PA: 53d4000, 8k, priv, RW, unlocked, ctx 0 local +[23] VA: c3fd6000, PA: 53d6000, 8k, priv, RW, unlocked, ctx 0 local +[24] VA: c3fd8000, PA: 53d8000, 8k, priv, RW, unlocked, ctx 0 local +[25] VA: c3fda000, PA: 53da000, 8k, priv, RW, unlocked, ctx 0 local +[26] VA: c3fdc000, PA: 53dc000, 8k, priv, RW, unlocked, ctx 0 local +[27] VA: c3fde000, PA: 53de000, 8k, priv, RW, unlocked, ctx 0 local +[28] VA: c3fe0000, PA: 53e0000, 8k, priv, RW, unlocked, ctx 0 local +[29] VA: c3fe2000, PA: 53e2000, 8k, priv, RW, unlocked, ctx 0 local +[30] VA: c3fe4000, PA: 53e4000, 8k, priv, RW, unlocked, ctx 0 local +[31] VA: c3fe6000, PA: 53e6000, 8k, priv, RW, unlocked, ctx 0 local +[32] VA: c3fe8000, PA: 53e8000, 8k, priv, RW, unlocked, ctx 0 local +[33] VA: fffff8000106a000, PA: 1000000, 4M, user, RW, unlocked, ctx 0 local +[34] VA: c1016000, PA: 416000, 8k, priv, RW, unlocked, ctx 0 local +[35] VA: fffff8000040e000, PA: 400000, 4M, user, RW, unlocked, ctx 0 local +[36] VA: c7bae000, PA: 6e78000, 8k, priv, RW, unlocked, ctx 0 local +[37] VA: c7bb8000, PA: 5a14000, 8k, priv, RW, unlocked, ctx 0 local +[38] VA: fffff80006e70000, PA: 6c00000, 4M, user, RW, unlocked, ctx 0 local +[39] VA: c7be2000, PA: 6e6c000, 8k, priv, RW, unlocked, ctx 0 local +[40] VA: fffff8000201a000, PA: 2000000, 4M, user, RW, unlocked, ctx 0 local +[41] VA: c101a000, PA: 201a000, 8k, priv, RW, unlocked, ctx 0 local +[42] VA: c101c000, PA: 201c000, 8k, priv, RW, unlocked, ctx 0 local +[43] VA: c101e000, PA: 201e000, 8k, priv, RW, unlocked, ctx 0 local +[44] VA: c1020000, PA: 2020000, 8k, priv, RW, unlocked, ctx 0 local +[45] VA: c85cc000, PA: 6e44000, 8k, priv, RW, unlocked, ctx 0 local +[46] VA: c85d6000, PA: 6e4c000, 8k, priv, RW, unlocked, ctx 0 local +[47] VA: c85e0000, PA: 6e54000, 8k, priv, RW, unlocked, ctx 0 local +[48] VA: c85ea000, PA: 6e5c000, 8k, priv, RW, unlocked, ctx 0 local +[49] VA: c85f4000, PA: 6e04000, 8k, priv, RW, unlocked, ctx 0 local +[50] VA: c85fe000, PA: 6e0c000, 8k, priv, RW, unlocked, ctx 0 local +[51] VA: c8608000, PA: 6e14000, 8k, priv, RW, unlocked, ctx 0 local +[52] VA: c3fb8000, PA: 53b8000, 8k, priv, RW, unlocked, ctx 0 local +[53] VA: c8612000, PA: 6e1c000, 8k, priv, RW, unlocked, ctx 0 local +[54] VA: c3fbc000, PA: 53bc000, 8k, priv, RW, unlocked, ctx 0 local +[55] VA: c861c000, PA: 6e24000, 8k, priv, RW, unlocked, ctx 0 local +[56] VA: c8626000, PA: 6e2c000, 8k, priv, RW, unlocked, ctx 0 local +[57] VA: c8630000, PA: 6e34000, 8k, priv, RW, unlocked, ctx 0 local +[58] VA: c863a000, PA: 6e3c000, 8k, priv, RW, unlocked, ctx 0 local +[59] VA: c8644000, PA: 5804000, 8k, priv, RW, unlocked, ctx 0 local +[60] VA: c0c00000, PA: 5c00000, 4M, priv, RW, locked, ctx 0 local +[61] VA: c0800000, PA: 6000000, 4M, priv, RW, locked, ctx 0 local +[62] VA: c0400000, PA: 6400000, 4M, priv, RW, locked, ctx 0 local +[63] VA: c0000000, PA: 6800000, 4M, priv, RW, locked, ctx 0 local +IMMU dump +[00] VA: ffd00000, PA: 1fff0000000, 512k, priv, locked, ctx 0 local +[01] VA: fe000000, PA: 1ff00800000, 4M, priv, locked, ctx 0 local +[02] VA: fe400000, PA: 1ff00c00000, 4M, priv, locked, ctx 0 local +[60] VA: c0c00000, PA: 5c00000, 4M, priv, locked, ctx 0 local +[61] VA: c0800000, PA: 6000000, 4M, priv, locked, ctx 0 local +[62] VA: c0400000, PA: 6400000, 4M, priv, locked, ctx 0 local +[63] VA: c0000000, PA: 6800000, 4M, priv, locked, ctx 0 local +(qemu) BOOTUnhandled Exception 0x0000000000000034 +PC = 0x00000000c0637454 NPC = 0x00000000c0637458 +Stopping execution + +(qemu) xp/i 0x6637454 +0x0000000006637454: ld [ %i1 + 4 ], %g1 + +But it's easier to use GDB for debugging (add -s -S switches, attach +with Sparc GDB): +$ sparc64-linux-gdb +GNU gdb 6.8 +Copyright (C) 2008 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "--host=x86_64-unknown-linux-gnu +--target=sparc64-linux". +(gdb) set architecture sparc:v9 +The target architecture is assumed to be sparc:v9 +(gdb) b *0x00000000c0637454 +Breakpoint 1 at 0xc0637454 +(gdb) target remote :1234 +[New Thread 1] +0x000001fff0000020 in ?? () +(gdb) c +Breakpoint 1, 0x00000000c0637454 in ?? () +(gdb) info registers +g0 0x0 0x0 +g1 0xc08eb730 0xc08eb730 +g2 0xc08ee910 0xc08ee910 +g3 0xc08eb730 0xc08eb730 +g4 0x186a1 0x186a1 +g5 0xfffff8000040fff8 0xfffff8000040fff8 +g6 0xc1017980 0xc1017980 +g7 0xc093ad68 0xc093ad68 +o0 0xc08ee8f0 0xc08ee8f0 +o1 0xc08eb730 0xc08eb730 +o2 0x0 0x0 +o3 0x0 0x0 +o4 0x0 0x0 +o5 0x0 0x0 +sp 0xc0940299 0xc0940299 +o7 0xc063744c 0xc063744c +l0 0xc08eb730 0xc08eb730 +l1 0x0 0x0 +l2 0x0 0x0 +l3 0xffffffffffffffff 0xffffffffffffffff +l4 0xfffff80001078c70 0xfffff80001078c70 +l5 0xc080b908 0xc080b908 +l6 0xfffff80001084c60 0xfffff80001084c60 +l7 0xc0898320 0xc0898320 +i0 0x0 0x0 +i1 0xffffffffffffffff 0xffffffffffffffff +i2 0x0 0x0 +i3 0x88ca6c00 0x88ca6c00 +i4 0x0 0x0 +i5 0x57e 0x57e +fp 0xc0940399 0xc0940399 +i7 0xc06373e0 0xc06373e0 +pc 0xc0637454 0xc0637454 +npc 0xc0637458 0xc0637458 +state 0x4415001407 0x4415001407 +fsr 0x0 [ ] +fprs 0x0 [ ] +y 0x0 0x0 +cwp 0x7 0x7 +pstate 0x14 [ PRIV PEF ] +asi 0x15 0x15 +ccr 0x44 0x44 +(gdb) disassemble $pc $pc+4 +Dump of assembler code from 0xc0637454 to 0xc0637458: +0x00000000c0637454: ld [ %i1 + 4 ], %g1 +End of assembler dump. + + +Fixed by 67494323f2c782fe3e65c60529fe9dfa613fc500. + + diff --git a/results/classifier/118/unknown/818673 b/results/classifier/118/unknown/818673 new file mode 100644 index 00000000..39060257 --- /dev/null +++ b/results/classifier/118/unknown/818673 @@ -0,0 +1,812 @@ +permissions: 0.892 +PID: 0.891 +assembly: 0.887 +register: 0.885 +graphic: 0.883 +vnc: 0.875 +socket: 0.874 +virtual: 0.873 +semantic: 0.873 +arm: 0.873 +performance: 0.870 +debug: 0.863 +files: 0.861 +boot: 0.859 +device: 0.855 +risc-v: 0.853 +hypervisor: 0.853 +VMM: 0.852 +architecture: 0.851 +network: 0.847 +peripherals: 0.844 +ppc: 0.841 +kernel: 0.839 +user-level: 0.831 +TCG: 0.830 +KVM: 0.802 +x86: 0.796 +mistranslation: 0.772 +i386: 0.751 + +virtio: trying to map MMIO memory + +Qemu host is Core i7, running Linux. Guest is Windows XP sp3. +Often, qemu will crash shortly after starting (1-5 minutes) with a statement "qemu-system-x86_64: virtio: trying to map MMIO memory" +This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. +Qemu is started as such: +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait +The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. + +On Sun, Jul 31, 2011 at 12:01 AM, Rick Vernam <email address hidden> wrote: +> Public bug reported: +> +> Qemu host is Core i7, running Linux. Guest is Windows XP sp3. +> Often, qemu will crash shortly after starting (1-5 minutes) with a statement "qemu-system-x86_64: virtio: trying to map MMIO memory" +> This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. +> Qemu is started as such: +> qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait +> The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. + +This is probably a guest virtio driver bug. + +Vadim: Any known issues like this with 1.1.16? + +Stefan + + +On Sun, 2011-07-31 at 18:54 +0100, Stefan Hajnoczi wrote: +> On Sun, Jul 31, 2011 at 12:01 AM, Rick Vernam <email address hidden> wrote: +> > Public bug reported: +> > +> > Qemu host is Core i7, running Linux. Guest is Windows XP sp3. +> > Often, qemu will crash shortly after starting (1-5 minutes) with a statement "qemu-system-x86_64: virtio: trying to map MMIO memory" +> > This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. +> > Qemu is started as such: +> > qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait +> > The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. +> +> This is probably a guest virtio driver bug. +> +> Vadim: Any known issues like this with 1.1.16? +No, it something new to me. +Will try to reproduce and fix it. +Thank you, +Vadim. +> +> Stefan + + + + +Seems to only crash the first time qemu is started after booting the host machine. +After the first crash, qemu will run solid for days if the host machine is not rebooted. +If I have an opportunity, I'll test if it also crashes after first start when kvm and/or kvm_intel modules are unloaded and reloaded. + +I have the same problem. I'm using the packages from the Sergei ppa with spice enabled on a server with 9 windows xp machines and 1 linux (ubuntu 10.04) one. Ubuntu is rock solid and never crash, but the windows machines do randomnly. I've updated everything i could (using the version from spice-space.org), i've disabled the memory ballooning, disabled spice etc... but it's always the same. It just crash with that message. + +I guess it's a driver problem. I've searched on google and found some clues (there's a guy porting spice drivers to BSD and got that problem and could resolve it). + +If i can do a test that helps, here i am. I've tried a few things but i'm out of ideas. + +With my test, the only thing that all the machines had always enabled is the virtio storage driver. I've tried disabling the network one and the memory one but no luck, so maybe it's related to the harddisk controller. (i can't disable it because windows doesn't like to mess with the hard disk controller, you know). + +Thanks a lot ;-) + +Continues to occur with recently updated qxl, vdagent & virtio serial windows binaries from spice-space.org. +Also continues with qemu-kvm-0.15.0-rc1, qemu-0.15.0-rc1 & qemu-0.15.0-rc2 + +Vadim, + +Have you been able to reproduce this? +Do you require any additional information? + +Thanks, +-Rick + +Continues with Qemu 0.15.0 and Qemu-KVM 0.15.0 + +It's something related to Windows. I have in the same machine a linux server working with spice enabled and is rock solid. The windows machines crash with that error randomnly. + +So that would point to virtio. This appears to be the place for virtio bugs, correct? +Should I be doing anything to help usher this along? + +On Sun, Aug 14, 2011 at 7:11 AM, Rick Vernam <email address hidden> wrote: +> So that would point to virtio. This appears to be the place for virtio bugs, correct? +> Should I be doing anything to help usher this along? + +Either we need to help Vadim reproduce this so he can take a look. +Vadim: were you able to reproduce this? + +Or someone interested in Windows driver debugging can see if they can +debug this. The symptom is that the guest driver is placing invalid +descriptors into the vring. QEMU tries to map the memory and finds +the address is in a memory-mapped I/O region instead of a RAM region. +Normally the vring descriptors only point into RAM, so this is a guest +driver bug where the vring is being corrupted somehow. If anyone +wants to take a look I can try to help guide them along the +virtio-specifics. + +Stefan + + +Do you know if it's something related to the virtio net driver? anyone tried going to the e1000 only? i have some machines with e1000 and some of them with virtio-net, but i have crash no matter what driver is using (but the virtio driver is installed anyway, despite i'm using the e1000). + +I was searching in the git repository for windows drivers, (http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-windows.git;a=history;f=NetKVM/Common/ndis56common.h;hb=HEAD ) but couldn't find anything related to this. + +Any news? i can't debug the driver, i would do it if i knew how. + +David Rando. + +On Thu, Aug 25, 2011 at 3:53 PM, David Rando <email address hidden> wrote: +> Do you know if it's something related to the virtio net driver? anyone +> tried going to the e1000 only? i have some machines with e1000 and some +> of them with virtio-net, but i have crash no matter what driver is using +> (but the virtio driver is installed anyway, despite i'm using the +> e1000). +> +> I was searching in the git repository for windows drivers, +> (http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers- +> windows.git;a=history;f=NetKVM/Common/ndis56common.h;hb=HEAD ) but +> couldn't find anything related to this. +> +> Any news? i can't debug the driver, i would do it if i knew how. +> +> David Rando. +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/818673 +> +> Title: +> virtio: trying to map MMIO memory +> +> Status in QEMU: +> New +> +> Bug description: +> Qemu host is Core i7, running Linux. Guest is Windows XP sp3. +> Often, qemu will crash shortly after starting (1-5 minutes) with a statement "qemu-system-x86_64: virtio: trying to map MMIO memory" +> This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. +> Qemu is started as such: +> qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait +> The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/818673/+subscriptions + +Vadim, +Have you had any luck reproducing this issue or any advice for David? + +Thanks, +Stefan + + +On Thu, 2011-08-25 at 16:54 +0100, Stefan Hajnoczi wrote: +> On Thu, Aug 25, 2011 at 3:53 PM, David Rando <email address hidden> wrote: +> > Do you know if it's something related to the virtio net driver? anyone +> > tried going to the e1000 only? i have some machines with e1000 and some +> > of them with virtio-net, but i have crash no matter what driver is using +> > (but the virtio driver is installed anyway, despite i'm using the +> > e1000). +> > +> > I was searching in the git repository for windows drivers, +> > (http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers- +> > windows.git;a=history;f=NetKVM/Common/ndis56common.h;hb=HEAD ) but +> > couldn't find anything related to this. +> > +> > Any news? i can't debug the driver, i would do it if i knew how. +> > +> > David Rando. +> > +> > -- +> > You received this bug notification because you are a member of qemu- +> > devel-ml, which is subscribed to QEMU. +> > https://bugs.launchpad.net/bugs/818673 +> > +> > Title: +> > virtio: trying to map MMIO memory +> > +> > Status in QEMU: +> > New +> > +> > Bug description: +> > Qemu host is Core i7, running Linux. Guest is Windows XP sp3. +> > Often, qemu will crash shortly after starting (1-5 minutes) with a statement "qemu-system-x86_64: virtio: trying to map MMIO memory" +> > This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and qemu 0.15.0-rc1. +> > Qemu is started as such: +> > qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -daemonize -monitor telnet:localhost:12341,server,nowait +> > The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most current spice binaries from spice-space.org. +> > +> > To manage notifications about this bug go to: +> > https://bugs.launchpad.net/qemu/+bug/818673/+subscriptions +> +> Vadim, +> Have you had any luck reproducing this issue or any advice for David? +Guys, I'm sorry. Not yet. I'll try my best to trace this problem on the +following weekend. + +Best, +Vadim. + +> +> Thanks, +> Stefan + + + + +We're affected by this bug, too. Trying to find a workaround, last friday we changed VGA model to cirrus, and the machine is working properly without new entries in log. + +ping... + +I understand that Vadim must be very busy that he can't look at this - I can relate. +But is there really only one person in all of Qemu and/or Spice who can be addressed to look into this? + +So that I can plan around the viability of Qemu for my users, I need to know if the technologies I seek will be well maintained. + +Thanks, +-Rick + +I've made several unsuccessful attempts to reproduce this problem, +running VMs on top of F14 and RHEL6.2 + +The only one relatively close problem, reported by our QE, was +https://bugzilla.redhat.com/show_bug.cgi?id=727034 +It must be fixed in our internal repository. (Public repository +is out of sync, but I'm going to update it soon) + +I put our recent (WHQL candidates) drivers here: +http://people.redhat.com/vrozenfe/virtio-win-prewhql-0.1.zip + +Please give them a try and share your experience. + +Best, +Vadim. + +Still crashes just the same. +I updated the drivers for virt net, scsi & serial from the XP and WXp folders in the zip file that you referenced. +Then I shutdown the VM. +Because it only seems to happen every other time that Qemu is started, I started it back up and shut it down again. +Then the VM was started a third time and left idle prior to crashing. + +Thanks, and sorry that I didn't have better news. +(also, note that I've built qemu-kvm straight from www.linux-kvm.org, and qemu straight from qemu.org). + +-Rick + +so if I use -vga std instead of -vga qxl (and of course take out the -spice stuff), I don't crash. +perhaps this is spice/qxl related? + +sorry, scratch that last about -vga std ... it still crashed just the same using -vga std. + +Thank you, Rick. + +Could you help me to narrow this problem down? + +As I see, you have three virtio drivers installed on your system - block, net, and virtio serial. +Technically, anyone of them can create "trying to map MMIO memory" problem. +The best way to find a buggy driver ( or drivers) will be to isolate one from the other. +If you can, please try running only one virtio device every time to see which driver +sends incorrect scatter/gather list element to QEMU. + +Another question. You said, the problem happens after every second or third restart. +Do you shutdown your VM, or just restart it? How does it work after going through +several hibernate/resume, and/or suspend/resume cycles. + +Best regards, +Vadim. + +On Wednesday 14 September 2011 14:42:09 vrozenfe wrote: +> Thank you, Rick. +> +> Could you help me to narrow this problem down? +Absolutely. + +> +> As I see, you have three virtio drivers installed on your system - block, +> net, and virtio serial. Technically, anyone of them can create "trying to +> map MMIO memory" problem. The best way to find a buggy driver ( or +> drivers) will be to isolate one from the other. If you can, please try +> running only one virtio device every time to see which driver sends +> incorrect scatter/gather list element to QEMU. +Sure, no problem. I'll have that in the next few days. + +> +> Another question. You said, the problem happens after every second or third +> restart. Do you shutdown your VM, or just restart it? +Have to shut down the VM guest so that the qemu process exits. + +> How does it work +> after going through several hibernate/resume, and/or suspend/resume +> cycles. +I often will suspend with or without pausing qemu (via monitor commands 'stop' +and 'cont'). I have never experienced any problem with the qemu process that +was running prior to the suspend. + +> +> Best regards, +> Vadim. + +Thanks, +-Rik + + +On Wednesday 14 September 2011 16:30:11 Rick Vernam wrote: +> On Wednesday 14 September 2011 14:42:09 vrozenfe wrote: +> > Thank you, Rick. +> > +> > Could you help me to narrow this problem down? +> +> Absolutely. +> +> > As I see, you have three virtio drivers installed on your system - block, +> > net, and virtio serial. Technically, anyone of them can create "trying to +> > map MMIO memory" problem. The best way to find a buggy driver ( or +> > drivers) will be to isolate one from the other. If you can, please try +> > running only one virtio device every time to see which driver sends +> > incorrect scatter/gather list element to QEMU. +> +> Sure, no problem. I'll have that in the next few days. +I started qemu without any of the virt-serial stuff, specfically: +qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid - +drive file=/home/rick/qemu/hds/wxp.raw,if=virtio,aio=native -m 1536 -name WinXP +-net nic,model=virtio -net user -localtime -usb -vga qxl -spice +port=1234,disable-ticketing -monitor stdio + +It's been running for around 2 hours and no crash yet. + +Thanks, +-Rick + +> +> > Another question. You said, the problem happens after every second or +> > third restart. Do you shutdown your VM, or just restart it? +> +> Have to shut down the VM guest so that the qemu process exits. +> +> > How does it work +> > after going through several hibernate/resume, and/or suspend/resume +> > cycles. +> +> I often will suspend with or without pausing qemu (via monitor commands +> 'stop' and 'cont'). I have never experienced any problem with the qemu +> process that was running prior to the suspend. +> +> > Best regards, +> > Vadim. +> +> Thanks, +> -Rik + + +Thank you, Rick. + +I will start checking virtio-serial driver tomorrow. + +Best, +Vadim. + + +On Thursday 15 September 2011 11:23:53 Rick Vernam wrote: +> On Wednesday 14 September 2011 16:30:11 Rick Vernam wrote: +> > On Wednesday 14 September 2011 14:42:09 vrozenfe wrote: +> > > Thank you, Rick. +> > > +> > > Could you help me to narrow this problem down? +> > +> > Absolutely. +> > +> > > As I see, you have three virtio drivers installed on your system - +> > > block, net, and virtio serial. Technically, anyone of them can create +> > > "trying to map MMIO memory" problem. The best way to find a buggy +> > > driver ( or drivers) will be to isolate one from the other. If you +> > > can, please try running only one virtio device every time to see which +> > > driver sends incorrect scatter/gather list element to QEMU. +> > +> > Sure, no problem. I'll have that in the next few days. +> +> I started qemu without any of the virt-serial stuff, specfically: +> qemu-system-x86_64 -cpu host -enable-kvm -pidfile +> /home/rick/qemu/hds/wxp.pid - drive +> file=/home/rick/qemu/hds/wxp.raw,if=virtio,aio=native -m 1536 -name WinXP +> -net nic,model=virtio -net user -localtime -usb -vga qxl -spice +> port=1234,disable-ticketing -monitor stdio +> +> It's been running for around 2 hours and no crash yet. +So without virt-serial, the machine ran until I rebooted the guest OS, then +crashed with the same error message. Without virt-serial it seemed to be +stable so long as it was just left running. + +Now I'll run it without virt-net, and let you know how that goes. + +> +> Thanks, +> -Rick +> +> > > Another question. You said, the problem happens after every second or +> > > third restart. Do you shutdown your VM, or just restart it? +> > +> > Have to shut down the VM guest so that the qemu process exits. +> > +> > > How does it work +> > > after going through several hibernate/resume, and/or suspend/resume +> > > cycles. +> > +> > I often will suspend with or without pausing qemu (via monitor commands +> > 'stop' and 'cont'). I have never experienced any problem with the qemu +> > process that was running prior to the suspend. +> > +> > > Best regards, +> > > Vadim. +> > +> > Thanks, +> > -Rik + + +On Friday 16 September 2011 03:52:34 hkran wrote: +[snip] +> +> I have tried many times with many restarts or shutdown-and-boot xp guest +> but failed to meet the crashing. +> (I am using the virtio drivers referenced in the earlier mail list.) +> my command: +> +> /home/huikai/qemu15/bin/qemu --enable-kvm -m 768 -drive +> file=/home/huikai/winxp_dev.img,if=virtio -net nic,model=virtio -net +> user -usb -usbdevice tablet -localtime -vga qxl -device virtio-serial +> -chardev spicevmc,name=vdagent,id=vdagent -device +> virtserialport,chardev=vdagent,name=spice0 -spice +> port=1234,disable-ticketing -monitor telnet:localhost:12341,server,nowait + +Okay, I tried a variation of that: +qemu-system-x86_64 -cpu host -enable-kvm -m 1536 -pidfile +/home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio +-net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial +-chardev spicevmc,name=vdagent,id=vdagent -device +virtserialport,chardev=vdagent,name=spice0 -spice port=1234,disable-ticketing +-monitor telnet:localhost:12341,server,nowait + +And it's been running stable all day. +The differences between the command line that crashes and yours are: +- yours doesn't have "aio=native" in the -drive declaration. +- yours has some differences in the virtio-serial device declaration. +- yours has some differences in the virtserialport device declaration. + +As time permits I'm going to try each of those differences individually. + +Thanks, +-Rick + + +On Friday 16 September 2011 12:42:02 Rick Vernam wrote: +> On Friday 16 September 2011 03:52:34 hkran wrote: +> [snip] +> +> > I have tried many times with many restarts or shutdown-and-boot xp guest +> > but failed to meet the crashing. +> > (I am using the virtio drivers referenced in the earlier mail list.) +> > my command: +> > +> > /home/huikai/qemu15/bin/qemu --enable-kvm -m 768 -drive +> > file=/home/huikai/winxp_dev.img,if=virtio -net nic,model=virtio -net +> > user -usb -usbdevice tablet -localtime -vga qxl -device virtio-serial +> > -chardev spicevmc,name=vdagent,id=vdagent -device +> > virtserialport,chardev=vdagent,name=spice0 -spice +> > port=1234,disable-ticketing -monitor +> > telnet:localhost:12341,server,nowait +> +> Okay, I tried a variation of that: +> qemu-system-x86_64 -cpu host -enable-kvm -m 1536 -pidfile +> /home/rick/qemu/hds/wxp.pid -drive +> file=/home/rick/qemu/hds/wxp.raw,if=virtio -net nic,model=virtio -net user +> -localtime -usb -vga qxl -device virtio-serial -chardev +> spicevmc,name=vdagent,id=vdagent -device +> virtserialport,chardev=vdagent,name=spice0 -spice +> port=1234,disable-ticketing -monitor telnet:localhost:12341,server,nowait +> +> And it's been running stable all day. +> The differences between the command line that crashes and yours are: +> - yours doesn't have "aio=native" in the -drive declaration. +> - yours has some differences in the virtio-serial device declaration. +> - yours has some differences in the virtserialport device declaration. + +I added "aio=native" and it crashed. +If it helps, I ran config like so: +./configure --target-list=x86_64-softmmu --disable-curses --disable-curl -- +audio-drv-list=alsa --audio-card-list=sb16,ac97,hda --enable-vnc-thread -- +disable-bluez --enable-vhost-net --enable-spice + +and I've attached config.log, as well as the output of configure. + +Thanks, +-Rick + + +On Friday 16 September 2011 12:42:02 Rick Vernam wrote: +> On Friday 16 September 2011 03:52:34 hkran wrote: +> [snip] +> +> > I have tried many times with many restarts or shutdown-and-boot xp guest +> > but failed to meet the crashing. +> > (I am using the virtio drivers referenced in the earlier mail list.) +> > my command: +> > +> > /home/huikai/qemu15/bin/qemu --enable-kvm -m 768 -drive +> > file=/home/huikai/winxp_dev.img,if=virtio -net nic,model=virtio -net +> > user -usb -usbdevice tablet -localtime -vga qxl -device virtio-serial +> > -chardev spicevmc,name=vdagent,id=vdagent -device +> > virtserialport,chardev=vdagent,name=spice0 -spice +> > port=1234,disable-ticketing -monitor +> > telnet:localhost:12341,server,nowait +> +> Okay, I tried a variation of that: +> qemu-system-x86_64 -cpu host -enable-kvm -m 1536 -pidfile +> /home/rick/qemu/hds/wxp.pid -drive +> file=/home/rick/qemu/hds/wxp.raw,if=virtio -net nic,model=virtio -net user +> -localtime -usb -vga qxl -device virtio-serial -chardev +> spicevmc,name=vdagent,id=vdagent -device +> virtserialport,chardev=vdagent,name=spice0 -spice +> port=1234,disable-ticketing -monitor telnet:localhost:12341,server,nowait +> +> And it's been running stable all day. +> The differences between the command line that crashes and yours are: +> - yours doesn't have "aio=native" in the -drive declaration. +> - yours has some differences in the virtio-serial device declaration. +> - yours has some differences in the virtserialport device declaration. +> +> As time permits I'm going to try each of those differences individually. +Without "aio=native" ... +in the definition of virtserialport, I changed "name=spice0" to +"name=com.redhat.spice.0" - with this change, the guest vdagent works, but it +crashed... + +> +> Thanks, +> -Rick + + +On Friday 23 September 2011 14:07:17 Alon Levy wrote: +> On Thu, Sep 22, 2011 at 02:10:04PM -0500, Rick Vernam wrote: +> > On Friday 16 September 2011 12:42:02 Rick Vernam wrote: +> > > On Friday 16 September 2011 03:52:34 hkran wrote: +> > > [snip] +> > > +> > > > I have tried many times with many restarts or shutdown-and-boot xp +> > > > guest but failed to meet the crashing. +> > > > (I am using the virtio drivers referenced in the earlier mail list.) +> > > > my command: +> > > > +> > > > /home/huikai/qemu15/bin/qemu --enable-kvm -m 768 -drive +> > > > file=/home/huikai/winxp_dev.img,if=virtio -net nic,model=virtio -net +> > > > user -usb -usbdevice tablet -localtime -vga qxl -device +> > > > virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device +> > > > virtserialport,chardev=vdagent,name=spice0 -spice +> > > > port=1234,disable-ticketing -monitor +> > > > telnet:localhost:12341,server,nowait +> > > +> > > Okay, I tried a variation of that: +> > > qemu-system-x86_64 -cpu host -enable-kvm -m 1536 -pidfile +> > > /home/rick/qemu/hds/wxp.pid -drive +> > > file=/home/rick/qemu/hds/wxp.raw,if=virtio -net nic,model=virtio -net +> > > user -localtime -usb -vga qxl -device virtio-serial -chardev +> > > spicevmc,name=vdagent,id=vdagent -device +> > > virtserialport,chardev=vdagent,name=spice0 -spice +> > > port=1234,disable-ticketing -monitor +> > > telnet:localhost:12341,server,nowait +> > > +> > > And it's been running stable all day. +> > > The differences between the command line that crashes and yours are: +> > > - yours doesn't have "aio=native" in the -drive declaration. +> > > - yours has some differences in the virtio-serial device declaration. +> > > - yours has some differences in the virtserialport device declaration. +> > > +> > > As time permits I'm going to try each of those differences +> > > individually. +> > +> > Without "aio=native" ... +> > in the definition of virtserialport, I changed "name=spice0" to +> > "name=com.redhat.spice.0" - with this change, the guest vdagent works, +> > but it crashed... +> +> If you provide details on the crash maybe someone can help. +This email thread has details early on the thread, and there is a bug report +here: https://bugs.launchpad.net/bugs/818673 +All the details of the crash that are available to me are previously +described. + +> +> > > Thanks, +> > > -Rick + + +Vadim, + +Did you see comment #27? Is that helpful, would you like any additional info? Are there other things you would like for me to try? + +Thanks, +-Rick + +So I've built qemu with -enable-debug and tried running with an attached GDB, but got nothing. +I've never tried to debug Qemu before, but I know it's not quite a simple as debugging other apps. +I am honestly clueless about how to further debug this problem. + +Should I give up on using virtio-serial for spice vdagent integration? +It seems that nobody really has any interest in this problem. + +Are other people using qemu with spice (including functional guest agent support, copy/paste, etc)? How? +I know hkran posted how (s)he uses qemu without hitting this bug, but when I use qemu in that way, I loose guest agent. + +I like to fix things myself, and I hate to be asking about this when everybody clearly has more interesting things to do. +I just need some input so that I can have realistic expectations. + +Thanks, +-Rick + +I've been dealing with this bug for some time on Fedora. Until recently, I was using the VirtIO drivers from RHEV 2.2, which don't suffer from this problem. As of Fedora 16, however, that isn't an option, because they cause the guest to blue-screen early in the boot process. + +So ... I've been doing some more testing with the following setup: + + Host: + Intel DQ67SW motherboard with Q67 chipset (including IOMMU) + BIOS version SWQ6710H.86A.0050.2011.0401.1409 (release date 04/01/2011) + Intel Core i7 2600, 4-cores, 8 threads, 3.4 GHz + 16GB memory + Fedora 15 64-bit, fully updated including updates-testing repo + qemu-kvm-0.14.0-8.fc15.x86_64 + libvirt-0.8.8-7.fc15.x86_64 + kernel-2.6.41.6-1.fc15.x86_64 + + Guest: + Windows 7 Professional 32-bit, fully updated + 2 VCPUs + 3.5GB memory + Red Hat VirtIO Ethernet Adapter driver version 6.0.209.605 (9/20/2010) + Red Hat VirtIO SCSI Controller driver version 6.0.0.10 (9/20/2010) + (No VirtIO serial ports or channels defined) + +(The VirtIO drivers are from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/.) + +I have determined that disabling the Intel IOMMU has no effect; the problem still occurs. + +Perhaps more interestingly, it seems that the problem only occurs when I am using the VirtIO SCSI *and* the VirtIO Ethernet drivers. It seems that the problem does not occur if I only use one of the drivers; an IDE disk with a VirtIO NIC seems to be stable, as does a VirtIO disk with an e1000 NIC. + +Now to the big question ... what the heck can be done to get this problem fixed? I hope that everyone agrees that it's totally unacceptable for a problem like this to sit unfixed for so long. I am more than willing to test any patches, enable +debugging, etc.; just tell me what to do. + +Thanks! + +Two other observations: + +* The problem is also present in the latest drivers in the RHEL 6.2 virtio-win package (both driver versions 60.62.102.3000, dates 9/12/2011). +* The problem does not seem to occur if the guest has only 1 VCPU. + +So the problem only occurs when using 2 VirtIO devices with 2 VCPUs. This leads me to speculate that there is some sort of VirtIO "core" that is shared between the 2 devices, and that there is some sort of race condition or locking problem in that core. + +In reply to comment #32, I encounter this problem with 1VCPU - see the original description of the bug. +Also note that after qemu quits with the error, the subsequent execution of the same qemu invocation will run stable. + + +And I have this bug! +Linux test-2 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux +In container i have Windows XP SP3 + +In log: +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 2048 -sm +p 2 -name boss_xp -uuid 9041090d-acee-da4a-921d-238f2a43be64 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/boss_xp.monitor,server,nowait -monitor cha +rdev:monitor -localtime -boot c -drive file=/root/boss_xp.qcow2,if=virtio,index=0,boot=on,format=raw,cache=none -drive file=/home/admino/virtio-win-1.1.16.is +o,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:49:83:6c,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -chardev pty,id +=serial0 -serial chardev:serial0 -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:2 -k en-us -vga cirrus +char device redirected to /dev/pts/3 +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" +virtio_ioport_write: unexpected address 0x13 value 0x1 +virtio: trying to map MMIO memory + +After this Windows go shutdown. +I tried this (in log): + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 2048 -sm +p 2 -name boss_xp -uuid 9041090d-acee-da4a-921d-238f2a43be64 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/boss_xp.monitor,server,nowait -monitor cha +rdev:monitor -localtime -boot c -drive file=/root/boss_xp.qcow2,if=virtio,index=0,boot=on,format=raw,cache=none -drive file=/home/admino/virtio-win-1.1.16.is +o,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:49:83:6c,vlan=0,model=rtl8139,name=rtl8139.0 -net tap,fd=43,vlan=0,name=tap.0 -chardev pty, +id=serial0 -serial chardev:serial0 -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:2 -k en-us -vga cirrus +char device redirected to /dev/pts/3 +pci_add_option_rom: failed to find romfile "pxe-rtl8139.bin" +virtio: trying to map MMIO memory +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 2048 -sm +p 2 -name boss_xp -uuid 9041090d-acee-da4a-921d-238f2a43be64 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/boss_xp.monitor,server,nowait -monitor cha +rdev:monitor -localtime -boot c -drive file=/root/boss_xp.qcow2,if=virtio,index=0,boot=on,format=raw,cache=none -drive file=/home/admino/virtio-win-1.1.16.is +o,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:49:83:6c,vlan=0,model=rtl8139,name=rtl8139.0 -net tap,fd=43,vlan=0,name=tap.0 -chardev pty, +id=serial0 -serial chardev:serial0 -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:2 -k en-us -vga cirrus +char device redirected to /dev/pts/3 +pci_add_option_rom: failed to find romfile "pxe-rtl8139.bin" +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 2048 -sm +p 1 -name boss_xp -uuid 9041090d-acee-da4a-921d-238f2a43be64 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/boss_xp.monitor,server,nowait -monitor cha +rdev:monitor -localtime -boot c -drive file=/root/boss_xp.qcow2,if=virtio,index=0,boot=on,format=raw,cache=none -drive file=/home/admino/virtio-win-1.1.16.is +o,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:49:83:6c,vlan=0,model=rtl8139,name=rtl8139.0 -net tap,fd=43,vlan=0,name=tap.0 -chardev pty, +id=serial0 -serial chardev:serial0 -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:2 -k en-us -vga cirrus +char device redirected to /dev/pts/3 +pci_add_option_rom: failed to find romfile "pxe-rtl8139.bin" +virtio: trying to map MMIO memory + +Its log i got within the limits of 15 minuts. + +Now i try this config: +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 2048 -sm +p 1 -name boss_xp -uuid 9041090d-acee-da4a-921d-238f2a43be64 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/boss_xp.monitor,server,nowait -monitor cha +rdev:monitor -localtime -boot c -drive file=/root/boss_xp.qcow2,if=virtio,index=0,boot=on,format=raw,cache=none -drive file=/home/admino/virtio-win-1.1.16.is +o,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:49:83:6c,vlan=0,model=rtl8139,name=rtl8139.0 -net tap,fd=43,vlan=0,name=tap.0 -serial none +-parallel none -usb -usbdevice tablet -vnc 127.0.0.1:2 -k en-us -vga cirrus +pci_add_option_rom: failed to find romfile "pxe-rtl8139.bin" + +I Will write later with result. + +ps sorry for English + +And more: i have too more virtual PC with WindowsXP SP3 and with one CPU, but them doesnt have any problems. Maybe this bug depends on 2 and more CPU?? + +I experience this on uni-processor. + +On Tuesday 24 January 2012 16:48:04 Vitalis wrote: +> And more: i have too more virtual PC with WindowsXP SP3 and with one +> CPU, but them doesnt have any problems. Maybe this bug depends on 2 and +> more CPU?? + + +Does this Bug similiar with https://bugzilla.redhat.com/show_bug.cgi?id=771390 ? + +Yes, I would say it is the same bug. I will test the driver that Vadim linked in Comment 33 (https://bugzilla.redhat.com/show_bug.cgi?id=771390#c33) and report back. + +Thanks, Mike, for posting here. + +well, the link in the redhat bug, comment 33, is no good apparently. I will follow that bug, and test when I see Vadim has posted a new driver to test. + +Now have next config and bug still: +/usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 2048 -smp 1 -name boss_xp -uuid 9041090d-acee-da4a-921d-238f2a43be64 -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/boss_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/boss_xp.qcow2,if=virtio,index=0,boot=on,format=raw,cache=none -drive file=/home/admino/virtio-win-1.1.16.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:49:83:6c,vlan=0,model=rtl8139,name=rtl8139.0 -net tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:2 -k en-us -vga cirrus + + +It was a long journey. +But now it seem like we've managed to fix this problem. +https://bugzilla.redhat.com/show_bug.cgi?id=771390#c45 + +I put new drivers here: +http://people.redhat.com/vrozenfe/vioscsi.vfd + +Best regards, +Vadim. + +Thanks! Where can I get ISO of new drivers pack? for Ubuntu 10.04 + +Vadim, Could this be related to the hangs during boot with qxl and virtio-serial in a single windows vm? + +Alon + +I have no idea regarding Ubuntu, but you can find the new drivers +at Fedora project site +http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/virtio-win-0.1-22.iso + +Hi Alon, +Unfortunately, qxl and virtio-serial +hang is a different problem. + + +Hello with bad news! I have: + +virtio_ioport_write: unexpected address 0x13 value 0x1 + +on config: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 +1c1839e4ba -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowait -monitor chardev:monitor -localtime -boot c -drive file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw +,cache=none -drive file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,format=raw -net nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net tap,fd=43,vlan=0,name=tap.0 -serial +none -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus +pci_add_option_rom: failed to find romfile "pxe-virtio.bin" + +with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012 x86_64 GNU/Linux +qemu drivers are virtio-win-0.1-22.iso + +Anybody help me? + + +According to comment 41, this bug has been fixed, so I'm setting the status to "Fix released" now ... Vitalis, your problem from comment 46 sounds differently - if it still persists today, please open a new bug ticket for this instead. + diff --git a/results/classifier/118/unknown/854 b/results/classifier/118/unknown/854 new file mode 100644 index 00000000..6cd8874e --- /dev/null +++ b/results/classifier/118/unknown/854 @@ -0,0 +1,92 @@ +risc-v: 0.898 +debug: 0.879 +ppc: 0.874 +virtual: 0.864 +permissions: 0.863 +vnc: 0.861 +peripherals: 0.858 +VMM: 0.857 +user-level: 0.857 +hypervisor: 0.854 +performance: 0.853 +register: 0.853 +device: 0.851 +assembly: 0.843 +arm: 0.842 +architecture: 0.839 +semantic: 0.837 +PID: 0.833 +network: 0.832 +files: 0.832 +graphic: 0.829 +KVM: 0.829 +TCG: 0.823 +x86: 0.819 +kernel: 0.815 +socket: 0.793 +mistranslation: 0.774 +i386: 0.754 +boot: 0.746 + +rsync to ext4-fs on dynamic expanding qcow2 fails +Description of problem: +Firstly, this issue does not seem to happen when the virtual-disk is dd-raw-img or fixed qcow2 (preallocation=falloc). The guest-kernel has multiple tracebacks during rsync to dst folder on ext4-fs on qcow2. +I ctrl-C-ed the rsync process after the first traceback, which happened after copying around 52 GiB. +On a previous run, wherein I had let it continue, somewhere near the end, around 83 GiB, dmesg would bloat with a zillion trace-backs and stall. The sha256sum verify seems to have succeeded for all files copied so far and correctly gives error "Failed open or read" on subsequent files that were not copied. +In this test, the partial-rsync completed files were not corrupted. However, as qemu's disk emulation allocates blocks, qemu may be inducing paging-bugs into the guest-kernel. Paging issues like these may also lead to corruption. The guest-kernel should see the same full emulated disk regardless of whether qemu provided a fixed disk, dynamic disk, or even a different type of virtual-disk-format. The guest-vm should not detect/perceive any difference between them. + +There may be upcoming trouble round the 5.17 corner. + +It is beyond me to figure out if this is due to +* qemu-6.2 block code +* guest-kernel ( kernel-5.17 folio/page management or ntfs3 driver or something else ) + +It may be necessary to ascertain if this is a new bug on account of qemu not being ready for folio type page-management or a bug in upstream kernel.org. My apologies in advance if it turns out that this is not a qemu bug. + +There there does seem to be some problem with qemu dealing with expanding virtual disks, with bugs that show up only if the underlying virtual-disk is dynamic and expanding. + +I just think that storage/block-code should be made rock solid with a much higher priority than adding new features. +If storage code is undependable, then qemu/vm cannot be used, and there is no point in any other feature. qcow2 in particular is the qemu's native virtual-disk format. + +I had to stop testing on Issue #727 , Issue #814 , on account of what I thought was a bug in 5.15 kernels. I filed the bug as "fs/ntfs3: page_cache_ra_unbounded on rsync from ntfs3 to ext4" https://bugzilla.kernel.org/show_bug.cgi?id=215460 . I assume that bug is different because it happens even on raw image. + +setup is as follows: +- Host: Fedora-35 with kernel-5.17.0-0.rc2.83.fc35.x86_64 self-built from srpm ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1910212 ) +- Guest: Fedora-Workstation-Live-x86_64-Rawhide-20220201.n.0.iso with 5.17.0-0.rc2.83.fc36.x86_64 ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1910892 ) +- qemu: 6.2.0 (qemu-6.2.0-2.fc35.1) self-built from srpm ( https://koji.fedoraproject.org/koji/buildinfo?buildID=1897713 ) +- hda: qcow2(dyn) with ext4 and also 4 combinations of raw_img/fixed_qcow2 with ext4/ntfs3 +- hdb: vhdx, ntfs3 (pre-prepared sgdata https://gitlab.com/qemu-project/qemu/-/issues/727#note_739930694 ) + +qcow2 image is created as follows: +``` +[root@sirius ~]# qemu-img create -f qcow2 /mnt/a16/gkpics01.qcow2 99723771904 +Formatting '/mnt/a16/gkpics01.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=99723771904 lazy_refcounts=off refcount_bits=16 +``` + +qemu command is as follows: +``` +[root@sirius ~]# qemu-system-x86_64 -cpu qemu64 -m 4096 -machine "type=q35" -accel "kvm" -smp "sockets=1,cores=8,threads=1" -boot "d" -cdrom "/vol/15KJ_Images/transcend/Fedora-Workstation-Live-x86_64-Rawhide-20220201.n.0.iso" -hda "/mnt/a16/gkpics01.raw" -hdb "/vol/15KJ_Images/test/sgdata.vhdx" -device "virtio-vga" -display "gtk,gl=on" -rtc "base=utc" -net "user" -device "virtio-net,netdev=vmnic" -netdev "user,id=vmnic,net=192.168.20.0/24,dns=192.168.20.3,dhcpstart=192.168.20.15" +``` +Steps to reproduce: +1. Inside booted vm, use gdisk to partition /dev/sda1 if necessary +2. ```dmesg -w (in another pty)``` +3. ```mkfs.ext4 /dev/sda1 -L fs_gkpics001``` +4. ```mkdir /mnt/a /mnt/b``` +5. ```mount -t ext4 /dev/sda1 /mnt/a``` +6. ```mount -t ntfs3 /dev/sdb2 /mnt/b``` +7. rsync testdata: ```(sdate=`date` ; echo "$sdate" ; cd /mnt/b ; rsync -avH ./photos001 /mnt/a | tee /tmp/rst.txt ; echo "$sdate" ; date )``` +8. ```umount /mnt/a ; ``` +9. ```mount -t ext4 /dev/sda1 /mnt/a``` +10. verify: ```(sdate=`date` ; echo "$sdate" ; cd /mnt/a/photos001 ; sha256sum -c ./find.CHECKSUM --quiet ; echo "$sdate" ; date )``` +11. ```umount /mnt/a ; umount /mnt/b;``` +Additional information: +**Test attempts** +- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/rawimg/ext4 with vhdx/ntfs3/sgdata +- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/rawimg/ntfs3 with vhdx/ntfs3/sgdata +- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/qcow2(fixed)/ext4 with vhdx/ntfs3/sgdata +- Bug does not happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/qcow2(fixed)/ntfs3 with vhdx/ntfs3/sgdata +- Bug **does** happen with 5.17.0-0.rc2.83/qemu-6.2.0-2/5.17.0-0.rc2.83/ExFAT/**qcow2(dyn)**/ext4 with vhdx/ntfs3/sgdata +- Bug does not happen directly on Host with 5.17.0-0.rc2.83/ExFat with ntfs3/sgdata +- Bug does not happen directly on Host with 5.17.0-0.rc2.83/ntfs3 with ntfs3/sgdata + +Also filed a linux-kernel bug titled "during rsync, vm guest kernel trace arising from memcg_kmem_charge_page alloc_pages" https://bugzilla.kernel.org/show_bug.cgi?id=215563 diff --git a/results/classifier/118/unknown/899961 b/results/classifier/118/unknown/899961 new file mode 100644 index 00000000..12d3756a --- /dev/null +++ b/results/classifier/118/unknown/899961 @@ -0,0 +1,187 @@ +debug: 0.912 +boot: 0.893 +user-level: 0.866 +performance: 0.857 +permissions: 0.854 +virtual: 0.850 +device: 0.849 +KVM: 0.847 +x86: 0.845 +register: 0.842 +VMM: 0.837 +peripherals: 0.835 +hypervisor: 0.833 +arm: 0.833 +socket: 0.832 +vnc: 0.831 +architecture: 0.826 +semantic: 0.822 +graphic: 0.818 +ppc: 0.815 +mistranslation: 0.812 +files: 0.811 +assembly: 0.810 +PID: 0.810 +TCG: 0.803 +i386: 0.803 +kernel: 0.796 +risc-v: 0.785 +network: 0.783 + +qemu/kvm locks up when run 32bit userspace with 64bit kernel + +Applies to both qemu and qemu-kvm 1.0, but only when kernel is 64bit and userspace is 32bit, on x86. Did not happen with previous released versions, such as 0.15. Not all guests triggers this issue - so far, only (32bit) windows 7 guest shows it, but does that quite reliable: first boot of an old guest with new qemu (or qemu-kvm), windows finds a new CPU and suggests rebooting - hit "Reboot" and in a few seconds it will be locked up (including the monitor), with 100% CPU usage. Killable with -9. + +Actually after trying to do lots of experiments and finally a git bisection, it turned out that the issue only affects qemu-kvm, not upstream qemu. Bisection between qemu-kvm 0.15.0 and 1.0 lead to this commit: + +commit 145e11e840500e04a4d0a624918bb17596be19e9 +Merge: ce967f6 b195043 +Author: Avi Kivity <email address hidden> +Date: Wed Aug 10 12:06:58 2011 +0300 + + Merge commit 'b195043003d90ea4027ea01cc7a6c974ac915108' into upstream-merge + + * commit 'b195043003d90ea4027ea01cc7a6c974ac915108': (130 commits) + ... + +After which I'm stuck... ;) + +And some more info. Debugging with gdb shows this: + +(gdb) info threads + Id Target Id Frame + 2 Thread 0xf6d4eb70 (LWP 28697) "qemu-system-x86" 0xf7711425 in __kernel_vsyscall () +* 1 Thread 0xf6f50700 (LWP 28694) "qemu-system-x86" 0xf7711425 in __kernel_vsyscall () +(gdb) bt +#0 0xf7711425 in __kernel_vsyscall () +#1 0xf76d620a in __pthread_cond_wait (cond=0x840fa60, mutex=0x89e82f0) + at pthread_cond_wait.c:153 +#2 0x080e8bb5 in qemu_cond_wait (cond=0x840fa60, mutex=0x89e82f0) + at /build/kvm/git/qemu-thread-posix.c:113 +#3 0x08050c2e in run_on_cpu (env=0x9466460, + func=0x8083ad0 <do_kvm_cpu_synchronize_state>, data=0x9466460) + at /build/kvm/git/cpus.c:715 +#4 0x08083b63 in kvm_cpu_synchronize_state (env=0x9466460) + at /build/kvm/git/kvm-all.c:927 +#5 0x0804faaa in cpu_synchronize_state (env=0x9466460) + at /build/kvm/git/kvm.h:173 +#6 0x0804fc3a in cpu_synchronize_all_states () at /build/kvm/git/cpus.c:94 +#7 0x080647ec in main_loop () at /build/kvm/git/vl.c:1421 +#8 0x0806974d in main (argc=17, argv=0xff996e04, envp=0xff996e4c) + at /build/kvm/git/vl.c:3395 +(gdb) frame 2 +#2 0x080e8bb5 in qemu_cond_wait (cond=0x840fa60, mutex=0x89e82f0) + at /build/kvm/git/qemu-thread-posix.c:113 +113 err = pthread_cond_wait(&cond->cond, &mutex->lock); +(gdb) +(gdb) thread 2 +[Switching to thread 2 (Thread 0xf6d4eb70 (LWP 28697))] +#0 0xf7711425 in __kernel_vsyscall () +(gdb) bt +#0 0xf7711425 in __kernel_vsyscall () +#1 0xf727ac89 in ioctl () at ../sysdeps/unix/syscall-template.S:82 +#2 0x08084004 in kvm_vcpu_ioctl (env=0x9466460, type=44672) + at /build/kvm/git/kvm-all.c:1090 +#3 0x08083cd8 in kvm_cpu_exec (env=0x9466460) at /build/kvm/git/kvm-all.c:976 +#4 0x08050f44 in qemu_kvm_cpu_thread_fn (arg=0x9466460) + at /build/kvm/git/cpus.c:806 +#5 0xf76d1c39 in start_thread (arg=0xf6d4eb70) at pthread_create.c:304 +#6 0xf728296e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 +Backtrace stopped: Not enough registers or memory available to unwind further + +which is not entirely interesting, but: + +when exiting gdb (I attached it to a running process), the whole thing unfreezes and continue its work as usual, if no lockup ever occured -- ie, it is enough to attach gdb to a locked up process and quit gdb - enough to unfreeze it. Also, when running under gdb, the lockup does not occur - I can reboot the guest at will any times, it all goes fine. Once gdb is detached, reboot immediately results in a lockup again - which - again - can be "cured" by attaching and detaching gdb to the process. + +And one more correction for the original report. When locked up, it does NOT use 100% CPU - CPU is 100% _idle_. + +On 12/04/2011 07:45 PM, Michael Tokarev wrote: +> Actually after trying to do lots of experiments and finally a git +> bisection, it turned out that the issue only affects qemu-kvm, not +> upstream qemu. Bisection between qemu-kvm 0.15.0 and 1.0 lead to this +> commit: +> +> commit 145e11e840500e04a4d0a624918bb17596be19e9 +> Merge: ce967f6 b195043 +> Author: Avi Kivity <email address hidden> +> Date: Wed Aug 10 12:06:58 2011 +0300 +> +> Merge commit 'b195043003d90ea4027ea01cc7a6c974ac915108' into upstream-merge +> +> * commit 'b195043003d90ea4027ea01cc7a6c974ac915108': (130 commits) +> ... +> +> After which I'm stuck... ;) +> + +32-on-64 doesn't build on Fedora due to glib2-devel.i686 conflicting +with its x86_64 cousin, so I can't reproduce this. Can you try +bisecting this further? + +$ git tag M b195043003d90ea4027ea01cc7a6c974ac915108 +$ git bisect start M M^ +... +$ git merge --no-commit M^ +[build and test] +$ git merge --abort (or git checkout -f) +$ git bisect [good|bad] + +if it happens that M^2 was the bad commit, you'll get a merge conflict. +In that case do + +$ git merge --abort +$ git merge M + +(you'll just be testing M again, but it's good to verify) + +-- +error compiling committee.c: too many arguments to function + + + +I tried bisecting it today, again. I think you did mean 145e11e840500e04a4d0a624918bb17596be19e9 as the "M" point (the large merge), not b195043003d90ea4027ea01cc7a6c974ac915108 (which is the first commit in that merge) ;) Actually I did the same already, just didn't post to the bugreport. But anyway. + +The first bad commit inside the merge which shows the bad behavour is: + +commit 68d100e905453ebbeea8e915f4f18a2bd4339fe8 +Author: Kevin Wolf <email address hidden> +Date: Thu Jun 30 17:42:09 2011 +0200 + + qcow2: Use coroutines + +Note: the issue happens only with qcow2 being in use so far, directly or indirectly with -snapshot. + +Also note that it only happens within kvm tree, ie: + + git checkout 68d100e905453ebbeea8e915f4f18a2bd4339fe8 + git merge --no-commit 145e11e840500e04a4d0a624918bb17596be19e9^ # the pre-merge point + +I tried to debug it further but without much success. + +I'm attaching an strace the above source (with a few debug fprintf(stderr)s added into qcow2 source around lock/unlock calls) running winXP guest from point where I hit "Reboot" button and up to the point where it stalls. Search for "qcow2: mutex_unlock" from the _end_ of the file. + +What I also observed is -- it looks like it merely loses an interrupt somewere, it is enough to Ctrl+Z/fg it or to attach/detach strace to the process for it to "unstuck" and continue executing. Attaching gdb also makes it unstuck as demonstrated initially. + +This qcow2 commit may actually be innocent: it just started using coroutines, and that's where the bug/problem might be, say, 64bit kernel gets confused by the process switching stack for example? I dunno. + +Note again that switching to alternative coroutine implementations makes the issue go away. Ie, it only happens with mkcontext&Co coroutine implementation, and the commit which git bisect found to be "guilty" is the one which makes usage of coroutines. + + +After some more digging I found out that qemu also has this very issue, but it happens a bit differently. In particular, this very same winXP test guest freezes in upstream qemu with -enable-kvm on _shutdown_, not on restart. In qemu-kvm it happens on restart but not on shutdown. + +And bisecting plain qemu leads to this commit: + +commit 12d4536f7d911b6d87a766ad7300482ea663cea2 +Author: Anthony Liguori <email address hidden> +Date: Mon Aug 22 08:24:58 2011 -0500 + + main: force enabling of I/O thread + +As far as I remember, qemu-kvm always had iothread enabled, that's why the bug initially was only reproducible on qemu-kvm. + +Forgot to mention: tcg appears to be unaffected - so far anyway. + +The bug in Debian has been marked as "Fix released", so I assume this has been fixed in upstream QEMU, too? Or is there still anything left to do here? + +Since the debian bug has been marked as fixed and there wasn't any response to the question in my last comment, I assume this has been fixed in upstream QEMU, too. So closing this ticket accordingly... + diff --git a/results/classifier/118/unknown/932487 b/results/classifier/118/unknown/932487 new file mode 100644 index 00000000..1edd5c2e --- /dev/null +++ b/results/classifier/118/unknown/932487 @@ -0,0 +1,647 @@ +performance: 0.895 +user-level: 0.883 +device: 0.882 +debug: 0.860 +register: 0.860 +architecture: 0.856 +arm: 0.855 +permissions: 0.840 +mistranslation: 0.838 +virtual: 0.825 +semantic: 0.824 +PID: 0.817 +boot: 0.814 +socket: 0.812 +peripherals: 0.811 +risc-v: 0.808 +TCG: 0.804 +graphic: 0.802 +kernel: 0.799 +assembly: 0.796 +vnc: 0.784 +VMM: 0.779 +files: 0.776 +hypervisor: 0.769 +KVM: 0.760 +i386: 0.759 +ppc: 0.733 +network: 0.727 +x86: 0.717 + +win32: git rev 59f971d crashes when accessing disk (coroutine issue) + +Host: XP SP3 / Vista SP2 + +configure commandline: ./configure --target-list="i386-softmmu" --audio-drv-list=sdl --audio-card-list=ac97,sb16,adlib --disable-linux-aio --disable-vnc-thread --disable-vnc-jpeg --extra-cflags="-O0 -pipe" + +gcc -v: +Using built-in specs. +Target: mingw32 +Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32' +Thread model: win32 +gcc version 4.3.3 (4.3.3-tdm-1 mingw32) + +gdb output: +C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios -hda xp.vmdk +GNU gdb (GDB) 7.3 +Copyright (C) 2011 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "mingw32". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... +done. +(gdb) r +Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios -hda xp.vmdk +[New Thread 2472.0x8e0] +[New Thread 2472.0xdc4] +[New Thread 2472.0x8f0] + +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 2472.0x8f0] +0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +(gdb) bt +#0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +#1 0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8, + action=COROUTINE_YIELD) at coroutine-win32.c:48 +#2 0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8) + at qemu-coroutine.c:31 +#3 0x00411618 in bdrv_rw_co (bs=<optimized out>, sector_num=<optimized out>, + buf=0x2140000 "@", nb_sectors=1, is_write=false) at block.c:1335 +#4 0x00486e39 in ide_sector_read (s=0x1bbdaa0) + at C:/msys/home/User/qemu/hw/ide/core.c:480 +#5 0x0054e71f in memory_region_iorange_write (iorange=0x1bbcf60, offset=7, + width=1, data=32) at C:/msys/home/User/qemu/memory.c:431 +#6 0x005494e0 in ioport_writeb_thunk (opaque=0x1bbcf60, addr=7680, data=32) + at C:/msys/home/User/qemu/ioport.c:211 +#7 0x005496cf in ioport_write (data=<optimized out>, + address=<optimized out>, index=<optimized out>) + at C:/msys/home/User/qemu/ioport.c:82 +#8 cpu_outb (addr=2147340288, val=0 '\000') + at C:/msys/home/User/qemu/ioport.c:274 +#9 0x022c0397 in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) + +Same crash in wine: + +user@gx110-lubuntu:~/qemu/i386-softmmu $ wine --version +wine-1.3.37 +user@gx110-lubuntu:~/qemu/i386-softmmu $ winedbg qemu-system-i386.exe -L ..\\pc-bios -fda fda.img +WineDbg starting on pid 0024 +0x7b85dedf: movl %edi,0x4(%esp) +Wine-dbg>cont +fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0080: stub! +fixme:keyboard:X11DRV_LoadKeyboardLayout L"00000409", 0001: stub! +Unhandled exception: page fault on write access to 0x00000004 in 32-bit code (0x7b83ba1e). + +Wine-dbg>bt all +(...) + +Backtracing for thread 000d in process 0024 (Z:\home\user\qemu\i386-softmmu\qemu-system-i386.exe): +Backtrace: +=>0 0x7e06f832 GLIBC_2+0x832() in ld-linux.so.2 (0x0dd1e9b8) + 1 0x68621611 in winmm (+0x21610) (0x0dd1ea48) + 2 0x7bc70ed0 call_thread_func_wrapper+0xb() in ntdll (0x0dd1ea58) + 3 0x7bc7110d call_thread_func+0x7c() in ntdll (0x0dd1eb28) + 4 0x7bc70eae RtlRaiseException+0x21() in ntdll (0x0dd1eb48) + 5 0x7bc7acd5 in ntdll (+0x6acd4) (0x0dd1f398) + 6 0x6814696e start_thread+0xbd() in libpthread.so.0 (0x0dd1f498) + +Backtracing for thread 0029 in process 0024 (Z:\home\user\qemu\i386-softmmu\qemu-system-i386.exe): +Backtrace: +=>0 0x7b83ba1e SwitchToFiber+0x1e() in kernel32 (0x04dde198) + 1 0x0044e368 qemu_coroutine_switch+0x37(from_=0x14730c, to_=0x16d430, action=COROUTINE_YIELD) [/home/user/qemu/coroutine-win32.c:48] in qemu-system-i386 (0x04dde1d8) + 2 0x004f4038 coroutine_swap+0x27(from=(nil), to=0x16d430) [/home/user/qemu/qemu-coroutine.c:31] in qemu-system-i386 (0x04dde208) + 3 0x00413c92 bdrv_rw_co+0x81(bs=<is not available>, sector_num=0x7ffd000000000000, buf="µ", nb_sectors=0x1, is_write=false) [/home/user/qemu/block.c:1335] in qemu-system-i386 (0x04dde268) + 4 0x004884e4 fdctrl_transfer_handler+0x1f3(opaque=0x1dd6d0, nchan=0x2, dma_pos=0, dma_len=0x200) [/home/user/qemu/hw/fdc.c:1162] in qemu-system-i386 (0x04dde4f8) + 5 0x0047f9e1 DMA_run+0xd0() [/home/user/qemu/hw/dma.c:348] in qemu-system-i386 (0x04dde548) + 6 0x00487286 fdctrl_start_transfer+0x2f5(fdctrl=0x1dd6d0, direction=0x1) [/home/user/qemu/hw/fdc.c:1093] in qemu-system-i386 (0x04dde5c8) + 7 0x0056b86d memory_region_iorange_write+0x9c(iorange=0x1df790, offset=0x4, width=0x1, data=0xff) [/home/user/qemu/memory.c:431] in qemu-system-i386 (0x04dde638) + 8 0x005666f7 ioport_writeb_thunk+0x46(opaque=0x1df790, addr=0x3f5, data=0xff) [/home/user/qemu/ioport.c:211] in qemu-system-i386 (0x04dde678) + 9 0x00566408 ioport_write+0x37(index=<is not available>, address=0x7ffd0000, data=0x4ddea70) [/home/user/qemu/ioport.c:82] in qemu-system-i386 (0x04dde6a8) + 10 0x01854496 (0x0015aab0) + +Backtracing for thread 0025 in process 0024 (Z:\home\user\qemu\i386-softmmu\qemu-system-i386.exe): +Backtrace: +=>0 0x7e06f830 GLIBC_2+0x830() in ld-linux.so.2 (0x015bf368) + 1 0x7bc77563 in ntdll (+0x67562) (0x015bf598) + 2 0x7bc77835 NtWaitForMultipleObjects+0x54() in ntdll (0x015bf5c8) + 3 0x7b86f89f WaitForMultipleObjectsEx+0xee() in kernel32 (0x015bf718) + 4 0x7b86f91a WaitForMultipleObjects+0x39() in kernel32 (0x015bf748) + 5 0x004d4c6f main_loop_wait+0x5be(nonblocking=0) [/home/user/qemu/main-loop.c:387] in qemu-system-i386 (0x015bfac8) + 6 0x004ccfc9 qemu_main+0xe18(argc=0x5, argv=0x131320, envp=(nil)) [/home/user/qemu/vl.c:1482] in qemu-system-i386 (0x015bfcf8) + 7 0x004d08ea SDL_main+0x29(argc=0x5, argv=0x131320) [/home/user/qemu/vl.c:102] in qemu-system-i386 (0x015bfd28) + 8 0x005fceae in qemu-system-i386 (+0x1fcead) (0x015bfd58) + 9 0x005fcf64 in qemu-system-i386 (+0x1fcf63) (0x015bfd88) + 10 0x005fc8d9 in qemu-system-i386 (+0x1fc8d8) (0x015bfe08) + 11 0x004010a7 __mingw_CRTStartup+0x86() [/build/buildd/mingw32-runtime-3.15.2/build_dir/src/mingwrt-3.15.2-mingw32/crt1.c:237] in qemu-system-i386 (0x015bfe50) + 12 0x004010a7 __mingw_CRTStartup+0x86() [/build/buildd/mingw32-runtime-3.15.2/build_dir/src/mingwrt-3.15.2-mingw32/crt1.c:237] in qemu-system-i386 (0x015bfe70) + 13 0x004010a7 __mingw_CRTStartup+0x86() [/build/buildd/mingw32-runtime-3.15.2/build_dir/src/mingwrt-3.15.2-mingw32/crt1.c:237] in qemu-system-i386 (0x015bfe88) + 14 0x004010a7 __mingw_CRTStartup+0x86() [/build/buildd/mingw32-runtime-3.15.2/build_dir/src/mingwrt-3.15.2-mingw32/crt1.c:237] in qemu-system-i386 (0x015bfec8) + 15 0x004010a7 __mingw_CRTStartup+0x86() [/build/buildd/mingw32-runtime-3.15.2/build_dir/src/mingwrt-3.15.2-mingw32/crt1.c:237] in qemu-system-i386 (0x015bfed8) + 16 0x004010a7 __mingw_CRTStartup+0x86() [/build/buildd/mingw32-runtime-3.15.2/build_dir/src/mingwrt-3.15.2-mingw32/crt1.c:237] in qemu-system-i386 (0x015bffa8) + 17 0x004010a7 __mingw_CRTStartup+0x86() [/build/buildd/mingw32-runtime-3.15.2/build_dir/src/mingwrt-3.15.2-mingw32/crt1.c:237] in qemu-system-i386 (0x015bffc8) + 18 0x004010a7 __mingw_CRTStartup+0x86() [/build/buildd/mingw32-runtime-3.15.2/build_dir/src/mingwrt-3.15.2-mingw32/crt1.c:237] in qemu-system-i386 (0x015bffe8) + 19 0x004010a7 __mingw_CRTStartup+0x86() [/build/buildd/mingw32-runtime-3.15.2/build_dir/src/mingwrt-3.15.2-mingw32/crt1.c:237] in qemu-system-i386 (0x00000000) +0x68000830 GLIBC_2+0x830 in ld-linux.so.2: int $0x80 + +Wine-dbg>q +wine: Unhandled page fault on write access to 0x00000004 at address 0x7b83ba1e (thread 0029), starting debugger... + + +On Wed, Feb 15, 2012 at 1:59 AM, Roy Tam <email address hidden> wrote: +> 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +> (gdb) bt +> #0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +> #1 0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8, +> action=COROUTINE_YIELD) at coroutine-win32.c:48 +> #2 0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8) +> at qemu-coroutine.c:31 +> #3 0x00411618 in bdrv_rw_co (bs=<optimized out>, sector_num=<optimized out>, +> buf=0x2140000 "@", nb_sectors=1, is_write=false) at block.c:1335 + +This is interesting because the code is a straightforward usage of coroutines: + +co = qemu_coroutine_create(bdrv_rw_co_entry); +qemu_coroutine_enter(co, &rwco); <--- boom + +Please make test-coroutine and try ./test-coroutine. That performs +some sanity checks. + +I haven't had time to look in depth yet but perhaps this worked in the +past and you could bisect it to find the commit that broke it? + +Stefan + + +Am 16.02.2012 10:34, schrieb Stefan Hajnoczi: +> This is interesting because the code is a straightforward usage of +> coroutines: +> +> co = qemu_coroutine_create(bdrv_rw_co_entry); +> qemu_coroutine_enter(co, &rwco); <--- boom +> +> Please make test-coroutine and try ./test-coroutine. That performs +> some sanity checks. +> +> I haven't had time to look in depth yet but perhaps this worked in the +> past and you could bisect it to find the commit that broke it? + +Remember that I saw a similar crash a while ago? It was definitely a +NULL pointer access somewhere inside SwitchToFiber. I can't remember +exactly what came out of it, but I think you and Paolo couldn't +reproduce it and I ran out of time for debugging win32 stuff. + +If I was to debug this, the first thing I would try is that I would dump +co->fiber (or actually I seem to remember it was some data structure +that is only pointed to by a field in co->fiber) immediately after the +coroutine is created (I think it was still okay then) and set a +watchpoint on it. + +Kevin + + +2012/2/16 Kevin Wolf <email address hidden>: +> Am 16.02.2012 10:34, schrieb Stefan Hajnoczi: +>> This is interesting because the code is a straightforward usage of +>> coroutines: +>> +>> co = qemu_coroutine_create(bdrv_rw_co_entry); +>> qemu_coroutine_enter(co, &rwco); <--- boom +>> +>> Please make test-coroutine and try ./test-coroutine. That performs +>> some sanity checks. +>> +>> I haven't had time to look in depth yet but perhaps this worked in the +>> past and you could bisect it to find the commit that broke it? +> +> Remember that I saw a similar crash a while ago? It was definitely a +> NULL pointer access somewhere inside SwitchToFiber. I can't remember +> exactly what came out of it, but I think you and Paolo couldn't +> reproduce it and I ran out of time for debugging win32 stuff. +> +> If I was to debug this, the first thing I would try is that I would dump +> co->fiber (or actually I seem to remember it was some data structure +> that is only pointed to by a field in co->fiber) immediately after the +> coroutine is created (I think it was still okay then) and set a +> watchpoint on it. +> +> Kevin + +A -O0 build traces: (I should put this in CFLAGS but not in --extra-cflags) + +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 5688.0x17c0] +0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +(gdb) bt +#0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +#1 0x0045e98d in qemu_coroutine_switch (from_=0x18f93a4, to_=0x1b79648, + action=COROUTINE_YIELD) at coroutine-win32.c:48 +#2 0x004fea3f in coroutine_swap (from=0x18f93a4, to=0x1b79648) + at qemu-coroutine.c:31 +#3 0x004feb34 in qemu_coroutine_enter (co=0x1b79648, opaque=0x1fafa60) + at qemu-coroutine.c:58 +#4 0x00414e22 in bdrv_rw_co (bs=0x18f7fb0, sector_num=0, buf=0x20e0000 "@", + nb_sectors=1, is_write=false) at block.c:1337 +#5 0x00414e92 in bdrv_read (bs=0x18f7fb0, sector_num=0, buf=0x20e0000 "@", + nb_sectors=1) at block.c:1349 +#6 0x004a03d5 in ide_sector_read (s=0x1b5b9e0) + at C:/msys/home/User/qemu/hw/ide/core.c:480 +#7 0x0058872b in memory_region_iorange_write (iorange=0xdc32268, offset=7, + width=1, data=32) at C:/msys/home/User/qemu/memory.c:431 +#8 0x00583510 in ioport_writeb_thunk (opaque=0xdc32268, addr=7680, data=32) + at C:/msys/home/User/qemu/ioport.c:211 +#9 0x005836ff in ioport_write (data=<optimized out>, + address=<optimized out>, index=<optimized out>) + at C:/msys/home/User/qemu/ioport.c:82 +#10 cpu_outb (addr=2147340288, val=0 '\000') + at C:/msys/home/User/qemu/ioport.c:274 +#11 0x02260397 in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) +(gdb) frame 1 +#1 0x0045e98d in qemu_coroutine_switch (from_=0x18f93a4, to_=0x1b79648, + action=COROUTINE_YIELD) at coroutine-win32.c:48 +48 SwitchToFiber(to->fiber); +(gdb) print to +$1 = (CoroutineWin32 *) 0x1b79648 +(gdb) print *to +$2 = {base = {entry = 0x414cb0 <bdrv_rw_co_entry>, entry_arg = 0x1fafa60, + caller = 0x18f93a4, pool_next = {le_next = 0x0, le_prev = 0x0}, + co_queue_next = {tqe_next = 0x0, tqe_prev = 0x0}}, fiber = 0x249e30, + action = COROUTINE_YIELD} + + +2012/2/16 Kevin Wolf <email address hidden>: +> Am 16.02.2012 12:01, schrieb Paolo Bonzini: +>> On 02/16/2012 11:34 AM, Kevin Wolf wrote: +>>> Remember that I saw a similar crash a while ago? It was definitely a +>>> NULL pointer access somewhere inside SwitchToFiber. I can't remember +>>> exactly what came out of it, but I think you and Paolo couldn't +>>> reproduce it and I ran out of time for debugging win32 stuff. +>>> +>>> If I was to debug this, the first thing I would try is that I would dump +>>> co->fiber (or actually I seem to remember it was some data structure +>>> that is only pointed to by a field in co->fiber) immediately after the +>>> coroutine is created (I think it was still okay then) and set a +>>> watchpoint on it. +>> +>> IIRC the problem was that thread-local storage was not thread-local at all. +> +> Ah, right. And we didn't introduce a workaround, so I guess this is the +> same thing. +> +> Do newer mingw versions get this right or were you just lucky and we +> should look for some kind of workaround? +> + +Does QEMU calls ConvertThreadToFiber() in I/O Thread? +From thread notes located in +http://www.lisphacker.com/temp/threading-notes.txt : + + * Before a Thread can call SwitchToFiber() it must call + ConvertThreadToFiber(), but there is no way prior to Vista + to know if a Thread created by alien code is already a + Fiber, and the documentation is spectacularly unclear on the + consequences of using the Fiber functions improperly (such + as calling SwitchToFiber() without calling + ConvertThreadToFiber() or calling ConvertThreadToFiber() + when the Thread has already been converted). + +If so, we may hitting this issue. + +> Kevin +> + +Roy + + +The crash is caused by non-working thread local storage (TLS) in coroutine-win32.c. + +It took me some time to analyze this bug because I don't get it in my native w32 environment with gcc-4.6.2, +but I could reproduce it with cross compiled w32 code. SwitchToFiber crashed because it was called with a +TIB (http://en.wikipedia.org/wiki/Win32_Thread_Information_Block) which belonged to a thread which was +not converted to a fiber. ConvertThreadToFiber was not called for this thread because TLS "current" was +not thread local. + +Please try these modified configure option which adds the compiler flag needed for multithreading: +--extra-cflags="-O0 -pipe -mthreads". For me, -mthreads solved the problem. + +Regards, +Stefan Weil + +2012/2/17 Stefan Weil <email address hidden>: +> The crash is caused by non-working thread local storage (TLS) in +> coroutine-win32.c. +> +> It took me some time to analyze this bug because I don't get it in my native w32 environment with gcc-4.6.2, +> but I could reproduce it with cross compiled w32 code. SwitchToFiber crashed because it was called with a +> TIB (http://en.wikipedia.org/wiki/Win32_Thread_Information_Block) which belonged to a thread which was +> not converted to a fiber. ConvertThreadToFiber was not called for this thread because TLS "current" was +> not thread local. +> +> Please try these modified configure option which adds the compiler flag needed for multithreading: +> --extra-cflags="-O0 -pipe -mthreads". For me, -mthreads solved the problem. +> + +Yes "-mthreads" switch does workaround the issue. +But using "-mthreads" making resulting binaries depend on +mingwm10.dll, which is not good. + +> Regards, +> Stefan Weil + + +2012/2/17 Roy Tam <email address hidden>: +> 2012/2/17 Stefan Weil <email address hidden>: +>> The crash is caused by non-working thread local storage (TLS) in +>> coroutine-win32.c. +>> +>> It took me some time to analyze this bug because I don't get it in my native w32 environment with gcc-4.6.2, +>> but I could reproduce it with cross compiled w32 code. SwitchToFiber crashed because it was called with a +>> TIB (http://en.wikipedia.org/wiki/Win32_Thread_Information_Block) which belonged to a thread which was +>> not converted to a fiber. ConvertThreadToFiber was not called for this thread because TLS "current" was +>> not thread local. +>> +>> Please try these modified configure option which adds the compiler flag needed for multithreading: +>> --extra-cflags="-O0 -pipe -mthreads". For me, -mthreads solved the problem. +>> +> +> Yes "-mthreads" switch does workaround the issue. +> But using "-mthreads" making resulting binaries depend on +> mingwm10.dll, which is not good. +> + +And also it still crash when quitting: +Program received signal SIGSEGV, Segmentation fault. +0x00609bfb in emutls_destroy (ptr=0x1959418) + at ../../../gcc-4.3.3/libgcc/../gcc/emutls.c:76 +76 ../../../gcc-4.3.3/libgcc/../gcc/emutls.c: No such file or directory. + in ../../../gcc-4.3.3/libgcc/../gcc/emutls.c +(gdb) bt +#0 0x00609bfb in emutls_destroy (ptr=0x1959418) + at ../../../gcc-4.3.3/libgcc/../gcc/emutls.c:76 +#1 0x6fbc1263 in __mingwthr_run_key_dtors () + from C:\msys\home\User\qemu\i386-softmmu\mingwm10.dll +#2 0x6fbc1408 in __dyn_tls_dtor@12 () + from C:\msys\home\User\qemu\i386-softmmu\mingwm10.dll +#3 0x6fbc0000 in ?? () +#4 0x7c9424ca in ntdll!RtlDestroyQueryDebugBuffer () + from C:\WINDOWS\system32\ntdll.dll +#5 0x7c81caae in KERNEL32!IsValidLocale () + from C:\WINDOWS\system32\kernel32.dll +#6 0x7c81cb26 in KERNEL32!ExitProcess () + from C:\WINDOWS\system32\kernel32.dll +#7 0x77c09d45 in strerror () from C:\WINDOWS\system32\msvcrt.dll +#8 0x77c09e78 in msvcrt!_initterm () from C:\WINDOWS\system32\msvcrt.dll +#9 0x77c09e90 in msvcrt!exit () from C:\WINDOWS\system32\msvcrt.dll +#10 0x006024dc in console_main () +#11 0x00602594 in WinMain@16 () +#12 0x00601db8 in main () + +>> Regards, +>> Stefan Weil + + +More or less same crash for me: +Using built-in specs. +COLLECT_GCC=d:\MinGW\bin\gcc.exe +COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe +Target: mingw32 +Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw +Thread model: win32 +gcc version 4.6.2 (GCC) + +Host WinXP SP3 - Qemu-1.0.1 + +Maybe it can help: + +Some stack frame (breakpoint set with command "where; continue" on function qemu_coroutine_switch(): + +Breakpoint 1, qemu_coroutine_switch (from_=0x1989f34, to_=0x209df00, action=COROUTINE_YIELD) at coroutine-win32.c:41 +41 { +#0 qemu_coroutine_switch (from_=0x1989f34, to_=0x209df00, action=COROUTINE_YIELD) at coroutine-win32.c:41 +#1 0x004c3fe6 in _fu6882____stack_chk_guard () at qemu-coroutine.c:31 +#2 0x00410e1e in _fu528____stack_chk_guard () at block.c:2518 +#3 0x00403152 in _fu35____stack_chk_guard () at async.c:71 +#4 0x004a7a8e in _fu5545____stack_chk_guard () at main-loop.c:472 +#5 0x004a27db in main_loop () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\vl.c:1481 +#6 _fu5383____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\vl.c:3485 +#7 0x004a3b2a in _fu5385____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\vl.c:102 +#8 0x005ddcf9 in console_main (argc=20, argv=0x1985d00) at ./src/main/win32/SDL_win32_main.c:315 +#9 0x005dddbb in WinMain@16 (hInst=0x400000, hPrev=0x0, szCmdLine=0x241f18 "-L Bios -k fr -vga std -soundhw es1370 -boot menu=on,splash=bootsplash.bmp,splash-time=5000 -rtc base=localtime,clock=host -name linux-0.2 -drive file=linux-0.2.img,media=disk,cache=writeback -no-acpi"..., sw=10) at ./src/main/win32/SDL_win32_main.c:398 +#10 0x005dd45a in main (argc=) at ../mingw/main.c:73 +[Switching to Thread 5316.0xda0] + +Breakpoint 1, qemu_coroutine_switch (from_=0x1989f34, to_=0x1bcf900, action=COROUTINE_YIELD) at coroutine-win32.c:41 +41 { +#0 qemu_coroutine_switch (from_=0x1989f34, to_=0x1bcf900, action=COROUTINE_YIELD) at coroutine-win32.c:41 +#1 0x004c3fe6 in _fu6882____stack_chk_guard () at qemu-coroutine.c:31 +#2 0x0041543d in _fu757____stack_chk_guard () at block.c:2657 +#3 0x00472b95 in _fu3751____stack_chk_guard () +#4 0x00554e1b in _fu11201____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\memory.c:446 +#5 0x0054e5a8 in _fu10980____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\ioport.c:211 +#6 0x0054eb9d in ioport_write (data=<optimized out>, address=503, index=0) at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\ioport.c:82 +#7 _fu10998____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\ioport.c:274 +#8 0x026680cf in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) + +Program received signal SIGILL, Illegal instruction. +0x68ac12ca in ?? () from d:\documents\lassauge\qemu-windows\libssp-0.dll +(gdb) at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0xbaadf011 +Cannot access memory at address 0x0 + +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x68ac12ca in ?? () from d:\documents\lassauge\qemu-windows\libssp-0.dll +(gdb) where +#0 0x68ac12ca in ?? () from d:\documents\lassauge\qemu-windows\libssp-0.dll +#1 0x68ac1322 in libssp-0!__stack_chk_fail () from d:\documents\lassauge\qemu-windows\libssp-0.dll +#2 0x0044a399 in _fu2073____stack_chk_guard () at coroutine-win32.c:50 +#3 0x0049dc77 in _fu5254____stack_chk_guard () at d:\Documents\lassauge\Software\dev\Qemu\qemu-1.0.1\vl.c:1218 +#4 0x7ffdd000 in ?? () +#5 0xffffffff in ?? () +#6 0x00400000 in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) +(gdb) up +#1 0x68ac1322 in libssp-0!__stack_chk_fail () from d:\documents\lassauge\qemu-windows\libssp-0.dll +(gdb) up +#2 0x0044a399 in _fu2073____stack_chk_guard () at coroutine-win32.c:50 +50 } +(gdb) l +45 current = to_; +46 +47 to->action = action; +48 SwitchToFiber(to->fiber); +49 return from->action; +50 } +51 +52 static void CALLBACK coroutine_trampoline(void *co_) +53 { +54 Coroutine *co = co_; +(gdb) p action +$2 = 0 + + +coroutine issue again, when booting tinycore_3.3.iso: + +C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios -cdrom tinycore_3.3.iso +GNU gdb (GDB) 7.3 +Copyright (C) 2011 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "mingw32". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... +done. +(gdb) r +Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L .. +\\pc-bios -cdrom tinycore_3.3.iso +[New Thread 10072.0x2318] +[New Thread 10072.0x2050] +[New Thread 10072.0x29fc] +*** stack smashing detected ***: terminated + +Program received signal SIGILL, Illegal instruction. +[Switching to Thread 10072.0x29fc] +0x00634a4a in fail.isra.0 () +(gdb) bt +#0 0x00634a4a in fail.isra.0 () +#1 0x00634ab2 in __stack_chk_fail () +#2 0xa6782315 in ?? () +#3 0x00000bda in ?? () +#4 0x00000001 in ?? () +#5 0x0044b9b9 in qemu_coroutine_switch (from_=0x22f848, to_=0x7c92e920, + action=0) at coroutine-win32.c:50 +#6 0x000cef9f in ?? () +#7 0x0022f848 in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) +(gdb) + +http://<email address hidden>/msg103426.html may refer to this too. + +Please try a newer compiler. gcc-4.6.2 compiles thread local storage correctly, gcc-4.3.3 obviously doesn't. +If you can confirm that newer compilers fix this bug, I'd like to close this ticket. + + +2012/3/20 Stefan Weil <email address hidden>: +> Please try a newer compiler. gcc-4.6.2 compiles thread local storage correctly, gcc-4.3.3 obviously doesn't. +> If you can confirm that newer compilers fix this bug, I'd like to close this ticket. +> + +I'm using gcc-4.6.2 now. + +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/932487 +> +> Title: +> win32: git rev 59f971d crashes when accessing disk (coroutine issue) +> +> Status in QEMU: +> Confirmed +> +> Bug description: +> Host: XP SP3 / Vista SP2 +> +> configure commandline: ./configure --target-list="i386-softmmu" +> --audio-drv-list=sdl --audio-card-list=ac97,sb16,adlib --disable- +> linux-aio --disable-vnc-thread --disable-vnc-jpeg --extra-cflags="-O0 +> -pipe" +> +> gcc -v: +> Using built-in specs. +> Target: mingw32 +> Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32' +> Thread model: win32 +> gcc version 4.3.3 (4.3.3-tdm-1 mingw32) +> +> gdb output: +> C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios -hda xp.vmdk +> GNU gdb (GDB) 7.3 +> Copyright (C) 2011 Free Software Foundation, Inc. +> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +> This is free software: you are free to change and redistribute it. +> There is NO WARRANTY, to the extent permitted by law. Type "show copying" +> and "show warranty" for details. +> This GDB was configured as "mingw32". +> For bug reporting instructions, please see: +> <http://www.gnu.org/software/gdb/bugs/>... +> Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... +> done. +> (gdb) r +> Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios -hda xp.vmdk +> [New Thread 2472.0x8e0] +> [New Thread 2472.0xdc4] +> [New Thread 2472.0x8f0] +> +> Program received signal SIGSEGV, Segmentation fault. +> [Switching to Thread 2472.0x8f0] +> 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +> (gdb) bt +> #0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll +> #1 0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8, +> action=COROUTINE_YIELD) at coroutine-win32.c:48 +> #2 0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8) +> at qemu-coroutine.c:31 +> #3 0x00411618 in bdrv_rw_co (bs=<optimized out>, sector_num=<optimized out>, +> buf=0x2140000 "@", nb_sectors=1, is_write=false) at block.c:1335 +> #4 0x00486e39 in ide_sector_read (s=0x1bbdaa0) +> at C:/msys/home/User/qemu/hw/ide/core.c:480 +> #5 0x0054e71f in memory_region_iorange_write (iorange=0x1bbcf60, offset=7, +> width=1, data=32) at C:/msys/home/User/qemu/memory.c:431 +> #6 0x005494e0 in ioport_writeb_thunk (opaque=0x1bbcf60, addr=7680, data=32) +> at C:/msys/home/User/qemu/ioport.c:211 +> #7 0x005496cf in ioport_write (data=<optimized out>, +> address=<optimized out>, index=<optimized out>) +> at C:/msys/home/User/qemu/ioport.c:82 +> #8 cpu_outb (addr=2147340288, val=0 '\000') +> at C:/msys/home/User/qemu/ioport.c:274 +> #9 0x022c0397 in ?? () +> Backtrace stopped: previous frame inner to this frame (corrupt stack?) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/932487/+subscriptions + + +Fixed in newer versions which no longer have problems with thread local storage on Windows. + diff --git a/results/classifier/118/unknown/987 b/results/classifier/118/unknown/987 new file mode 100644 index 00000000..883f406e --- /dev/null +++ b/results/classifier/118/unknown/987 @@ -0,0 +1,79 @@ +permissions: 0.930 +user-level: 0.898 +peripherals: 0.896 +hypervisor: 0.895 +performance: 0.893 +KVM: 0.886 +architecture: 0.885 +graphic: 0.868 +register: 0.863 +device: 0.862 +semantic: 0.859 +vnc: 0.859 +debug: 0.859 +assembly: 0.853 +ppc: 0.852 +x86: 0.843 +VMM: 0.842 +PID: 0.841 +files: 0.839 +TCG: 0.836 +arm: 0.832 +virtual: 0.825 +kernel: 0.822 +socket: 0.821 +risc-v: 0.807 +i386: 0.802 +network: 0.796 +boot: 0.789 +mistranslation: 0.774 + +compiling issue +Description of problem: +compilation error issue while building for qemu-riscv32-static +Steps to reproduce: +1.git clone https://github.com/qemu/qemu.git + +2. ./configure --static --disable-system --target-list=riscv32-linux-user + + +issue output: +``` +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[954/960] Compiling C object tests/unit/test-string-output-visitor.p/test-string-output-visitor.c.o +[955/960] Linking target tests/unit/test-string-output-visitor +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[956/960] Compiling C object tests/unit/test-string-input-visitor.p/test-string-input-visitor.c.o +[957/960] Linking target tests/unit/test-string-input-visitor +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[958/960] Linking target tests/unit/test-x86-cpuid +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[959/960] Compiling C object tests/unit/test-visitor-serialization.p/test-visitor-serialization.c.o +[960/960] Linking target tests/unit/test-visitor-serialization +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +make[1]: Leaving directory '/home/sadiq/work/qemu/build' +changing dir to build for make ""... +make[1]: Entering directory '/home/sadiq/work/qemu/build' + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp +[1/3] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +make[1]: Leaving directory '/home/sadiq/work/qemu/build' +``` + +Any suggestions to resolve the issue would be helpful + +Thanks |