diff options
Diffstat (limited to '')
21 files changed, 1609 insertions, 0 deletions
diff --git a/results/classifier/108/other/152 b/results/classifier/108/other/152 new file mode 100644 index 000000000..1c1078a4c --- /dev/null +++ b/results/classifier/108/other/152 @@ -0,0 +1,16 @@ +graphic: 0.775 +performance: 0.657 +other: 0.559 +semantic: 0.551 +device: 0.442 +permissions: 0.371 +files: 0.217 +network: 0.196 +socket: 0.147 +PID: 0.134 +debug: 0.105 +boot: 0.101 +vnc: 0.096 +KVM: 0.026 + +qemu-img compare -m option is missing diff --git a/results/classifier/108/other/1520 b/results/classifier/108/other/1520 new file mode 100644 index 000000000..079242f3c --- /dev/null +++ b/results/classifier/108/other/1520 @@ -0,0 +1,64 @@ +performance: 0.916 +graphic: 0.876 +device: 0.871 +boot: 0.865 +permissions: 0.861 +other: 0.849 +semantic: 0.838 +PID: 0.819 +debug: 0.808 +network: 0.793 +files: 0.774 +socket: 0.761 +KVM: 0.699 +vnc: 0.678 + +x86 TCG acceleration running on s390x with -smp > host cpus slowed down by x10 +Description of problem: +This boots up a trivial guest using OVMF, when the conditions below are given it runs ~10x slower. + +I have found this breaking our tests of qemu 7.2 [(which due to Debian adding the offending change as backport is affected)](https://salsa.debian.org/qemu-team/qemu/-/blob/master/debian/patches/master/acpi-cpuhp-fix-guest-visible-maximum-access-size-to-.patch) by runnig an order of magnitude slower. + + +I was tracing it down (insert a long strange trip here) and found that it occurs: +- only with patch dab30fb "acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block" applied + - latest master is still affetced +- only with s390x running emulation of x86 + - emulating x86 on ppc64 didn't show the same behavior +- only with -smp > host cpus + - smp 2 with 1 host cpu => slow + - smp 4 with 2 host cpu => slow + - any case where host cpu >= smp => fast + +On average good cases are on a 2964 s390x machine taking ~5-6 seconds for the good case. +The bad case is close to 60s which is the timeout of the automated tests. + +We all know -smp shouldn't be >host-cpus, and I totally admit that this is the definition of an edge case. +But I do not know what else might be affected and this just happened to be what the test does by default - and a slowdown by x10 seems too much even for edge cases to be just ignored. +And while we could just bump up the timeout (and probably will as an interim workaround) I wanted to file it here for your awareness. +Steps to reproduce: +You can recreate the same by using the commandline above and timing things on your own. + +Or you can use the [autopkgtest of edk2 in Ubuntu](https://git.launchpad.net/ubuntu/+source/edk2/tree/debian/tests/shell.py#n214) which have [shown this](https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/s390x/e/edk2/20230224_094012_c95f4@/log.gz) first. +Additional information: +Only signed OVMF cases are affected, while aavmf and other OVMF are more or less on the same speed. + +``` +1 CPU / 1GB Memory +7.0 7.2 +6.54s 58.32s test_ovmf_ms +6.72s 56.96s test_ovmf_4m_ms +7.54s 55.47s test_ovmf_4m_secboot +7.56s 49.88s test_ovmf_secboot +7.01s 39.79s test_ovmf32_4m_secboot +7.38s 7.43s test_aavmf32 +7.27s 7.30s test_aavmf +7.26s 7.26s test_aavmf_snakeoil +5.83s 5.95s test_ovmf_4m +5.61s 5.81s test_ovmf_q35 +5.51s 5.64s test_ovmf_pc +5.26s 5.42s test_ovmf_snakeoil +``` + +Highlighting @cborntra since it is somewhat s390x related and @mjt0k as the patch is applied as backport in Debian. +I didn't find the handle of Laszlo (Author) to highlight him as well. diff --git a/results/classifier/108/other/1520730 b/results/classifier/108/other/1520730 new file mode 100644 index 000000000..77ed072c1 --- /dev/null +++ b/results/classifier/108/other/1520730 @@ -0,0 +1,37 @@ +graphic: 0.843 +device: 0.622 +other: 0.523 +semantic: 0.483 +performance: 0.479 +permissions: 0.285 +PID: 0.187 +network: 0.169 +debug: 0.168 +vnc: 0.132 +boot: 0.117 +files: 0.112 +socket: 0.109 +KVM: 0.014 + +32-bit editors vim/rhide broken keyboard handling in freedos 1.1 and ms-dos 6.22 + +This bug is present as of the latest commit: 714487515dbe0c65d5904251e796cd3a5b3579fb + +I also saw it in 2.4.1, but that was a distro package. + +You can see the bug simply using the following line: qemu-system-i386 -hda freedos.disk + +Simply type vim (or rhide) and start entering in some text. You'll notice repeating characters, and also eventually the key mode will change as if you're holding down the shift button. Not capslock. "a" will become "A", but "\" will also become "|". + +I don't think this is a bug in freedos because I get the same behavior with dos 6.22. Not dosbox, though. + + + +I'm seeing this issue in version 2.12.0-rc4. I wasn't seeing this as much in earlier 2.11, but its a major pain in the current version. + +Which user interface is this? + +Can you still reproduce this issue with the latest version of QEMU? Are you using a SDL or GTK build for the graphical interface? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1521 b/results/classifier/108/other/1521 new file mode 100644 index 000000000..39351afda --- /dev/null +++ b/results/classifier/108/other/1521 @@ -0,0 +1,16 @@ +device: 0.902 +other: 0.661 +socket: 0.551 +network: 0.543 +semantic: 0.407 +permissions: 0.404 +performance: 0.392 +boot: 0.343 +debug: 0.263 +graphic: 0.258 +PID: 0.147 +vnc: 0.125 +files: 0.090 +KVM: 0.026 + +USB HID not using the keycodemapdb and thus lacking new entries diff --git a/results/classifier/108/other/1523811 b/results/classifier/108/other/1523811 new file mode 100644 index 000000000..7fea22147 --- /dev/null +++ b/results/classifier/108/other/1523811 @@ -0,0 +1,121 @@ +permissions: 0.893 +device: 0.877 +debug: 0.873 +other: 0.857 +performance: 0.847 +PID: 0.847 +network: 0.835 +graphic: 0.829 +semantic: 0.815 +vnc: 0.811 +files: 0.809 +socket: 0.809 +KVM: 0.803 +boot: 0.715 + +USB assert failure on dev-storage.c + +On executing the attached python script in the guest OS, QEMU dies with assert failure: + +[run python script in guest root shell] +# python a.py + +[host message] +qemu-system-x86_64: hw/usb/dev-storage.c:445: usb_msd_handle_data: Assertion `le32_to_cpu(s->csw.residue) == 0' failed. +Aborted (core dumped) + + +When I detach the kernel driver and send CBW and reattach it again, without conforming to the command/data/status protocol, QEMU dies. +I think this is due to misimplementation of Command/Data/Status protocol in Bulk-only transfer. +This kind of assert failure can be misused by malwares to avoid being analyzed by terminating only in the virtual environments and still execute the malicious code in real machines. +Before running python script, make sure to change a.py that it should points to usb mass storage's vid and pid. + +QEMU was running on these environment : +[CPU model] Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz +[qemu version] QEMU 2.5.0-rc2 (compiled from source, gcc 4.8.4) +[host info] Ubuntu 14.04.3, x86_64, 3.19.0-32-generic +[guest info] Ubuntu 14.04.3, x86_64, 3.19.0-28-generic +[QEMU argument] +x86_64-softmmu/qemu-system-x86_64 -hda /media/hdd/img/ubuntu1404.qcow2.5 \ + -m 512 \ + --usbdevice disk:format=qcow2:../usb.img.5 \ + --enable-kvm + + + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (version 2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + +Using hypervisor fuzzer, hyfuzz, I found an assertion failure through nec-usb-xhci 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, 51db2d7cf26d05a961ec0ee0eb773594b32cc4a1) + +To reproduce the assertion failure, please run the QEMU with the following command line. + +``` + +$ qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -drive if=none,id=stick,file=./usbdisk.img,format=raw -device nec-usb-xhci,id=usb -device usb-storage,bus=usb.0,drive=stick + + +``` + + +``` + +qemu-system-i386: ../hw/usb/dev-storage.c:454: void usb_msd_handle_data(USBDevice *, USBPacket *): Assertion `le32_to_cpu(s->csw.residue) == 0' failed. + +#0 0x00007ffff1a60fb7 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x00007ffff1a62921 in __GI_abort () at abort.c:79 +#2 0x00007ffff1a5248a in __assert_fail_base (fmt=0x7ffff1bd9750 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x555557518dc0 <.str.30> "le32_to_cpu(s->csw.residue) == 0", file=file@entry=0x5555575189e0 <.str.19> "../hw/usb/dev-storage.c", line=line@entry=0x1c6, function=function@entry=0x555557518e20 <__PRETTY_FUNCTION__.usb_msd_handle_data> "void usb_msd_handle_data(USBDevice *, USBPacket *)") at assert.c:92 +#3 0x00007ffff1a52502 in __GI___assert_fail (assertion=0x555557518dc0 <.str.30> "le32_to_cpu(s->csw.residue) == 0", file=0x5555575189e0 <.str.19> "../hw/usb/dev-storage.c", line=0x1c6, function=0x555557518e20 <__PRETTY_FUNCTION__.usb_msd_handle_data> "void usb_msd_handle_data(USBDevice *, USBPacket *)") at assert.c:101 +#4 0x0000555556299749 in usb_msd_handle_data (dev=<optimized out>, p=<optimized out>) at ../hw/usb/dev-storage.c:454 +#5 0x00005555563120b3 in usb_device_handle_data (dev=0x62300000a900, p=0x611001da3fc8) at ../hw/usb/bus.c:180 +#6 0x000055555610ac07 in usb_process_one (p=0x611001da3fc8) at ../hw/usb/core.c:406 +#7 0x0000555556109d8f in usb_handle_packet (dev=0x62300000a900, p=<optimized out>) at ../hw/usb/core.c:438 +#8 0x000055555687de55 in xhci_submit (xhci=<optimized out>, xfer=<optimized out>, epctx=<optimized out>) at ../hw/usb/hcd-xhci.c:1779 +#9 0x000055555687de55 in xhci_fire_transfer (xhci=<optimized out>, xfer=<optimized out>, epctx=<optimized out>) at ../hw/usb/hcd-xhci.c:1788 +#10 0x000055555687de55 in xhci_kick_epctx (epctx=<optimized out>, streamid=0x0) at ../hw/usb/hcd-xhci.c:1947 +#11 0x000055555688c7f6 in xhci_kick_ep (xhci=<optimized out>, slotid=<optimized out>, epid=<optimized out>, streamid=0x0) at ../hw/usb/hcd-xhci.c:1813 +#12 0x00005555568943b7 in xhci_doorbell_write (ptr=<optimized out>, reg=0x1, val=0x4, size=<optimized out>) at ../hw/usb/hcd-xhci.c:3114 +#13 0x0000555556c6617a 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 +#14 0x0000555556c65d96 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 +#15 0x0000555556c65d96 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1501 +#16 0x0000555556fb4b90 in flatview_write_continue (fv=0x6060002bf460, addr=0xfebf2004, attrs=..., ptr=<optimized out>, len=0x4, addr1=0x7fff775fa810, l=<optimized out>, mr=0x7fff74937610) at ../softmmu/physmem.c:2776 +#17 0x0000555556fb9e3d in flatview_write (fv=<optimized out>, addr=<optimized out>, attrs=..., len=0x4, buf=<optimized out>) at ../softmmu/physmem.c:2816 +#18 0x0000555556fb9e3d in subpage_write (opaque=<optimized out>, addr=<optimized out>, value=<optimized out>, len=<optimized out>, attrs=...) at ../softmmu/physmem.c:2482 +#19 0x0000555556c668ff in memory_region_write_with_attrs_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../softmmu/memory.c:511 +#20 0x0000555556c65de6 in access_with_adjusted_size (addr=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, mr=<optimized out>, attrs=..., value=<optimized out>, access_fn=<optimized out>) + at ../softmmu/memory.c:552 +#21 0x0000555556c65de6 in memory_region_dispatch_write (mr=<optimized out>, addr=<optimized out>, data=<optimized out>, op=<optimized out>, attrs=...) at ../softmmu/memory.c:1508 +#22 0x0000555556cd2796 in io_writex (iotlbentry=<optimized out>, mmu_idx=<optimized out>, val=<optimized out>, addr=<optimized out>, retaddr=<optimized out>, op=4054192055, env=<optimized out>) at ../accel/tcg/cputlb.c:1425 +#23 0x0000555556cd2796 in store_helper (env=<optimized out>, addr=<optimized out>, val=0x4, oi=<optimized out>, retaddr=<optimized out>, op=MO_32) at ../accel/tcg/cputlb.c:2444 +#24 0x0000555556cd2796 in helper_le_stl_mmu (env=<optimized out>, addr=<optimized out>, val=0x1ca6828, oi=<optimized out>, retaddr=0x7fff97c4ce9f) at ../accel/tcg/cputlb.c:2510 +#25 0x00007fff97c4ce9f in code_gen_buffer () +#26 0x0000555556f3ea44 in cpu_tb_exec (cpu=0x62e000000400, itb=<optimized out>, tb_exit=0x7fff775fbf20) at ../accel/tcg/cpu-exec.c:191 +#27 0x0000555556f40cf4 in cpu_loop_exec_tb (tb=<optimized out>, tb_exit=<optimized out>, cpu=<optimized out>, last_tb=<optimized out>) at ../accel/tcg/cpu-exec.c:672 +#28 0x0000555556f40cf4 in cpu_exec (cpu=0x62e000000400) at ../accel/tcg/cpu-exec.c:797 +#29 0x0000555556c5cd73 in tcg_cpus_exec (cpu=0x62e000000400) at ../accel/tcg/tcg-accel-ops.c:60 +#30 0x0000555556cfd60d in mttcg_cpu_thread_fn (arg=0x62e000000400) at ../accel/tcg/tcg-accel-ops-mttcg.c:70 +#31 0x00005555573f75cf in qemu_thread_start (args=0x6030000d9870) at ../util/qemu-thread-posix.c:521 +#32 0x0000555556022f5f in __asan::AsanThread::ThreadStart(unsigned long, __sanitizer::atomic_uintptr_t*) () +#33 0x00007ffff243e6db in start_thread (arg=0x7fff775ff700) at pthread_create.c:463 +#34 0x00007ffff1b4371f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +``` + + + +Looking at commit 0659879e6e5 ("usb-storage: remove MSDState->residue") +this assert seems a left-over, CSW residue should be irrelevant in CBW +path... +Gerd, can we simply remove it? + +No, we can't. csw.residue is non-zero if the request didn't complete yet (usb_msd_send_status clears it via memset). We *really* should not be in USB_MSDM_CBW state with a non-zero residue. +We need to figure how we end up with this inconsistency. Possibly via usb_msd_handle_reset(). + +https://gitlab.com/qemu-project/qemu/-/commit/39912c14da07a2d + diff --git a/results/classifier/108/other/1524 b/results/classifier/108/other/1524 new file mode 100644 index 000000000..f620c8947 --- /dev/null +++ b/results/classifier/108/other/1524 @@ -0,0 +1,52 @@ +device: 0.695 +graphic: 0.678 +KVM: 0.535 +vnc: 0.491 +PID: 0.462 +semantic: 0.447 +performance: 0.368 +debug: 0.363 +socket: 0.338 +network: 0.332 +files: 0.256 +permissions: 0.192 +boot: 0.145 +other: 0.042 + +error while loading state for instance 0x0 of device 'kvm-tpr-opt',load of migration failed: Operation not permitted +Description of problem: +when i save and restore a guest,it report the error: "error while loading state for instance 0x0 of device 'kvm-tpr-opt',load of migration failed: Operation not permitted" +Steps to reproduce: +1.virsh save test ccc.img + +2.virsh restore ccc.im + + +it report error: + +[root@TOS-9772 ~]# virsh save test ccc.img + +[root@TOS-9772 ~]# virsh restore ccc.img + +error: Failed to restore domain from ccc.img + +error: internal error: qemu unexpectedly closed the monitor: qmp_cmd_name: query-hotpluggable-cpus, arguments: {} + +qmp_cmd_name: query-cpus-fast, arguments: {} + +qmp_cmd_name: query-iothreads, arguments: {} + +qmp_cmd_name: expire_password, arguments: {"protocol": "spice", "time": "never"} + +qmp_cmd_name: balloon, arguments: {"value": 1073741824} + +qmp_cmd_name: migrate-incoming, arguments: {"uri": "fd:29"} + +{"timestamp": {"seconds": 1677661413, "microseconds": 275227}, "event": "MIGRATION", "data": {"status": "setup"}} + +{"timestamp": {"seconds": 1677661413, "microseconds": 275600}, "event": "MIGRATION", "data": {"status": "active"}} + +2023-03-01T09:03:33.316549Z qemu-system-x86_64: error while loading state for instance 0x0 of device 'kvm-tpr-opt' + +2023-03-01T09:03:33.317076Z qemu-system-x86_64: load of migration failed: Operation not permitted +{"timestamp": {"seconds": 1677661413, "microseconds": 317297}, "event": "MIGRATION", "data": {"status": "failed"}} diff --git a/results/classifier/108/other/1524637 b/results/classifier/108/other/1524637 new file mode 100644 index 000000000..8e8d1cc33 --- /dev/null +++ b/results/classifier/108/other/1524637 @@ -0,0 +1,33 @@ +device: 0.805 +graphic: 0.727 +semantic: 0.679 +permissions: 0.631 +socket: 0.449 +files: 0.430 +performance: 0.428 +other: 0.411 +network: 0.411 +debug: 0.362 +vnc: 0.352 +KVM: 0.302 +PID: 0.298 +boot: 0.179 + +system_powerdown/system_reset not working when exec stop on hmp + +system_powerdown/system_reset stops working in qemu for centos kernels if KVM is enabled. + +qemu versioin: 2.4 +linux kernel versioin: 4.2.5 + +How to reproduce: + +1. qemu-system-x86_64 -enable-kvm -drive if=none,id=drive0,file=/media/sda5/image/fc21/fc21.raw -device virtio-blk-pci,drive=drive0,iothread=iothread0 -machine smm=off -object iothread,id=iothread0 -monitor stdio +2. Enter stop in the qemu console, we can see the vm is stopped. +3. Enter system_powerdown in the qemu console +4. Nothing happens. + +Can you please give a prompt or something else when the vm isn't allowed to powerdown or reset? + +Looking through old bug tickets ... I don't think this was really a bug. If you stop your guest, of course the guest operating system can not powerdown anymore. It should powerdown once you resume your guest with "cont". + diff --git a/results/classifier/108/other/1525123 b/results/classifier/108/other/1525123 new file mode 100644 index 000000000..fa1baf80f --- /dev/null +++ b/results/classifier/108/other/1525123 @@ -0,0 +1,145 @@ +other: 0.966 +permissions: 0.963 +graphic: 0.960 +debug: 0.959 +semantic: 0.954 +performance: 0.937 +device: 0.935 +files: 0.935 +socket: 0.922 +PID: 0.919 +KVM: 0.912 +vnc: 0.894 +network: 0.885 +boot: 0.860 + +USB assert failure on hcd-uhci.c + +When inserting the attached kernel moudle in the guest OS, QEMU quits with therse assert failure: + + +[insert kernel module in guest root shell] +root@qemu:~# insmod mymod.ko +root@qemu:~# +Connection closed by foreign host. + +[host message] +qemu-system-x86_64: hw/usb/core.c:718: usb_ep_get: Assertion `pid == 0x69 || pid == 0xe1' failed. +Aborted + +The cause of this bug is due to misimplementation of UHCI. +According to Intel's UHCI design guide, packet identification in transfer descriptor should have one of these three value : IN (69h), OUT (E1h), and SETUP (2Dh). Any other value in this field shoudl cause HALT OF only HOST CONTROLLER. +However, due to misimplementation in QEMU, not only host controller halts, but QEMU itself exits with assertion failure. +This kind of assert failure can be misused by malwares to avoid being analyzed by terminating only in the virtual environments and still execute the malicious code in real machines. + +[How to run exploit code] +Prepare linux kernel's source header, then type these lines in root shell. +# make +# insmod mymod.ko + +It needs uhci-hcd.h from linux kernel source. +I attached linux 3.18.24's uhci-hcd.h for tempory measure; You should get proper version of uhci-hcd.h. +In the following envrionment, this exploit worked, exiting whole QEMU, not only USB. + +QEMU was running on these environment : +[CPU model] Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz +[qemu version] QEMU 2.5.0-rc3 (compiled from source, gcc 4.8.4) +[host info] Ubuntu 14.04.3, x86_64, 3.19.0-32-generic +[guest info] Ubuntu 14.04.3, x86_64, 3.19.0-28-generic +[QEMU argument] +x86_64-softmmu/qemu-system-x86_64 -hda /media/hdd/img/ubuntu1404.qcow2 \ + -m 512 \ + --usbdevice disk:format=qcow2:../usb.img \ + --enable-kvm + + + +Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (version 2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + +Hello, +While fuzzing, I found an input that triggers this assertion-failure in usb_ep_get + +/home/alxndr/Development/qemu/hw/usb/core.c:723: struct USBEndpoint *usb_ep_get(USBDevice *, int, int): Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed. +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555557fd2c60 <str> "pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT", file=0x555557fd1ec0 <str> "/home/alxndr/Development/qemu/hw/usb/core.c", line=0x2d3, function=0x555557fd2c00 <__PRETTY_FUNCTION__.usb_ep_get> "struct USBEndpoint *usb_ep_get(USBDevice *, int, int)") at assert.c:101 +#4 0x000055555724690a in usb_ep_get (dev=0x623000001d00, pid=0x0, ep=0x2) at /home/alxndr/Development/qemu/hw/usb/core.c:723 +#5 0x00005555572bdd8e in ehci_execute (p=0x611000048480, action=0x555557fdd860 <str> "process") at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1366 +#6 0x00005555572b74a3 in ehci_state_execute (q=0x60d000004f10) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1942 +#7 0x00005555572b3510 in ehci_advance_state (ehci=0x62100002d9f0, async=0x1) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:2083 +#8 0x00005555572b2db9 in ehci_advance_async_state (ehci=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:2152 +#9 0x00005555572a29c3 in ehci_work_bh (opaque=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:2320 +#10 0x0000555557bfba60 in aio_bh_call (bh=0x60400001cd90) at /home/alxndr/Development/qemu/util/async.c:136 +#11 0x0000555557bfc1fe in aio_bh_poll (ctx=0x61300008fa00) at /home/alxndr/Development/qemu/util/async.c:164 +#12 0x0000555557c149e8 in aio_dispatch (ctx=0x61300008fa00) at /home/alxndr/Development/qemu/util/aio-posix.c:380 +#13 0x0000555557c00455 in aio_ctx_dispatch (source=0x61300008fa00, callback=0x0, user_data=0x0) at /home/alxndr/Development/qemu/util/async.c:306 +#14 0x00007ffff7ca89ee in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 + + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 -machine q35 \ +-device ich9-usb-ehci1,bus=pcie.0,addr=1d.7,multifunction=on,id=ich9-ehci-1 \ +-drive if=none,id=usbcdrom,media=cdrom \ +-device usb-storage,bus=ich9-ehci-1.0,port=2,drive=usbcdrom \ +-display none -nodefaults -nographic +outl 0xcf8 0x8000ef10 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000ef14 +outl 0xcf8 0x8000ef04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe0000020 0x4b 0x21fe00695501ff21fe00695501ff21fe00695501ff21fe00695501ff21fe00695501ff21fe00695501ff21fe00695501ff21fe00695501ff21fe00695501ff21fe00695501ff21fe006955 +write 0x5 0x1 0x92 +write 0x15 0x3 0x92ab01 +write 0x1b 0x1 0xab +write 0x1ab9208 0x2 0x92ab +EOF + +I also attached the commands to this launchpad report, in case the formatting +is broken: + +qemu-system-i386 \ +-qtest stdio -nographic -monitor none -serial none \ +-M pc-q35-5.0 -machine q35 \ +-device ich9-usb-ehci1,bus=pcie.0,addr=1d.7,multifunction=on,id=ich9-ehci-1 \ +-drive if=none,id=usbcdrom,media=cdrom \ +-device usb-storage,bus=ich9-ehci-1.0,port=2,drive=usbcdrom \ +-display none -nodefaults -nographic < attachment + +Please let me know if I can provide any further info. +-Alex + + +We can reproduce this bug in QEMU 5.0.0 + +``` +qemu-system-x86_64: hw/usb/core.c:723: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed. +``` + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash.iso -nographic -m 100 -enable-kvm -net none -device ich9-usb-ehci1 -device usb-tablet +``` + +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 +``` + + + + +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/119 + + diff --git a/results/classifier/108/other/1525676 b/results/classifier/108/other/1525676 new file mode 100644 index 000000000..163ecd386 --- /dev/null +++ b/results/classifier/108/other/1525676 @@ -0,0 +1,64 @@ +other: 0.925 +semantic: 0.894 +debug: 0.886 +permissions: 0.884 +graphic: 0.876 +device: 0.824 +PID: 0.816 +socket: 0.782 +performance: 0.756 +network: 0.752 +boot: 0.726 +vnc: 0.720 +files: 0.708 +KVM: 0.621 + +qemu runas and sandbox option incompatible, process will hang in futex after setgid + +With -runas [user] and -sandbox on, qemu process will fail in the process of dropping privileges. While setgid() is done (see below), setuid() is not attempted. Instead process blocks waiting for a futex never to come. + +[pid 21769] +++ killed by SIGSYS +++ +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] tgkill(21767, 21768, SIGRT_1 <unfinished ...> +[pid 21768] <... nanosleep resumed> {0, 7284187}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) +[pid 21768] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=21767, si_uid=0} --- +[pid 21768] setgid(100) = 0 +[pid 21768] futex(0x7f7f0f53fd1c, FUTEX_WAKE_PRIVATE, 1) = 0 +[pid 21768] rt_sigreturn() = -1 EINTR (Interrupted system call) +[pid 21768] nanosleep({0, 7284187}, <unfinished ...> +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] futex(0x7ffd5a9b6890, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...> +[pid 21768] <... nanosleep resumed> 0x7f7f0f53eb00) = 0 +[pid 21768] futex(0x55f52acd1f44, FUTEX_WAIT, 4294967295, NULL + +This bug might be addresses in the discussion/patchset http://qemu.11.n7.nabble.com/PATCH-Add-syscalls-for-runas-and-chroot-to-the-seccomp-sandbox-td359588.html + +# lsb_release -rd +Description: Ubuntu 15.10 +Release: 15.10 + +# apt-cache policy qemu-system-x86 +qemu-system-x86: + Installed: 1:2.3+dfsg-5ubuntu9.1 + Candidate: 1:2.3+dfsg-5ubuntu9.1 + Version table: + *** 1:2.3+dfsg-5ubuntu9.1 0 + 500 http://archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages + 500 http://archive.ubuntu.com/ubuntu/ wily-security/main amd64 Packages + 100 /var/lib/dpkg/status + 1:2.3+dfsg-5ubuntu9 0 + 500 http://archive.ubuntu.com/ubuntu/ wily/main amd64 Packages + +Yes, it looks like that discussion is related. Though I also got the impression that there is currently still some decision going on how exactly to fix this. So it feels like we should wait with any fix until this decision is made (and a fix is committed into qemu's upstream repo)... + +hmm, the change still did not made it upstream. +I lost track on it and only see it now checking bugs that became dormant - was that fixed in another way? + +There is some overlap with LP: #1675114 so you might be interested to know that @otubo is working on refactoring seccomp for upstream. No firm ETA yet but he thinks that 18.04 would be doable. + +I haven't tried, but I think this should be fixed now with the new elevateprivileges parameter of the -sandbox option. Have you tried to reproduce the problem with the latest version of QEMU already? + +[Expired for qemu (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/108/other/1525682 b/results/classifier/108/other/1525682 new file mode 100644 index 000000000..7ff4b16d8 --- /dev/null +++ b/results/classifier/108/other/1525682 @@ -0,0 +1,143 @@ +other: 0.858 +semantic: 0.805 +debug: 0.780 +device: 0.775 +permissions: 0.773 +KVM: 0.761 +PID: 0.759 +vnc: 0.758 +graphic: 0.756 +performance: 0.754 +socket: 0.703 +files: 0.678 +network: 0.670 +boot: 0.645 + +configure: fix POSIX compatibility issue + +When running configure script from 2.5.0-rc4 on OpenBSD-current (amd64), I get the following error: + + ./configure[4756]: ${nettle:+($nettle_version)}": bad substitution + *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2747 '/usr/ports/pobj/qemu-2.5.0rc4/.configure_done') + *** Error 1 in /usr/ports/openbsd-wip/emulators/qemu (/usr/ports/infrastructure/mk/bsd.port.mk:2491 'configure') + +Indeed, construct "${nettle:+($nettle_version)}" does not conform to POSIX Shell Command Language. The attached patch fixes the issue. + + + +Sorry, wrong patch. + +On Sun, Dec 13, 2015 at 06:39:22PM -0000, Dmitrij D. Czarkoff wrote: +> Sorry, wrong patch. +> +> ** Patch added: "0001-configure-fix-POSIX-compatibility-issue.patch" +> https://bugs.launchpad.net/qemu/+bug/1525682/+attachment/4534158/+files/0001-configure-fix-POSIX-compatibility-issue.patch +> +> ** Patch removed: "0001-configure-fix-POSIX-compatibility-issue.patch" +> https://bugs.launchpad.net/qemu/+bug/1525682/+attachment/4534156/+files/0001-configure-fix-POSIX-compatibility-issue.patch + +Please send patches to <email address hidden>. Guidelines on submitting +patches are here: +http://qemu-project.org/Contribute/SubmitAPatch + +Thanks! + + +In particular, the Signed-off-by: line is critically important -- we cannot apply a patch without one. + +git blame says this + syntax was originally introduced in commit becaeb726 in July (though at that point the variable name was slightly different: ${gnutls_nettle+($nettle_version)} ). That means we were using this construct in v2.4.0, so this is not a regression for 2.5.0. + +I'm also a bit confused by your patch and your original bug report. The error message you quote is complaining about a line with ":+" syntax, but upstream configure is not using ":+" syntax here. Indeed your patch is changing it from + to :+. + + -echo "nettle $nettle ${nettle+($nettle_version)}" + +echo "nettle $nettle ${nettle:+($nettle_version)}" + +It's not clear to me why this would help, because +http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 +(section "Parameter Expansion") which documents the syntax describes both ":+" and "+", so whatever the shell is complaining about it presumably isn't the + vs :+ distinction. + +Which shell is this? + + +OK, so I misidentified the issue and screwed up my bug report. + +The shell is pdksh on OpenBSD, and the real issue is with parentheses: + + $ a=1 + $ b=2 + $ echo "${a+($b)}" + ksh: ${a+($b)}": bad substitution + $ echo "${a+\($b\)}" + (2) + +Unfortunately in bash and dash backslash-escaping the brackets results in the backslashes being printed verbatim: +$ (a=1 b=2 ; echo "${a+\($b\)}") +\(2\) + +Can you try this syntax with extra quote characters? (It works in bash/dash): +(a=1 b=2 ; echo "${a+"($b)"}") +(2) + + +It works. + +Thanks. I'll send out a patch. + + +Actually it turns out we really shouldn't be using the ${} syntax anyway, because if nettle is not present we end up printing +"nettle: no ()" +because $nettle is set to "no", not null or unset. So we should just write this out like: +if test "$nettle" = "yes"; then + echo "nettle $nettle ($nettle_version)" +else + echo "nettle $nettle" +fi + + +FWIW this way it is also consistent with other check results reporting, eg. spice. + +The patch to fix this is at: http://patchwork.ozlabs.org/patch/556537/ + +Unfortunately it has just missed the cutoff to get into 2.5.0 (since it has been present since 2.4.0 and there is a workaround of running "/path/to/bash configure"). We'll put it into the next 2.5.x stable release, though. + + +[adding autoconf, which likes to document shell bugs] + +On 12/14/2015 04:34 AM, Dmitrij D. Czarkoff wrote: +> OK, so I misidentified the issue and screwed up my bug report. +> +> The shell is pdksh on OpenBSD, and the real issue is with parentheses: +> +> $ a=1 +> $ b=2 +> $ echo "${a+($b)}" +> ksh: ${a+($b)}": bad substitution + +That's a bug in pdksh; see the POSIX interpretation: + +http://austingroupbugs.net/view.php?id=221#c399 + + For parameter expansions other than the four varieties that provide + for substring processing, within the string of characters from an + enclosed "${" to the matching '}', the double-quotes within which + the expansion occurs shall preserve the literal value of all + characters, with the exception of the characters double-quote, + backquote, <dollar-sign>, and <backslash>. + +The fact that you are using "" outside the ${} means that all characters +between + and } should be used literally (the same as if you had done +'echo "($b)"'). According to POSIX, it should not be a syntax error, so +you should report this to the pdksh shell developers. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Note that mksh is virtually a superset of OpenBSD ksh and accepts this construct, for a quick fix. + +The patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=18f49881cf8359e89396aac +... which should be part of QEMU 2.6.0, so let's mark this bug report as fixed. + diff --git a/results/classifier/108/other/1526 b/results/classifier/108/other/1526 new file mode 100644 index 000000000..ee6ce0f6d --- /dev/null +++ b/results/classifier/108/other/1526 @@ -0,0 +1,16 @@ +other: 0.847 +device: 0.827 +network: 0.724 +performance: 0.571 +vnc: 0.488 +socket: 0.451 +boot: 0.429 +semantic: 0.389 +debug: 0.388 +graphic: 0.311 +files: 0.257 +KVM: 0.172 +permissions: 0.164 +PID: 0.102 + +hw/vfio/trace-events incorrect format diff --git a/results/classifier/108/other/1527 b/results/classifier/108/other/1527 new file mode 100644 index 000000000..54d407075 --- /dev/null +++ b/results/classifier/108/other/1527 @@ -0,0 +1,18 @@ +other: 0.963 +device: 0.921 +semantic: 0.805 +graphic: 0.661 +debug: 0.566 +boot: 0.521 +network: 0.503 +performance: 0.398 +files: 0.297 +socket: 0.270 +PID: 0.248 +vnc: 0.243 +KVM: 0.237 +permissions: 0.216 + +-blockdev option missing host_device documenation and command line help support +Additional information: +We recommend -blockdev in the documentation as the preferred way to configure storage backends but the online help isn't useful. We also seem to be missing information for some of the blockdev drivers, for example host_device. diff --git a/results/classifier/108/other/1527322 b/results/classifier/108/other/1527322 new file mode 100644 index 000000000..a4e93afc3 --- /dev/null +++ b/results/classifier/108/other/1527322 @@ -0,0 +1,67 @@ +other: 0.710 +device: 0.681 +graphic: 0.679 +network: 0.645 +performance: 0.610 +debug: 0.601 +permissions: 0.585 +socket: 0.570 +KVM: 0.562 +semantic: 0.560 +boot: 0.560 +PID: 0.545 +vnc: 0.500 +files: 0.495 + +segfault in thread-pool.c:246:5: + +Building qemu-2.5.0 with -fsanitize=undefined shows, e.g.: + +markus@x4 linux % qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user -fsdev local,security_model=none,id=root,path=/ -device virtio-9p-pci,id=root,fsdev +=root,mount_tag=/dev/root -m 512 -smp 2 -kernel /usr/src/linux/arch/x86/boot/bzImage -nographic -append "init=/bin/zsh root=/dev/root console=ttyS0 kgdboc=ttyS0 rootflags=rw, +trans=virtio rootfstype=9p ip=dhcp earlyprintk=ttyS0" +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/exec.c:307:5: runtime error: variable length array bound evaluates to non-positive value 0 +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/hw/i386/kvm/apic.c:37:47: runtime error: left shift of 15 by 28 places cannot be represented in type 'int' +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/include/qemu/rcu.h:85:21: runtime error: member access within null pointer of type 'struct rcu_reader_data' +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/include/qemu/rcu.h:101:5: runtime error: member access within null pointer of type 'struct rcu_reader_data' +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/include/qemu/rcu.h:102:8: runtime error: member access within null pointer of type 'struct rcu_reader_data' +... +ALSA device list: + No soundcards found. +/var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/thread-pool.c:246:5: runtime error: member access within null pointer of type 'struct ThreadPool' +[1] 9295 segmentation fault qemu-system-x86_64 -s -enable-kvm -net nic,vlan=0,model=virtio -net user + +As you can see it segfaults when build with upcoming gcc-6, that is more aggressive when it comes to undefined behavior. +The compiler just assumes that "this" can never be NULL and optimizes accordingly. + +It also segfaults when build with gcc-4.9.4 or gcc-5.3. + +Program received signal SIGSEGV, Segmentation fault. +thread_pool_submit_aio (pool=0x0, func=0x555555820bc0 <coroutine_enter_func>, arg=0x5555579db430, cb=<optimized out>, opaque=<optimized out>) + at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/thread-pool.c:246 +246 QLIST_INSERT_HEAD(&pool->head, req, all); +(gdb) bt +#0 thread_pool_submit_aio (pool=0x0, func=0x555555820bc0 <coroutine_enter_func>, arg=0x5555579db430, cb=<optimized out>, opaque=<optimized out>) + at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/thread-pool.c:246 +#1 0x00005555559451cd in aio_bh_call (bh=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/async.c:64 +#2 aio_bh_poll (ctx=ctx@entry=0x5555561c1da0) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/async.c:92 +#3 0x00005555559524f0 in aio_dispatch (ctx=0x5555561c1da0) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/aio-posix.c:305 +#4 0x0000555555944f4e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) + at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/async.c:231 +#5 0x00007ffff726ce2e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#6 0x0000555555950baa in glib_pollfds_poll () at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/main-loop.c:211 +#7 os_host_main_loop_wait (timeout=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/main-loop.c:256 +#8 main_loop_wait (nonblocking=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/main-loop.c:504 +#9 0x00005555556ddf46 in main_loop () at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/vl.c:1923 +#10 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /var/tmp/portage/app-emulation/qemu-2.5.0/work/qemu-2.5.0/vl.c:4684 +(gdb) p pool +$1 = (ThreadPool *) 0x0 + + +This issue was fixed with the following upstream commit: + +http://git.qemu.org/?p=qemu.git;a=commit;h=4b3a4f2d458ca5a7c6c16ac36a8d9ac22cc253d6 + +Shipped in QEMU 2.5.1 and 2.6. + + diff --git a/results/classifier/108/other/1527765 b/results/classifier/108/other/1527765 new file mode 100644 index 000000000..f90b7a6b1 --- /dev/null +++ b/results/classifier/108/other/1527765 @@ -0,0 +1,168 @@ +other: 0.872 +permissions: 0.851 +graphic: 0.848 +debug: 0.822 +performance: 0.807 +semantic: 0.800 +device: 0.800 +boot: 0.779 +KVM: 0.763 +PID: 0.760 +socket: 0.743 +vnc: 0.735 +network: 0.716 +files: 0.715 + +sh4: ghc randomly segfaults on qemu-sh4-static + +Hello! + +I am currently in the process of bootstrapping ghc for the Debian sh4 port and ran into a strange problem with qemu-sh4-static which randomly segfaults when running ghc to compile a Haskell source: + +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ls +Main.hi Main.hs Setup.hs ghc-pwd.cabal ghc.mk +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +Bad interface file: /usr/local/lib/sh4-unknown-linux-gnu-ghc-7.10.3/time/dist-install/build/Data/Time/Format/Parse.hi + ghc: panic! (the 'impossible' happened) + (GHC version 7.10.3 for sh4-unknown-linux): + getSymtabName:unknown known-key unique +<<details unavailable>> + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +Linking Main ... +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# + +As seen above, compiling a Haskell source code often results in a segfault but simply by retrying to run ghc over and over again, the compile process will eventually succeed and no segfault occurs. + +I have created a tarball which contains the sh4 chroot from the example above which also includes ghc, gcc and the source code in question (in /root/ghc-7.8.4/utils/ghc-pwd). To test, it's probably a good idea to replace the qemu-sh4-static binary in /usr/bin with a current git snapshot (which I tried but didn't help). + +> http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz + +In case anyone wants to try ghc with their own sh4 chroot, here's my version of ghc: + +> https://people.debian.org/~glaubitz/sh4-unknown-linux-gnu-ghc-7.10.3.tar.gz + +Just extract in the chroot of the sh4 chroot. + +Please note, that it might be advisable on sh4 to apply the patches from these two bug reports as otherwise qemu-sh4-static won't work properly on sh4 and misses syscall 186: + +> https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1254824 +> https://bugs.launchpad.net/qemu/+bug/1516408 + +The above issue is reproducible with the two patches applied and without. It's also reproducible with both libc6 2.19 and 2.21 in the chroot. Thus, I am currently out of ideas what else to test. + +Cheers, +Adrian + +Thank you for the 611 MB tar.... + +The behavior is a little bit different on my system: + +root@Quad:~# ls +ghc-7.8.4 ghc_7.8.4-9~bpo8+1.dsc +ghc_7.8.4-9~bpo8+1.debian.tar.xz ghc_7.8.4.orig.tar.xz +root@Quad:~# cd ghc-7.8.4/utils/ghc-p +ghc-pkg/ ghc-pwd/ +root@Quad:~# cd ghc-7.8.4/utils/ghc-p +ghc-pkg/ ghc-pwd/ +root@Quad:~# cd ghc-7.8.4/utils/ghc-pwd/ +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ls +Main Main.hi Main.hs Main.o Setup.hs ghc-pwd.cabal ghc.mk +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main +Main Main.hi Main.hs Main.o +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +root@Quad:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +ghc: pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) + +The emulated "tas.b" instruction is not atomic, this is why sometimes the locking fails... + + +Interestingly, cmake also seems to crash in a similar way: + +- Log: https://buildd.debian.org/status/fetch.php?pkg=apt-cacher-ng&arch=sh4&ver=0.8.8-1&stamp=1450985460 +- Log: https://buildd.debian.org/status/fetch.php?pkg=texworks&arch=sh4&ver=0.5~svn1363-6%2Bb1&stamp=1450992669 +- Log: https://buildd.debian.org/status/fetch.php?pkg=x265&arch=sh4&ver=1.8-6&stamp=1450995672 +- Log: https://buildd.debian.org/status/fetch.php?pkg=libwebsockets&arch=sh4&ver=1.6.0-2&stamp=1450997039 + +Maybe those are related? + +Just tested with the latest git snapshot of qemu, still no improvement: + +... +checking for gfind... no +checking for find... /usr/bin/find +checking for sort... /usr/bin/sort +checking for GHC Git commit id... given 4986837f8168cacf95c24fecc84d7b36c47f3c11 +checking version of ghc... 8.0.1 +ghc: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +ghc: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +ghc: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Bootstrapping GHC is a cross compiler. This probably isn't going to work +checking build system type... sh4-unknown-linux-gnu +checking host system type... sh4-unknown-linux-gnu +checking target system type... sh4-unknown-linux-gnu +Build platform inferred as: sh4-unknown-linux +Host platform inferred as: sh4-unknown-linux +Target platform inferred as: sh4-unknown-linux +GHC build : sh4-unknown-linux +GHC host : sh4-unknown-linux +GHC target : sh4-unknown-linux +configure: Building in-tree ghc-pwd +(hangs here) + +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/108/other/1528214 b/results/classifier/108/other/1528214 new file mode 100644 index 000000000..6df1daa12 --- /dev/null +++ b/results/classifier/108/other/1528214 @@ -0,0 +1,60 @@ +semantic: 0.888 +other: 0.887 +permissions: 0.886 +debug: 0.882 +graphic: 0.863 +PID: 0.842 +network: 0.840 +performance: 0.838 +vnc: 0.837 +KVM: 0.829 +device: 0.826 +socket: 0.811 +files: 0.782 +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/108/other/1528239 b/results/classifier/108/other/1528239 new file mode 100644 index 000000000..220e863c5 --- /dev/null +++ b/results/classifier/108/other/1528239 @@ -0,0 +1,68 @@ +semantic: 0.668 +debug: 0.549 +performance: 0.545 +PID: 0.514 +device: 0.490 +socket: 0.473 +graphic: 0.465 +network: 0.443 +files: 0.440 +permissions: 0.429 +vnc: 0.425 +KVM: 0.375 +boot: 0.300 +other: 0.226 + +Unable to debug PIE binaries with QEMU gdb stub. + +The issue occurs on current trunk: + +max@max:~/build/qemu$ cat test.c +#include <stdio.h> + +int main() { + printf("Hello, world!\n"); + return 0; +} + +max@max:~/build/qemu$ gcc test.c -fPIC -pie -o bad.x +max@max:~/build/qemu$ ./x86_64-linux-user/qemu-x86_64 -g 1234 bad.x +............................. + + +max@max:~/build/qemu$ gdb +GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 +........................................................................................ +(gdb) file bad.x +Reading symbols from bad.x...(no debugging symbols found)...done. +(gdb) b main +Breakpoint 1 at 0x779 +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +Reading symbols from /lib64/ld-linux-x86-64.so.2...warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). + +Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done. +done. +Loaded symbols for /lib64/ld-linux-x86-64.so.2 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +0x0000004000a042d0 in _start () from /lib64/ld-linux-x86-64.so.2 +(gdb) c +Continuing. +[Inferior 1 (Remote target) exited normally] +(gdb) + + +max@max:~/build/qemu$ cat config.log +# Configured with: '/home/max/src/qemu/configure' '--prefix=/home/max/install/qemu' '--target-list=arm-linux-user,aarch64-linux-user,x86_64-linux-user' '--static' + + +W/O QEMU or -pie flag breakpoint on main works fine. + +GDB server itself actually supports PIE binaries. + +This patch https://<email address hidden>/ fixes the issue. + +Patch has been included in QEMU v4.2: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=dc12567a53c88d7a91b9 + diff --git a/results/classifier/108/other/1529 b/results/classifier/108/other/1529 new file mode 100644 index 000000000..cbcab96ad --- /dev/null +++ b/results/classifier/108/other/1529 @@ -0,0 +1,16 @@ +semantic: 0.726 +performance: 0.319 +graphic: 0.187 +permissions: 0.171 +other: 0.072 +device: 0.028 +network: 0.019 +files: 0.012 +boot: 0.006 +KVM: 0.005 +debug: 0.005 +socket: 0.002 +vnc: 0.002 +PID: 0.002 + +Documentation refers to Windows Hypervisor Platform as wphx instead of whpx diff --git a/results/classifier/108/other/1529226 b/results/classifier/108/other/1529226 new file mode 100644 index 000000000..1b65fab82 --- /dev/null +++ b/results/classifier/108/other/1529226 @@ -0,0 +1,53 @@ +graphic: 0.733 +performance: 0.555 +semantic: 0.540 +device: 0.503 +other: 0.481 +permissions: 0.417 +files: 0.351 +boot: 0.306 +PID: 0.289 +network: 0.247 +debug: 0.194 +socket: 0.193 +vnc: 0.176 +KVM: 0.036 + +qemu-i386-user on 32-bit Linux: uncaught target signal 11 + +Even though the command I'm trying to run (a wrapper script for qemu-i386-user running rustc, the rust compiler) produces the expected compiled output, the build process is interrupted: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +i686-unknown-linux-gnu/stage0/bin/rustc: line 1: 7474 Segmentation fault /usr/local/bin/qemu-i386 -cpu qemu32 /home/petevine/stage0/rustc.bin -C target-cpu=pentium2 -L /home/petevine/unpacked/rust-master/i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/ "$@" +make: *** [i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.rustc_back] Error 139 + +The stamp file is not being created so this could be about forking bash after finishing the wrapper script. + +Qemu was compiled from the latest git source. + +Hi; thanks for this bug report. Could you provide instructions for how to reproduce this bug, please? + + +My recollection is fuzzy but it would probably amount to something like this on any platform currently: + +- download rust-1.10 beta source https://static.rust-lang.org/dist/rustc-beta-src.tar.gz + +- download this stage0 snapshot https://www.dropbox.com/s/01ywl9mwwo6xojw/rust-stage0-2016-04-18-b324fa7-linux-armv7.tar.xz?dl=0 + +- unpack the stage0 rustc binary to ~/somewhere/bin, renaming it to rustc.bin, and create a wrapper script named rustc in that directory containing: + +`/usr/bin/qemu-arm ~/somewhere/rustc.bin "$@"` + +In the rustc source directory, start the rust bootstrap process (with LLVM 3.7 or higher installed) issuing the following command: +`./configure --enable-optimize --enable-local-rust --local-rust-root=~/somewhere --llvm-root=/usr` + +Followed by `make`. + +At the time of the original report, QEMU wasn't able to complete all crates' build commands naturally. (the stamp file had to be created manually to continue) + +A simpler way to reproduce would probably be to wrap the regular, installed rustc that way and try running some compilations using cargo. That should be enough to elicit the same problem. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1529449 b/results/classifier/108/other/1529449 new file mode 100644 index 000000000..dcfb54f7c --- /dev/null +++ b/results/classifier/108/other/1529449 @@ -0,0 +1,210 @@ +permissions: 0.911 +semantic: 0.896 +device: 0.895 +other: 0.887 +debug: 0.879 +network: 0.862 +performance: 0.861 +PID: 0.860 +graphic: 0.849 +files: 0.844 +vnc: 0.838 +boot: 0.819 +socket: 0.812 +KVM: 0.788 + +serial is required for -device nvme + +I am not exactly sure if this is a bug, but I don't see why the option "serial" is required for -device nvme like drive. Truth is it seem to accept random string as its value anyway, if that's the case, couldn't qemu just generate one for it when it's not specified? + +On Mon, Jan 11, 2016 at 05:35:50PM +0100, Markus Armbruster wrote: +> Tom Yan <email address hidden> writes: +> > Public bug reported: +> > +> > I am not exactly sure if this is a bug, but I don't see why the option +> > "serial" should be required for -device nvme like the option "drive". +> > Truth is it seem to accept random string as its value anyway, if that's +> > the case, couldn't qemu just generate one for it when it's not +> > specified? +> +> You should've included a reproducer. Here are mine: +> +> 1. Bad error reporting on missing drive: +> +> $ upstream-qemu -nodefaults -device nvme +> upstream-qemu: -device nvme: Device initialization failed +> +> Expected: error reported like for other devices, e.g. +> +> $ upstream-qemu -nodefaults -device virtio-blk +> upstream-qemu: -device virtio-blk: drive property not set +> +> 2. Bad error reporting on empty drive: +> +> $ upstream-qemu -nodefaults -drive if=none,id=foo -device nvme,drive=foo +> upstream-qemu: -device nvme,drive=foo: Device initialization failed +> +> Expected: error is reported like for other devices, e.g. +> +> $ upstream-qemu -nodefaults -drive if=none,id=foo -device virtio-blk,drive=foo +> upstream-qemu: -device virtio-blk,drive=foo: Device needs media, but drive is empty +> +> 3. Bad handling of missing serial: +> +> $ upstream-qemu -nodefaults -drive if=none,id=foo,file=tmp.qcow2 -device nvme,drive=foo +> upstream-qemu: -device nvme,drive=foo: Device initialization failed +> +> Expected: either default the serial number, like some other devices +> do, or a decent error message. +> +> I recommend to convert the device to realize(), and add the missing +> error_setg(). Keith? + +Requiring a serial was a concious choice to push that responsibility +on the user, but I don't see a problem having the code provide default +serial string if the user does not over ride it. + +If you've multiple nvme devices in your guest, creating the same serial +could cause problems with multipathing if they're basing end device +uniqueness on the serial (some do). If we have the code provide the +serial, perhaps it would be best to make each unique. That's easy enough +to append an incrementing number to the end of the serial. + + +Instead of requiring a serial of arbitrary length/format, I think a WWN/EUI-64 is more useful/important, not to mention that the WWN/EUI-64 can pretty much always be used as the serial at the same time. + +Unlike Linux, Windows consider the WWN/EUI-64 as the "serial": + +"C:\Windows\system32>sg_vpd -i PD1 +Device Identification VPD page: + Addressed logical unit: + designator type: SCSI name string, code set: UTF-8 + SCSI name string: + 8086QEMU NVMe Ctrl 00012BDAC262CF831698 + +C:\Windows\system32>sg_vpd -p sn PD1 +Unit serial number VPD page: + Unit serial number: 0000_0000_0000_0000." + +(https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650553/+files/02.PNG) + +UEFI also makes use of the WWN/EUI-64 to generate boot entries for NVMe devices: +https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650554/+files/03.png +https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650555/+files/04.png + + +On 04/28/16 20:07, Tom Yan wrote: +> Instead of requiring a serial of arbitrary length/format, I think a +> WWN/EUI-64 is more useful/important, + +WWN/EUI-64 is not "more important". Section "7.9 Unique Identifier" in +the NVMe spec (Revision 1.2a, October 23, 2015) says that the serial +number is mandatory, while implementing an EUI-64 is optional. Let me +quote it all (emphases mine): + +> 7.9 Unique Identifier +> +> Information is returned in the Identify Controller data structure that +> may be used to construct a unique identifier. Specifically, the PCI +> Vendor ID, *Serial Number*, and Model Number fields when combined +> shall form a globally unique value that identifies the NVM subsystem. +> The mechanism used by the vendor to assign Serial Number and Model +> Number values to ensure uniqueness is *outside the scope* of this +> specification. +> +> An NVM subsystem may contain multiple controllers. All of the +> controllers that make up an NVM subsystem share the same NVM subsystem +> identifier (i.e., PCI Vendor ID, Serial Number, and Model Number). The +> Controller ID (CNTLID) value returned in the Identify Controller data +> structure may be used to uniquely identify a controller within an NVM +> subsystem. The Controller ID value when combined with the NVM +> subsystem identifier forms a globally unique value that identifies the +> controller. The mechanism used by the vendor to assign Controller ID +> values is outside the scope of this specification. +> +> The Identify Namespace data structure contains the IEEE Extended +> Unique Identifier (EUI64) and the Namespace Globally Unique Identifier +> (NGUID) fields. EUI64 is an 8-byte EUI-64 identifier and NGUID is a +> 16-byte identifier based on EUI-64. When creating a namespace, the +> controller specifies a globally unique value in the EUI64 or NGUID +> field (the controller may optionally specify a globally unique value +> in both fields). In cases where the 64-bit EUI64 field is unable to +> ensure a globally unique namespace identifier, the EUI64 field shall +> be cleared to 0h. *When not implemented*, these fields contain a value +> of 0h. + +The QEMU device model conforms to this: + +- The serial number is mandatory, and its generation is unspecified. +(First paragraph quoted.) Accordingly, QEMU forces the user to generate +and provide a serial number. + +- The EUI64 is optional (third paragraph); it shall be zero-filled when +not implemented. QEMU conforms. + +> not to mention that the WWN/EUI-64 +> can pretty much always be used as the serial at the same time. +> +> Unlike Linux, Windows consider the WWN/EUI-64 as the "serial": + +That's Windows's problem. Not the first (and not the last) occasion +where Microsoft interpret a specification creatively. + +> "C:\Windows\system32>sg_vpd -i PD1 +> Device Identification VPD page: +> Addressed logical unit: +> designator type: SCSI name string, code set: UTF-8 +> SCSI name string: +> 8086QEMU NVMe Ctrl 00012BDAC262CF831698 +> +> C:\Windows\system32>sg_vpd -p sn PD1 +> Unit serial number VPD page: +> Unit serial number: 0000_0000_0000_0000." +> +> (https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650553/+files/02.PNG) +> +> UEFI also makes use of the WWN/EUI-64 to generate boot entries for NVMe devices: +> https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650554/+files/03.png +> https://bugs.launchpad.net/qemu/+bug/1576347/+attachment/4650555/+files/04.png + +The UEFI specification (version 2.6, January 2016) says in "9.3.5.22 NVM +Express namespace messaging device path node": + + Mnemonic: IEEE Extended Unique Identifier + Byte Offset: 8 + Byte Length: 8 + Description: This field contains the IEEE Extended Unique + Identifier (EUI-64). Devices without an EUI-64 value + must initialize this field with a value of 0. + +QEMU conforms. + +The device paths visible on your OVMF screenshots are distinguishable +from each other by their Pci() device path nodes. There is no collision. + +I recommend reviewing the following commits: + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a907ec52cc1a +https://github.com/tianocore/edk2/commit/d7c0dfaef26c + +The point being: if QEMU grows a capability to store a nonzero EUI64, +and that EUI64 is reflected in the OpenFirmware device path that is +placed into the "bootorder" fw_cfg file, then OVMF will parse it just +fine. However, QEMU is not required to grow such a capability, according +to the NVMe and UEFI specifications. In practice, multiple NVMe devices +can be distinguished from each other by their different PCI B/D/F locations. + +Thanks, +Laszlo + + +Since both "drive=" and "serial=" expects an arbitrary string (while the value for "drive=" must be unique since it's the "id=" of a "-drive"), why not use the same string from "drive=" as the value of "serial=" when it's not specified explicitly? + +Apparently "-device scsi-hd" has already been doing that (although it does not create the "sn" VPD when a serial is not explicitly specified). + + + + + +No new developments for 4+ years, closing as invalid (I'd prefer "wontfix due to lack of resources", but I'm unable to pick that resolution). + diff --git a/results/classifier/108/other/1529764 b/results/classifier/108/other/1529764 new file mode 100644 index 000000000..df01d641f --- /dev/null +++ b/results/classifier/108/other/1529764 @@ -0,0 +1,30 @@ +graphic: 0.784 +device: 0.781 +files: 0.627 +permissions: 0.550 +network: 0.525 +PID: 0.485 +performance: 0.482 +semantic: 0.476 +other: 0.471 +socket: 0.430 +vnc: 0.429 +boot: 0.410 +debug: 0.330 +KVM: 0.274 + +No video output with the official Windows XP VMWare VGA driver + +Steps to reproduce: + +1) Set -vga to vmware +2) Install Windows XP SP3 +3) Install VGA drivers from http://packages.vmware.com/tools/releases/latest/windows/x86/VMware-tools-windows-10.0.5-3227872.iso + +Result: completely black screen (even after F8 -> use VGA mode). + +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/108/other/1529859 b/results/classifier/108/other/1529859 new file mode 100644 index 000000000..d922e398a --- /dev/null +++ b/results/classifier/108/other/1529859 @@ -0,0 +1,212 @@ +graphic: 0.825 +socket: 0.802 +performance: 0.802 +permissions: 0.797 +other: 0.789 +debug: 0.788 +PID: 0.785 +semantic: 0.768 +network: 0.753 +files: 0.751 +boot: 0.743 +device: 0.738 +KVM: 0.589 +vnc: 0.553 + +qemu 2.5.0 ivshmem segfault with msi=off option + +Launching qemu with "-device ivshmem,chardev=ivshmemid,msi=off -chardev socket,path=/tmp/ivshmem_socket,id=ivshmemid" + +Causes segfault because, s->msi_vectors is not initialized and s->msi_vectors == 0. + +Does ivshmem exactly need this line ? : + +s->msi_vectors[vector].pdev = pdev; + +It makes no sence for me. + +Subject: [PATCH] fixed ivshmem empty msi vector on msi=off segfault + +--- + hw/misc/ivshmem.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c +index f73f0c2..2087d5e 100644 +--- a/hw/misc/ivshmem.c ++++ b/hw/misc/ivshmem.c +@@ -359,8 +359,6 @@ static CharDriverState* create_eventfd_chr_device(void * opaque, EventNotifier * + int eventfd = event_notifier_get_fd(n); + CharDriverState *chr; + +- s->msi_vectors[vector].pdev = pdev; +- + chr = qemu_chr_open_eventfd(eventfd); + + if (chr == NULL) { +@@ -1038,10 +1036,11 @@ static void pci_ivshmem_exit(PCIDevice *dev) + } + + if (ivshmem_has_feature(s, IVSHMEM_MSI)) { +- msix_uninit_exclusive_bar(dev); ++ msix_uninit_exclusive_bar(dev); + } +- +- g_free(s->msi_vectors); ++ ++ if(s->msi_vectors) ++ g_free(s->msi_vectors); + } + + static bool test_msix(void *opaque, int version_id) +-- +2.3.6 + +On 12/29/2015 06:38 AM, maquefel wrote: +> Public bug reported: +> +> Launching qemu with "-device ivshmem,chardev=ivshmemid,msi=off -chardev +> socket,path=/tmp/ivshmem_socket,id=ivshmemid" +> +> Causes segfault because, s->msi_vectors is not initialized and +> s->msi_vectors == 0. +> +> Does ivshmem exactly need this line ? : +> +> s->msi_vectors[vector].pdev = pdev; +> +> It makes no sence for me. +> +> Subject: [PATCH] fixed ivshmem empty msi vector on msi=off segfault + +Patches require a Signed-off-by: line before they can be applied. + +> +> --- +> hw/misc/ivshmem.c | 9 ++++----- +> 1 file changed, 4 insertions(+), 5 deletions(-) +> +> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c +> index f73f0c2..2087d5e 100644 +> --- a/hw/misc/ivshmem.c +> +++ b/hw/misc/ivshmem.c +> @@ -359,8 +359,6 @@ static CharDriverState* create_eventfd_chr_device(void * opaque, EventNotifier * +> int eventfd = event_notifier_get_fd(n); +> CharDriverState *chr; +> +> - s->msi_vectors[vector].pdev = pdev; +> - + +This avoids the segfault, but it may break other uses. Are you sure you +don't need an 'if (s->msi_vectors[vector])' conditional? + +> chr = qemu_chr_open_eventfd(eventfd); +> +> if (chr == NULL) { +> @@ -1038,10 +1036,11 @@ static void pci_ivshmem_exit(PCIDevice *dev) +> } +> +> if (ivshmem_has_feature(s, IVSHMEM_MSI)) { +> - msix_uninit_exclusive_bar(dev); +> + msix_uninit_exclusive_bar(dev); + +I can't see what's changing here. Whitespace? + +> } +> - +> - g_free(s->msi_vectors); +> + +> + if(s->msi_vectors) +> + g_free(s->msi_vectors); + +This hunk is bogus. g_free(NULL) already works properly. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +See previously posted patch: + +http://lists.gnu.org/archive/html/qemu-stable/2015-12/msg00034.html + +On Mon, Jan 4, 2016 at 9:24 PM, Eric Blake <email address hidden> wrote: +> On 12/29/2015 06:38 AM, maquefel wrote: +>> Public bug reported: +>> +>> Launching qemu with "-device ivshmem,chardev=ivshmemid,msi=off -chardev +>> socket,path=/tmp/ivshmem_socket,id=ivshmemid" +>> +>> Causes segfault because, s->msi_vectors is not initialized and +>> s->msi_vectors == 0. +>> +>> Does ivshmem exactly need this line ? : +>> +>> s->msi_vectors[vector].pdev = pdev; +>> +>> It makes no sence for me. +>> +>> Subject: [PATCH] fixed ivshmem empty msi vector on msi=off segfault +> +> Patches require a Signed-off-by: line before they can be applied. +> +>> +>> --- +>> hw/misc/ivshmem.c | 9 ++++----- +>> 1 file changed, 4 insertions(+), 5 deletions(-) +>> +>> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c +>> index f73f0c2..2087d5e 100644 +>> --- a/hw/misc/ivshmem.c +>> +++ b/hw/misc/ivshmem.c +>> @@ -359,8 +359,6 @@ static CharDriverState* create_eventfd_chr_device(void * opaque, EventNotifier * +>> int eventfd = event_notifier_get_fd(n); +>> CharDriverState *chr; +>> +>> - s->msi_vectors[vector].pdev = pdev; +>> - +> +> This avoids the segfault, but it may break other uses. Are you sure you +> don't need an 'if (s->msi_vectors[vector])' conditional? +> +>> chr = qemu_chr_open_eventfd(eventfd); +>> +>> if (chr == NULL) { +>> @@ -1038,10 +1036,11 @@ static void pci_ivshmem_exit(PCIDevice *dev) +>> } +>> +>> if (ivshmem_has_feature(s, IVSHMEM_MSI)) { +>> - msix_uninit_exclusive_bar(dev); +>> + msix_uninit_exclusive_bar(dev); +> +> I can't see what's changing here. Whitespace? +> +>> } +>> - +>> - g_free(s->msi_vectors); +>> + +>> + if(s->msi_vectors) +>> + g_free(s->msi_vectors); +> +> This hunk is bogus. g_free(NULL) already works properly. +> +> -- +> Eric Blake eblake redhat com +1-919-301-3266 +> Libvirt virtualization library http://libvirt.org +> + + + +-- +Marc-André Lureau + + +>See previously posted patch: +> http://lists.gnu.org/archive/html/qemu-stable/2015-12/msg00034.html + +This patch resolves issue. I can confirm it works. + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=47213eb1104709bf23 + |