diff options
Diffstat (limited to '')
29 files changed, 3009 insertions, 0 deletions
diff --git a/results/classifier/108/other/165 b/results/classifier/108/other/165 new file mode 100644 index 000000000..62c17cf40 --- /dev/null +++ b/results/classifier/108/other/165 @@ -0,0 +1,16 @@ +device: 0.716 +performance: 0.624 +KVM: 0.410 +network: 0.409 +permissions: 0.296 +other: 0.282 +semantic: 0.267 +graphic: 0.181 +boot: 0.136 +PID: 0.135 +debug: 0.093 +files: 0.080 +socket: 0.034 +vnc: 0.020 + +No evdev mouse passthrough with virtio-vga or kvm diff --git a/results/classifier/108/other/1650 b/results/classifier/108/other/1650 new file mode 100644 index 000000000..48cc67688 --- /dev/null +++ b/results/classifier/108/other/1650 @@ -0,0 +1,29 @@ +performance: 0.872 +device: 0.836 +graphic: 0.772 +network: 0.750 +semantic: 0.731 +other: 0.692 +debug: 0.675 +PID: 0.551 +vnc: 0.487 +permissions: 0.483 +boot: 0.348 +socket: 0.283 +KVM: 0.226 +files: 0.130 + +Consider doing runtime detection of MAP_FIXED_NOREPLACE +Description of problem: +``` +qemu-i386-static: Unable to reserve 0xfffff000 bytes of virtual address space at 0x1000 (Operation not supported) for use as guest address space (check your virtual memory ulimit setting, min_mmap_addr or reserve less using -R option) +``` +strace says +``` + mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE|MAP_FIXED_NOREPLACE, -1, 0) = -1 EOPNOTSUPP (Operation not supported) +``` +Steps to reproduce: +1. `apt install qemu-i386-static 32subsystem` +2. `strace qemu-i386-static /opt/32/bin/as` +Additional information: +Repeating the strace call in a minimal C program gives the same errno as expected -- the kernel is only 4.4. The problem here is that qemu only does `MAP_FIXED_NOREPLACE` feature detection at build-time via a `#ifndef` and even that behavior is poorly documented. Maybe do something at runtime? diff --git a/results/classifier/108/other/1651 b/results/classifier/108/other/1651 new file mode 100644 index 000000000..d028b8a3b --- /dev/null +++ b/results/classifier/108/other/1651 @@ -0,0 +1,16 @@ +device: 0.892 +performance: 0.858 +network: 0.780 +graphic: 0.589 +files: 0.565 +debug: 0.540 +boot: 0.341 +semantic: 0.264 +other: 0.217 +PID: 0.173 +socket: 0.152 +permissions: 0.127 +vnc: 0.105 +KVM: 0.068 + +bcm2835 timer jumps to max delay diff --git a/results/classifier/108/other/1652011 b/results/classifier/108/other/1652011 new file mode 100644 index 000000000..e109ff843 --- /dev/null +++ b/results/classifier/108/other/1652011 @@ -0,0 +1,157 @@ +graphic: 0.816 +KVM: 0.811 +other: 0.781 +vnc: 0.777 +debug: 0.752 +semantic: 0.749 +socket: 0.725 +device: 0.724 +PID: 0.713 +permissions: 0.684 +performance: 0.664 +boot: 0.663 +network: 0.659 +files: 0.613 + +VM shuts down due to error in qemu block.c + +On a Trusty KVM host one of the guest VMs shut down without any user interaction. The system is running: + +$ cat /etc/lsb-release +DISTRIB_ID=Ubuntu +DISTRIB_RELEASE=14.04 +DISTRIB_CODENAME=trusty +DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS" + +$ dpkg -l libvirt0 qemu-kvm qemu-system-common qemu-system-x86 +Desired=Unknown/Install/Remove/Purge/Hold +| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend +|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) +||/ Name Version Architecture Description ++++-============================================================-===================================-===================================-============================================================================================================================== +ii libvirt0 1.2.2-0ubuntu13.1.17 amd64 library for interfacing with different virtualization systems +ii qemu-kvm 2.0.0+dfsg-2ubuntu1.27 amd64 QEMU Full virtualization +ii qemu-system-common 2.0.0+dfsg-2ubuntu1.27 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-x86 2.0.0+dfsg-2ubuntu1.27 amd64 QEMU full system emulation binaries (x86) + +In the VMs log in /var/lib/libvirt/qemu/hostname we see: + +2016-11-17 09:18:42.603+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 -name hostname,process=qemu:hostname -S -machine pc-i440fx-trusty,accel=kvm,usb=off -m 12697 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 51766564-ed8e-41aa-91b5-574220af4ac3 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hostname.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 -drive file=/dev/disk1/hostname,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=/dev/disk2/hostname_mnt_data,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/dev/disk1/hostname_tmp,if=none,id=drive-virtio-disk2,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk2,id=virtio-disk2 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,tx=bh,netdev=hostnet0,id=net0,mac=52:54:00:45:e7:d9,bus=pci.0,addr=0x6 -netdev tap,fd=31,id=hostnet1,vhost=on,vhostfd=32 -device virtio-net-pci,tx=bh,netdev=hostnet1,id=net1,mac=52:54:00:f6:6c:77,bus=pci.0,addr=0x7 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:5 -device VGA,id=video0,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 +char device redirected to /dev/pts/6 (label charserial0) +qemu-system-x86_64: /build/qemu-PVxDqC/qemu-2.0.0+dfsg/block.c:3491: bdrv_error_action: Assertion `error >= 0' failed. +2016-12-22 09:49:49.392+0000: shutting down + +In /var/lib/libvirt/libvirtd.log we see: + +2016-12-22 09:49:49.298+0000: 6946: error : qemuMonitorIO:656 : internal error: End of file from monitor + +We investigated to see if this is a known issue and came across a bug report for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1147398), but nothing references changes upstream that fix this. + +The guest OS is Ubuntu Precise (12.04.5) running kernel linux-image-3.2.0-101-virtual 3.2.0-101.141. There wasn't any significant load (CPU or IO) on the guest at the time that it shut down and there wasn't any appreciable disk IO on the KVM host either. The disks for the guest are on the KVM host box. + +Please do not report distribution specific bugs (since you're using qemu-kvm 2.0.0+dfsg-2ubuntu1.27) against the QEMU project bugtracker - use the distribution's bugtracker instead. + +Status changed to 'Confirmed' because the bug affects multiple users. + +Description of problem: +VM Guests occasionally hard shutdown unexpectedly with error: + +"qemu-system-x86_64: block.c:2806: bdrv_error_action: Assertion `error >= 0' failed." + +In my environment it only appears to be my Windows 2008R2 guests that are affected, although I know of another environment with SLES guests that are affected. As per email here: http://lists.gnu.org/archive/html/qemu-discuss/2014-06/msg00094.html + + +Version-Release number of selected component (if applicable): + + * qemu-system-x86-1.6.2-5.fc20.x86_64 + +How reproducible: + +It is difficult to reproduce, it occurs roughly once a week each Guest VM for me. + + +Additional info: + * I am running Openstack Icehouse on Fedora 20 (via packstack) + * Kernels: kernel-3.14.4-200.fc20.x86_64 / kernel-3.14.8-200.fc20.x86_64 + * libvirt-1.1.3.5-2.fc20.x86_64 + * Guest OS: Windows 2008R2 + * Guest VirtIO driver version 0.1-81 + * Guest Storage is via NFS export from a Netapp FAS 6220 cluster. + * These unexpected shutdowns do not occur for me at busy times for either the guests or the hosts. + +*** Bug 1147398 has been marked as a duplicate of this bug. *** + +bdrv_error_action is called from 3 places. What is going to +help most of all here is a stack trace. Easiest thing is +to enable core dumps and make sure the core dump is captured when +qemu fails. + +Thanks for the idea. Sounds better than mine to recompile qemu with debug messages. Can you give a hint how to achieve it in an OVirt/libvirt environment. + +I met this problem with qemu-1.6.1 too, while my problem is found at debian7 guests. + +This message is a reminder that Fedora 20 is nearing its end of life. +Approximately 4 (four) weeks from now Fedora will stop maintaining +and issuing updates for Fedora 20. It is Fedora's policy to close all +bug reports from releases that are no longer maintained. At that time +this bug will be closed as EOL if it remains open with a Fedora 'version' +of '20'. + +Package Maintainer: If you wish for this bug to remain open because you +plan to fix it in a currently maintained version, simply change the 'version' +to a later Fedora version. + +Thank you for reporting this issue and we are sorry that we were not +able to fix it before Fedora 20 is end of life. If you would still like +to see this bug fixed and are able to reproduce it against a later version +of Fedora, you are encouraged change the 'version' to a later Fedora +version prior this bug is closed as described in the policy above. + +Although we aim to fix as many bugs as possible during every release's +lifetime, sometimes those efforts are overtaken by events. Often a +more recent Fedora release includes newer upstream software that fixes +bugs or makes them obsolete. + +Since F20 is EOL soon, closing this. If anyone can still reproduce with F21+, please reopen and I'll take a look + +We see this in upstream openstack CI testing, viewable here: + +http://logs.openstack.org/07/251407/2/check/gate-tempest-dsvm-full/144f7fc/logs/libvirt/libvirtd.txt.gz#_2015-11-30_18_20_18_168 + +2015-11-30 18:20:18.168+0000: 31539: error : qemuMonitorIO:656 : internal error: End of file from monitor +2015-11-30 18:20:18.168+0000: 31539: debug : qemuMonitorIO:710 : Error on monitor internal error: End of file from monitor +2015-11-30 18:20:18.168+0000: 31539: debug : qemuMonitorIO:731 : Triggering EOF callback +2015-11-30 18:20:18.168+0000: 31539: debug : qemuProcessHandleMonitorEOF:300 : Received EOF on 0x7fa310011240 'instance-00000066' +2015-11-30 18:20:18.168+0000: 31539: debug : qemuProcessHandleMonitorEOF:318 : Monitor connection to 'instance-00000066' closed without SHUTDOWN event; assuming the domain crashed +2015-11-30 18:20:18.168+0000: 31539: debug : virObjectEventNew:643 : obj=0x7fa340aab850 +2015-11-30 18:20:18.168+0000: 31539: debug : qemuProcessStop:4235 : Shutting down vm=0x7fa310011240 name=instance-00000066 id=150 pid=17830 flags=0 + +This was the domain log: + +http://logs.openstack.org/07/251407/2/check/gate-tempest-dsvm-full/144f7fc/logs/libvirt/qemu/instance-00000066.txt.gz + +I noticed this: + +char device redirected to /dev/pts/1 (label charserial1) +qemu-system-x86_64: /build/qemu-5LgLIn/qemu-2.0.0+dfsg/block.c:3491: bdrv_error_action: Assertion `error >= 0' failed. +2015-11-30 18:20:18.168+0000: shutting down + +This is a volume-backed VM. I think around the time that this fails, we should be trying to plug a virtual interface. + +Possibly also helpful: + +http://logs.openstack.org/07/251407/2/check/gate-tempest-dsvm-full/144f7fc/logs/screen-n-net.txt.gz#_2015-11-30_18_19_45_252 + +2015-11-30 18:19:45.251 DEBUG oslo_concurrency.processutils [req-8911e8c7-2466-408f-832e-af4b78e9adec tempest-TestVolumeBootPattern-2142876884 tempest-TestVolumeBootPattern-1970238908] CMD "sudo nova-rootwrap /etc/nova/rootwrap.conf ebtables --concurrent -t nat -D PREROUTING --logical-in br100 -p ipv4 --ip-src 10.1.0.3 ! --ip-dst 10.1.0.0/20 -j redirect --redirect-target ACCEPT" returned: 255 in 0.147s execute /usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297 + +For comment 7, this is mitaka openstack. + +libvirt version: 1.2.2 + +QEMU 2.0.0 + +Ubuntu 14.04 for the compute host. + +If you are hitting this on ubuntu, you need to file an ubuntu bug. + diff --git a/results/classifier/108/other/1652373 b/results/classifier/108/other/1652373 new file mode 100644 index 000000000..6519dd9d1 --- /dev/null +++ b/results/classifier/108/other/1652373 @@ -0,0 +1,30 @@ +graphic: 0.772 +performance: 0.760 +device: 0.707 +semantic: 0.701 +other: 0.639 +vnc: 0.543 +permissions: 0.540 +files: 0.534 +socket: 0.516 +network: 0.496 +PID: 0.433 +boot: 0.390 +debug: 0.359 +KVM: 0.252 + +User-mode QEMU is not deterministic + +QEMU in user-mode (linux-user or bsd-user) has no way to get the equivalent of the "-icount" argument found in softmmu mode. + +It is true that some system calls in user-mode can prevent deterministic execution, but it would be very simple to patch time-related syscalls to return a number based on icount when in deterministic mode. + +Putting both changes together (icount + time-related syscalls) would cover the needs for deterministic execution of most benchmarks (i.e., those not interacting with the network or other programs in the system). + +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/108/other/1652459 b/results/classifier/108/other/1652459 new file mode 100644 index 000000000..0c84361f3 --- /dev/null +++ b/results/classifier/108/other/1652459 @@ -0,0 +1,40 @@ +device: 0.689 +KVM: 0.656 +network: 0.568 +other: 0.554 +semantic: 0.519 +performance: 0.491 +PID: 0.481 +vnc: 0.479 +files: 0.474 +graphic: 0.455 +socket: 0.436 +debug: 0.435 +permissions: 0.378 +boot: 0.297 + +kvm rbd driver (and maybe others, i.e. qcow2, qed and so on) does not report DISCARD-ZERO flag + +# lsblk -D +NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO +sda 0 4K 1G 0 +├─sda1 0 4K 1G 0 +├─sda2 1024 4K 1G 0 +└─sda5 0 4K 1G 0 + + +Last column should be `1` at least for "RBD+discard=unmap" since reading from discarded regions in RBD MUST return zeroes. The same with QCOW2, QED and sparse raw images. KVM should copy value of this flag when real raw device (i.e. real SSD) with discard capability is used as virtual disk. + +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. + + + +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/139 + + diff --git a/results/classifier/108/other/1653063 b/results/classifier/108/other/1653063 new file mode 100644 index 000000000..ed7d391af --- /dev/null +++ b/results/classifier/108/other/1653063 @@ -0,0 +1,84 @@ +other: 0.879 +permissions: 0.777 +semantic: 0.751 +vnc: 0.726 +debug: 0.725 +KVM: 0.694 +graphic: 0.693 +PID: 0.681 +network: 0.658 +socket: 0.607 +device: 0.606 +boot: 0.598 +files: 0.557 +performance: 0.535 + +qemu-system-arm hangs with -icount and -nodefaults + +I tested with the latest git repo, (commit: dbe2b65566e76d3c3a0c3358285c0336ac61e757). + +My configure options when building QEMU: +'../configure' '--prefix=$HOME/local/qemu.git' '--target-list=aarch64-softmmu,arm-softmmu' '--cpu=x86_64' '--cc=gcc' '--disable-user' '--disable-sdl' '--disable-stack-protector' '--disable-attr' '--disable-pie' '--disable-linux-aio' '--disable-tpm' '--without-system-pixman' '--disable-docs' '--disable-guest-agent' '--disable-guest-agent-msi' '--disable-modules' '--disable-sparse' '--disable-gnutls' '--disable-nettle' '--disable-gcrypt' '--disable-gtk' '--disable-vte' '--disable-curses' '--disable-vnc' '--disable-cocoa' '--disable-virtfs' '--disable-xen' '--disable-brlapi' '--disable-curl' '--disable-bluez' '--disable-rdma' '--disable-uuid' '--disable-vde' '--disable-netmap' '--disable-cap-ng' '--disable-attr' '--disable-vhost-net' '--disable-spice' '--disable-rbd' '--disable-libiscsi' '--disable-libnfs' '--disable-smartcard' '--disable-libusb' '--disable-usb-redir' '--disable-lzo' '--disable-snappy' '--disable-bzip2' '--disable-seccomp' '--disable-glusterfs' '--disable-archipelago' '--disable-libssh2' '--disable-vhdx' '--disable-numa' '--disable-werror' '--disable-blobs' '--disable-vhost-scsi' '--enable-debug' '--disable-strip' '--enable-debug-tcg' '--enable-debug-info' '--extra-cflags=-fPIC' + +My host OS is Redhat RHEL-6.5. uname command gives: +Linux rslpc1 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux + +The test image is downloaded from http://wiki.qemu.org/download/arm-test-0.2.tar.gz + +The command to re-produce the problem: +qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0" + +After console prints the message below: +"Uncompressing Linux.......................................................................... done, booting the kernel." +there's no further action noticed. + +If "-icount" is not set, namely run as: +qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0" + +or if "-nodefaults" is not set, namely run as: +qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 --append "console=ttyAMA0" + +The Linux boot procedure can finish successfully. + +Thanks. +Hansni + +On Thu, Dec 29, 2016 at 5:04 AM, Andrew Jones <email address hidden> wrote: +> On Thu, Dec 29, 2016 at 08:02:16AM -0000, Hansni Bu wrote: +>> Public bug reported: +> ... +>> https://bugs.launchpad.net/bugs/1653063 +> ... +>> After console prints the message below: +>> "Uncompressing Linux.......................................................................... done, booting the kernel." +>> there's no further action noticed. +>> +>> If "-icount" is not set, namely run as: +>> qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0" +>> +>> or if "-nodefaults" is not set, namely run as: +>> qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 --append "console=ttyAMA0" +>> +>> The Linux boot procedure can finish successfully. +> +> Hi Hansni, +> +> The fact things work when you remove -nodefaults is a sign that with it +> your single cpu may just not be getting scheduled again. Does the patch +> from Alex Bennée here[*] help? +> +> [*] https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg01743.html +> + +This bug is still reproducible with the latest git. + +-- +Pranith + +-- +Pranith + + +I think we fixed this bug in commit 013aabdc665e4256b38d which would have been in the 3.1.0 release (this is why we closed #1774677, which is the same issue). + + diff --git a/results/classifier/108/other/1653384 b/results/classifier/108/other/1653384 new file mode 100644 index 000000000..26855df90 --- /dev/null +++ b/results/classifier/108/other/1653384 @@ -0,0 +1,749 @@ +other: 0.664 +graphic: 0.601 +performance: 0.498 +boot: 0.497 +device: 0.488 +semantic: 0.481 +network: 0.475 +KVM: 0.469 +vnc: 0.463 +debug: 0.457 +files: 0.423 +permissions: 0.420 +socket: 0.380 +PID: 0.367 + +Assertion failed with USB pass through with XHCI controller + +Starting qemu 2.8.0 with XHCI controller and host device passed through results in an assertion failure: + +qemu-system-x86_64: hw/usb/core.c:623: usb_packet_cleanup: Assertion `!usb_packet_is_inflight(p)' failed. + +Can be reproduced with the following command (passing through a Lenovo keyboard): + +qemu-system-x86_64 -usb -device nec-usb-xhci,id=usb -device usb-host,vendorid=0x04b3,productid=0x3025,id=hostdev0,bus=usb.0,port=1 + +If nec-usb-xhci is changed to usb-ehci, qemu tries to boot without assertion failures. + + +Can be reproduced with the latest master (commit dbe2b65) and v2.8.0. + +Bisected the issue to following commit: +first bad commit: [94b037f2a451b3dc855f9f2c346e5049a361bd55] xhci: use linked list for transfers + + +Backtrace from commit dbe2b65: + +#0 0x00007f2eb4657227 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 + resultvar = 0 + pid = 3453 + selftid = 3453 +#1 0x00007f2eb465867a in __GI_abort () at abort.c:89 + save_stage = 2 + act = {__sigaction_handler = {sa_handler = 0x4, sa_sigaction = 0x4}, sa_mask = {__val = {140734740550528, 93876690035339, + 140734740550624, 48833659808, 0, 0, 0, 21474836480, 140734740550792, 139838573009553, 140734740550560, 139838573043008, + 139838573024160, 93876666665872, 139838702616576, 139838573024160}}, sa_flags = 1528954938, + sa_restorer = 0x55615b2202c0 <__PRETTY_FUNCTION__.38612>} + sigs = {__val = {32, 0 <repeats 15 times>}} +#2 0x00007f2eb46502cd in __assert_fail_base (fmt=0x7f2eb47893a0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x55615b22003a "!usb_packet_is_inflight(p)", file=file@entry=0x55615b21fdf0 "hw/usb/core.c", line=line@entry=619, + function=function@entry=0x55615b2202c0 <__PRETTY_FUNCTION__.38612> "usb_packet_cleanup") at assert.c:92 + str = 0x55615cfdf510 "" + total = 4096 +#3 0x00007f2eb4650382 in __GI___assert_fail (assertion=0x55615b22003a "!usb_packet_is_inflight(p)", file=0x55615b21fdf0 "hw/usb/core.c", + line=619, function=0x55615b2202c0 <__PRETTY_FUNCTION__.38612> "usb_packet_cleanup") at assert.c:101 +No locals. +#4 0x000055615afc385e in usb_packet_cleanup () +No symbol table info available. +#5 0x000055615afda555 in xhci_ep_free_xfer () +No symbol table info available. +#6 0x000055615afdc156 in xhci_kick_epctx () +No symbol table info available. +#7 0x000055615afda099 in xhci_ep_kick_timer () +No symbol table info available. +#8 0x000055615b08ceee in timerlist_run_timers () +No symbol table info available. +#9 0x000055615b08cf36 in qemu_clock_run_timers () +No symbol table info available. +#10 0x000055615b08d2df in qemu_clock_run_all_timers () +No symbol table info available. +#11 0x000055615b08be40 in main_loop_wait () +No symbol table info available. +#12 0x000055615ae3870f in main_loop () +No symbol table info available. +#13 0x000055615ae4027b in main () + +This behaviour was introduced by commit: + +94b037f2a451b3dc855f9f2c346e5049a361bd55 +xhci: use linked list for transfers + +However, QEMU does not crash yet, but linux' xhci_hcd reports errors like "ERROR Transfer event TRB DMA...". The following commit + +5612564ea9cf5b9636438a1b58ae9a2ab6ca16ae +xhci: drop XHCITransfer->xhci + +finally makes QEMU crash on the assertion check. + +I tried to dig into the code, but I'm not an expert in usb stuff so I don't understand it. usb_packet_is_inflight checks if USBPacket.state is USB_PACKET_QUEUED or USB_PACKET_ASYNC. I suppose that somewhere in the code changed by 94b037f2 finished usb transfers do not have the packet state changed. + + Hi, + +> qemu-system-x86_64: hw/usb/core.c:623: usb_packet_cleanup: Assertion +> `!usb_packet_is_inflight(p)' failed. + +We are trying to free a in-flight transfer. Hmm. + +> Bisected the issue to following commit: +> first bad commit: [94b037f2a451b3dc855f9f2c346e5049a361bd55] xhci: use linked list for transfers + +Ok. + +> #5 0x000055615afda555 in xhci_ep_free_xfer () +> No symbol table info available. +> #6 0x000055615afdc156 in xhci_kick_epctx () +> No symbol table info available. + +Can you rebuild with debug into and try again? + +There are multiple xhci_ep_free_xfer() callsites in xhci_kick_epctx() +and it would be useful to know which one is it. + +thanks, + Gerd + + +Hi, + +using qemu commit f634151b02ce5c80605383894f1f63f2c12e0033 +configured with --python=/usr/bin/python2 --target-list=x86_64-softmmu --audio-drv-list="oss alsa sdl pa" --enable-debug +running with -m 1024 -drive if=pflash,file=ovmf-arch.bin,format=raw -drive file=arch.raw,format=raw,if=virtio -device nec-usb-xhci,id=xhci -device usb-host,bus=xhci.0,vendorid=0x046d,productid=0x0a4d + +I get: +(gdb) bt full +#0 0x00007fffdccb304f in raise () at /usr/lib/libc.so.6 +#1 0x00007fffdccb447a in abort () at /usr/lib/libc.so.6 +#2 0x00007fffdccabea7 in __assert_fail_base () at /usr/lib/libc.so.6 +#3 0x00007fffdccabf52 in () at /usr/lib/libc.so.6 +#4 0x0000555555a8ab6e in usb_packet_cleanup (p=0x7fff5c125c18) at hw/usb/core.c:619 + __PRETTY_FUNCTION__ = "usb_packet_cleanup" +#5 0x0000555555aa8d97 in xhci_ep_free_xfer (xfer=0x7fff5c125c10) at hw/usb/hcd-xhci.c:1465 +#6 0x0000555555aaa9a8 in xhci_kick_epctx (epctx=0x7fff5c0205d0, streamid=0) at hw/usb/hcd-xhci.c:2201 + xfer = 0x7fff5c125c10 + xhci = 0x7fff76538010 + stctx = 0x7fffffffd960 + xfer = 0x2ffffd920 + ring = 0x5555562aeed0 <timers_state+16> + ep = 0x0 + mfindex = 113160 + length = 1434054766 + i = 32767 + __PRETTY_FUNCTION__ = "xhci_kick_epctx" +#7 0x0000555555aa88d9 in xhci_ep_kick_timer (opaque=0x7fff5c0205d0) at hw/usb/hcd-xhci.c:1363 + epctx = 0x7fff5c0205d0 +#8 0x0000555555b6217f in timerlist_run_timers (timer_list=0x5555567a25a0) at qemu-timer.c:540 + ts = 0x7fff5cb8f210 + current_time = 31951197002 + progress = false + cb = 0x555555aa88b4 <xhci_ep_kick_timer> + opaque = 0x7fff5c0205d0 +#9 0x0000555555b621cb in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at qemu-timer.c:551 +#10 0x0000555555b62564 in qemu_clock_run_all_timers () at qemu-timer.c:665 + progress = false + type = QEMU_CLOCK_VIRTUAL +#11 0x0000555555b610be in main_loop_wait (nonblocking=0) at main-loop.c:516 + ret = 0 + timeout = 1000 + timeout_ns = 289955 +#12 0x00005555558f0b97 in main_loop () at vl.c:1966 + nonblocking = false + last_io = 0 +#13 0x00005555558f847c in main (argc=11, argv=0x7fffffffde18, envp=0x7fffffffde78) at vl.c:4685 + i = 0 + snapshot = 0 + linux_boot = 0 + initrd_filename = 0x0 + kernel_filename = 0x0 + kernel_cmdline = 0x555555c8ecb6 "" + boot_order = 0x555555c7c5b5 "cad" + boot_once = 0x0 + ds = 0x555557777de0 + cyls = 0 + heads = 0 + secs = 0 + translation = 0 + hda_opts = 0x0 + opts = 0x0 + machine_opts = 0x5555567a2480 + icount_opts = 0x0 + olist = 0x0 + optind = 11 + optarg = 0x7fffffffe296 "usb-host,bus=xhci.0,vendorid=0x046d,productid=0x0a4d" + loadvm = 0x0 + machine_class = 0x55555676bef0 + cpu_model = 0x0 + vga_model = 0x555555c7cece "std" + qtest_chrdev = 0x0 + qtest_log = 0x0 + pid_file = 0x0 + incoming = 0x0 + defconfig = true + userconfig = true + nographic = false + display_type = DT_GTK + display_remote = 0 + log_mask = 0x0 + log_file = 0x0 + trace_file = 0x0 + maxram_size = 1073741824 + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + __func__ = "main" + +Hope this helps. + +I examined xhci_kick_epctx (frame 6) and looked into xfer and xfer->packet, maybe this helps: + +(gdb) bt +#0 0x00007fffdccb304f in raise () at /usr/lib/libc.so.6 +#1 0x00007fffdccb447a in abort () at /usr/lib/libc.so.6 +#2 0x00007fffdccabea7 in __assert_fail_base () at /usr/lib/libc.so.6 +#3 0x00007fffdccabf52 in () at /usr/lib/libc.so.6 +#4 0x0000555555a8ab6e in usb_packet_cleanup (p=0x7fff5c3bcd88) at hw/usb/core.c:619 +#5 0x0000555555aa8d97 in xhci_ep_free_xfer (xfer=0x7fff5c3bcd80) at hw/usb/hcd-xhci.c:1465 +#6 0x0000555555aaa9a8 in xhci_kick_epctx (epctx=0x7fff5c745290, streamid=0) at hw/usb/hcd-xhci.c:2201 +#7 0x0000555555aa88d9 in xhci_ep_kick_timer (opaque=0x7fff5c745290) at hw/usb/hcd-xhci.c:1363 +#8 0x0000555555b6217f in timerlist_run_timers (timer_list=0x5555567a25a0) at qemu-timer.c:540 +#9 0x0000555555b621cb in qemu_clock_run_timers (type=QEMU_CLOCK_VIRTUAL) at qemu-timer.c:551 +#10 0x0000555555b62564 in qemu_clock_run_all_timers () at qemu-timer.c:665 +#11 0x0000555555b610be in main_loop_wait (nonblocking=0) at main-loop.c:516 +#12 0x00005555558f0b97 in main_loop () at vl.c:1966 +#13 0x00005555558f847c in main (argc=11, argv=0x7fffffffde18, envp=0x7fffffffde78) at vl.c:4685 +(gdb) f 6 +#6 0x0000555555aaa9a8 in xhci_kick_epctx (epctx=0x7fff5c745290, streamid=0) at hw/usb/hcd-xhci.c:2201 +2201 xhci_ep_free_xfer(epctx->retry); +(gdb) info local +xfer = 0x7fff5c3bcd80 +xhci = 0x7fff76538010 +stctx = 0x7fffffffd960 +xfer = 0x2ffffd920 +ring = 0x5555562aeed0 <timers_state+16> +ep = 0x0 +mfindex = 126425 +length = 1434054766 +i = 32767 +__PRETTY_FUNCTION__ = "xhci_kick_epctx" +(gdb) print xfer +$1 = (XHCITransfer *) 0x7fff5c3bcd80 +(gdb) print *xfer +$2 = {epctx = 0x7fff5c745290, packet = {pid = 105, id = 1028964352, ep = 0x555558342660, stream = 0, iov = {iov = 0x7fff5c138960, niov = 1, nalloc = 1, size = 5}, parameter = 0, short_not_ok = false, int_req = true, status = -6, actual_length = 0, state = USB_PACKET_ASYNC, combined = 0x0, queue = {tqe_next = 0x0, tqe_prev = 0x555558342678}, combined_entry = {tqe_next = 0x0, tqe_prev = 0x0}}, sgl = {sg = 0x5555586401e0, nsg = 1, nalloc = 1, size = 5, dev = 0x7fff76538010, as = 0x7fff76538220}, running_async = true, running_retry = false, complete = false, int_req = true, iso_pkts = 0, streamid = 0, in_xfer = true, iso_xfer = false, timed_xfer = false, trb_count = 1, trbs = 0x7fff5c025690, status = CC_INVALID, pkts = 0, pktsize = 0, cur_pkt = 0, mfindex_kick = 126424, next = {tqe_next = 0x0, tqe_prev = 0x0}} +(gdb) print xfer->packet +$3 = {pid = 105, id = 1028964352, ep = 0x555558342660, stream = 0, iov = {iov = 0x7fff5c138960, niov = 1, nalloc = 1, size = 5}, parameter = 0, short_not_ok = false, int_req = true, status = -6, actual_length = 0, state = USB_PACKET_ASYNC, combined = 0x0, queue = {tqe_next = 0x0, tqe_prev = 0x555558342678}, combined_entry = {tqe_next = 0x0, tqe_prev = 0x0}} + + Hi, + +> #6 0x0000555555aaa9a8 in xhci_kick_epctx (epctx=0x7fff5c0205d0, streamid=0) at hw/usb/hcd-xhci.c:2201 + +Ok, suspected already it will be there. + +thanks, + Gerd + + +On Mi, 2017-01-11 at 16:35 +0000, Fabian Lesniak wrote: +> I examined xhci_kick_epctx (frame 6) and looked into xfer and +> xfer->packet, maybe this helps: + +> (gdb) print *xfer +> $2 = {epctx = 0x7fff5c745290, packet = {pid = 105, id = 1028964352, ep +> = 0x555558342660, stream = 0, iov = {iov = 0x7fff5c138960, niov = 1, +> nalloc = 1, size = 5}, parameter = 0, short_not_ok = false, int_req = +> true, status = -6, actual_length = 0, state = USB_PACKET_ASYNC, + ^^^^^^^^^^^^^^^^^^^^^^^^ +Yep, packed still being processed at that point. + + +Most callsites check already, one was missed. + +Cc: <email address hidden> +Fixes: 94b037f2a451b3dc855f9f2c346e5049a361bd55 +Reported-by: Fabian Lesniak <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/usb/hcd-xhci.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c +index 4acf0c6..e961564 100644 +--- a/hw/usb/hcd-xhci.c ++++ b/hw/usb/hcd-xhci.c +@@ -2198,7 +2198,9 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + xhci_complete_packet(xfer); + } + assert(!xfer->running_retry); +- xhci_ep_free_xfer(epctx->retry); ++ if (xfer->complete) { ++ xhci_ep_free_xfer(epctx->retry); ++ } + epctx->retry = NULL; + } + +-- +1.8.3.1 + + + +This patch fixes passing through a keyboard for me. I tried a Logitech K120 (046d:c31c). + +After that, I tried my real-world use case being a standard USB sound card (046d:0a4d). This does not crash the machine anymore, but linux reports: + +xhci_hcd 0000:00:03.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 + +multiple times when trying to use the sound card. I get no sound and my media player freezes. + +Before commit 94b037f2a451b3dc855f9f2c346e5049a361bd55 this sound card worked without any errors. + +Make clear that this isn't guaranteed to actually complete the transfer, +the usb packet can still be in flight after calling that function. + +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/usb/hcd-xhci.c | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c +index dd429dc..4e2807e 100644 +--- a/hw/usb/hcd-xhci.c ++++ b/hw/usb/hcd-xhci.c +@@ -1897,7 +1897,7 @@ static int xhci_setup_packet(XHCITransfer *xfer) + return 0; + } + +-static int xhci_complete_packet(XHCITransfer *xfer) ++static int xhci_try_complete_packet(XHCITransfer *xfer) + { + if (xfer->packet.status == USB_RET_ASYNC) { + trace_usb_xhci_xfer_async(xfer); +@@ -2002,7 +2002,7 @@ static int xhci_fire_ctl_transfer(XHCIState *xhci, XHCITransfer *xfer) + + usb_handle_packet(xfer->packet.ep->dev, &xfer->packet); + +- xhci_complete_packet(xfer); ++ xhci_try_complete_packet(xfer); + if (!xfer->running_async && !xfer->running_retry) { + xhci_kick_epctx(xfer->epctx, 0); + } +@@ -2106,7 +2106,7 @@ static int xhci_submit(XHCIState *xhci, XHCITransfer *xfer, XHCIEPContext *epctx + } + usb_handle_packet(xfer->packet.ep->dev, &xfer->packet); + +- xhci_complete_packet(xfer); ++ xhci_try_complete_packet(xfer); + if (!xfer->running_async && !xfer->running_retry) { + xhci_kick_epctx(xfer->epctx, xfer->streamid); + } +@@ -2185,7 +2185,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + } + usb_handle_packet(xfer->packet.ep->dev, &xfer->packet); + assert(xfer->packet.status != USB_RET_NAK); +- xhci_complete_packet(xfer); ++ xhci_try_complete_packet(xfer); + } else { + /* retry nak'ed transfer */ + if (xhci_setup_packet(xfer) < 0) { +@@ -2195,7 +2195,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + if (xfer->packet.status == USB_RET_NAK) { + return; + } +- xhci_complete_packet(xfer); ++ xhci_try_complete_packet(xfer); + } + assert(!xfer->running_retry); + if (xfer->complete) { +@@ -3492,7 +3492,7 @@ static void xhci_complete(USBPort *port, USBPacket *packet) + xhci_ep_nuke_one_xfer(xfer, 0); + return; + } +- xhci_complete_packet(xfer); ++ xhci_try_complete_packet(xfer); + xhci_kick_epctx(xfer->epctx, xfer->streamid); + if (xfer->complete) { + xhci_ep_free_xfer(xfer); +-- +1.8.3.1 + + + + Hi, + +Commit 94b037f2a451b3dc855f9f2c346e5049a361bd55 caused some regressions, +partly plain bugs in that commit, partly it seems to have uncovered +other issues lurking in the xhci code. This series fixes the isses +which poped up so far. + +cheers, + Gerd + +Gerd Hoffmann (4): + xhci: only free completed transfers + xhci: rename xhci_complete_packet to xhci_try_complete_packet + xhci: don't kick in xhci_submit and xhci_fire_ctl_transfer + xhci: guard xhci_kick_epctx against recursive calls + + hw/usb/hcd-xhci.c | 32 +++++++++++++++++--------------- + 1 file changed, 17 insertions(+), 15 deletions(-) + +-- +1.8.3.1 + + + +Track xhci_kick_epctx processing being active in a variable. Check the +variable before calling xhci_kick_epctx from xhci_kick_ep. Add an +assert to make sure we don't call recursively into xhci_kick_epctx. + +Cc: <email address hidden> +Fixes: 94b037f2a451b3dc855f9f2c346e5049a361bd55 +Reported-by: Fabian Lesniak <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/usb/hcd-xhci.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c +index 899a410..12cac89 100644 +--- a/hw/usb/hcd-xhci.c ++++ b/hw/usb/hcd-xhci.c +@@ -390,6 +390,7 @@ struct XHCIEPContext { + dma_addr_t pctx; + unsigned int max_psize; + uint32_t state; ++ uint32_t kick_active; + + /* streams */ + unsigned int max_pstreams; +@@ -2131,6 +2132,9 @@ static void xhci_kick_ep(XHCIState *xhci, unsigned int slotid, + return; + } + ++ if (!epctx->kick_active) { ++ return; ++ } + xhci_kick_epctx(epctx, streamid); + } + +@@ -2155,6 +2159,9 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + return; + } + ++ assert(!epctx->kick_active); ++ epctx->kick_active++; ++ + if (epctx->retry) { + XHCITransfer *xfer = epctx->retry; + +@@ -2253,6 +2260,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + break; + } + } ++ epctx->kick_active--; + + ep = xhci_epid_to_usbep(epctx); + if (ep) { +-- +1.8.3.1 + + + +xhci_submit and xhci_fire_ctl_transfer are is called from +xhci_kick_epctx processing loop only, so there is no need to call +xhci_kick_epctx make sure processing continues. Also eecursive calls +into xhci_kick_epctx can cause trouble. + +Drop the xhci_kick_epctx calls. + +Cc: <email address hidden> +Fixes: 94b037f2a451b3dc855f9f2c346e5049a361bd55 +Reported-by: Fabian Lesniak <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/usb/hcd-xhci.c | 8 -------- + 1 file changed, 8 deletions(-) + +diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c +index 4e2807e..899a410 100644 +--- a/hw/usb/hcd-xhci.c ++++ b/hw/usb/hcd-xhci.c +@@ -2001,11 +2001,7 @@ static int xhci_fire_ctl_transfer(XHCIState *xhci, XHCITransfer *xfer) + xfer->packet.parameter = trb_setup->parameter; + + usb_handle_packet(xfer->packet.ep->dev, &xfer->packet); +- + xhci_try_complete_packet(xfer); +- if (!xfer->running_async && !xfer->running_retry) { +- xhci_kick_epctx(xfer->epctx, 0); +- } + return 0; + } + +@@ -2105,11 +2101,7 @@ static int xhci_submit(XHCIState *xhci, XHCITransfer *xfer, XHCIEPContext *epctx + return -1; + } + usb_handle_packet(xfer->packet.ep->dev, &xfer->packet); +- + xhci_try_complete_packet(xfer); +- if (!xfer->running_async && !xfer->running_retry) { +- xhci_kick_epctx(xfer->epctx, xfer->streamid); +- } + return 0; + } + +-- +1.8.3.1 + + + +Most callsites check already, one was missed. + +Cc: <email address hidden> +Fixes: 94b037f2a451b3dc855f9f2c346e5049a361bd55 +Reported-by: Fabian Lesniak <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + hw/usb/hcd-xhci.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c +index e0b5169..dd429dc 100644 +--- a/hw/usb/hcd-xhci.c ++++ b/hw/usb/hcd-xhci.c +@@ -2198,7 +2198,9 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + xhci_complete_packet(xfer); + } + assert(!xfer->running_retry); +- xhci_ep_free_xfer(epctx->retry); ++ if (xfer->complete) { ++ xhci_ep_free_xfer(epctx->retry); ++ } + epctx->retry = NULL; + } + +-- +1.8.3.1 + + + +Track xhci_kick_epctx processing being active in a variable. Check the +variable before calling xhci_kick_epctx from xhci_kick_ep. Add an +assert to make sure we don't call recursively into xhci_kick_epctx. + +Cc: <email address hidden> +Fixes: 94b037f2a451b3dc855f9f2c346e5049a361bd55 +Reported-by: Fabian Lesniak <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +Message-id: <email address hidden> +--- + hw/usb/hcd-xhci.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c +index 899a410..df75907 100644 +--- a/hw/usb/hcd-xhci.c ++++ b/hw/usb/hcd-xhci.c +@@ -390,6 +390,7 @@ struct XHCIEPContext { + dma_addr_t pctx; + unsigned int max_psize; + uint32_t state; ++ uint32_t kick_active; + + /* streams */ + unsigned int max_pstreams; +@@ -2131,6 +2132,9 @@ static void xhci_kick_ep(XHCIState *xhci, unsigned int slotid, + return; + } + ++ if (epctx->kick_active) { ++ return; ++ } + xhci_kick_epctx(epctx, streamid); + } + +@@ -2146,6 +2150,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + int i; + + trace_usb_xhci_ep_kick(epctx->slotid, epctx->epid, streamid); ++ assert(!epctx->kick_active); + + /* If the device has been detached, but the guest has not noticed this + yet the 2 above checks will succeed, but we must NOT continue */ +@@ -2217,6 +2222,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + } + assert(ring->dequeue != 0); + ++ epctx->kick_active++; + while (1) { + length = xhci_ring_chain_length(xhci, ring); + if (length <= 0) { +@@ -2253,6 +2259,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + break; + } + } ++ epctx->kick_active--; + + ep = xhci_epid_to_usbep(epctx); + if (ep) { +-- +1.8.3.1 + + + +These patches solve my problems. All three devices I tested using xhci work correctly now. + +Most callsites check already, one was missed. + +Cc: <email address hidden> +Fixes: 94b037f2a451b3dc855f9f2c346e5049a361bd55 +Reported-by: Fabian Lesniak <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +Message-id: <email address hidden> +--- + hw/usb/hcd-xhci.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c +index f810678..6a1d3dc 100644 +--- a/hw/usb/hcd-xhci.c ++++ b/hw/usb/hcd-xhci.c +@@ -2198,7 +2198,9 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + xhci_complete_packet(xfer); + } + assert(!xfer->running_retry); +- xhci_ep_free_xfer(epctx->retry); ++ if (xfer->complete) { ++ xhci_ep_free_xfer(epctx->retry); ++ } + epctx->retry = NULL; + } + +-- +1.8.3.1 + + + +xhci_submit and xhci_fire_ctl_transfer are is called from +xhci_kick_epctx processing loop only, so there is no need to call +xhci_kick_epctx make sure processing continues. Also eecursive calls +into xhci_kick_epctx can cause trouble. + +Drop the xhci_kick_epctx calls. + +Cc: <email address hidden> +Fixes: 94b037f2a451b3dc855f9f2c346e5049a361bd55 +Reported-by: Fabian Lesniak <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +Message-id: <email address hidden> +--- + hw/usb/hcd-xhci.c | 8 -------- + 1 file changed, 8 deletions(-) + +diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c +index 7e863d3..f89d8da 100644 +--- a/hw/usb/hcd-xhci.c ++++ b/hw/usb/hcd-xhci.c +@@ -2001,11 +2001,7 @@ static int xhci_fire_ctl_transfer(XHCIState *xhci, XHCITransfer *xfer) + xfer->packet.parameter = trb_setup->parameter; + + usb_handle_packet(xfer->packet.ep->dev, &xfer->packet); +- + xhci_try_complete_packet(xfer); +- if (!xfer->running_async && !xfer->running_retry) { +- xhci_kick_epctx(xfer->epctx, 0); +- } + return 0; + } + +@@ -2105,11 +2101,7 @@ static int xhci_submit(XHCIState *xhci, XHCITransfer *xfer, XHCIEPContext *epctx + return -1; + } + usb_handle_packet(xfer->packet.ep->dev, &xfer->packet); +- + xhci_try_complete_packet(xfer); +- if (!xfer->running_async && !xfer->running_retry) { +- xhci_kick_epctx(xfer->epctx, xfer->streamid); +- } + return 0; + } + +-- +1.8.3.1 + + + +Track xhci_kick_epctx processing being active in a variable. Check the +variable before calling xhci_kick_epctx from xhci_kick_ep. Add an +assert to make sure we don't call recursively into xhci_kick_epctx. + +Cc: <email address hidden> +Fixes: 94b037f2a451b3dc855f9f2c346e5049a361bd55 +Reported-by: Fabian Lesniak <email address hidden> +Signed-off-by: Gerd Hoffmann <email address hidden> +Message-id: <email address hidden> +Message-id: <email address hidden> +--- + hw/usb/hcd-xhci.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c +index f89d8da..1878dad 100644 +--- a/hw/usb/hcd-xhci.c ++++ b/hw/usb/hcd-xhci.c +@@ -390,6 +390,7 @@ struct XHCIEPContext { + dma_addr_t pctx; + unsigned int max_psize; + uint32_t state; ++ uint32_t kick_active; + + /* streams */ + unsigned int max_pstreams; +@@ -2131,6 +2132,9 @@ static void xhci_kick_ep(XHCIState *xhci, unsigned int slotid, + return; + } + ++ if (epctx->kick_active) { ++ return; ++ } + xhci_kick_epctx(epctx, streamid); + } + +@@ -2146,6 +2150,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + int i; + + trace_usb_xhci_ep_kick(epctx->slotid, epctx->epid, streamid); ++ assert(!epctx->kick_active); + + /* If the device has been detached, but the guest has not noticed this + yet the 2 above checks will succeed, but we must NOT continue */ +@@ -2217,6 +2222,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + } + assert(ring->dequeue != 0); + ++ epctx->kick_active++; + while (1) { + length = xhci_ring_chain_length(xhci, ring); + if (length <= 0) { +@@ -2253,6 +2259,7 @@ static void xhci_kick_epctx(XHCIEPContext *epctx, unsigned int streamid) + break; + } + } ++ epctx->kick_active--; + + ep = xhci_epid_to_usbep(epctx); + if (ep) { +-- +1.8.3.1 + + + diff --git a/results/classifier/108/other/1654 b/results/classifier/108/other/1654 new file mode 100644 index 000000000..9420c0766 --- /dev/null +++ b/results/classifier/108/other/1654 @@ -0,0 +1,96 @@ +vnc: 0.832 +other: 0.814 +KVM: 0.803 +graphic: 0.785 +device: 0.784 +socket: 0.761 +performance: 0.740 +debug: 0.713 +permissions: 0.706 +semantic: 0.703 +PID: 0.677 +files: 0.663 +network: 0.608 +boot: 0.600 + +Memory out of bounds access vulnerability when guest accesses Block Limits information of SCSI devices +Description of problem: +When a guest uses a Linux kernel version 5.19 or higher and uses an scsi device, there will be a memory access violation, which can be clearly seen when ASAN is turned on. + +**reason：** +Linux kernel 5.19 merge commit： + +https://github.com/torvalds/linux/commit/c92a6b5d63359dd6d2ce6ea88ecd8e31dd769f6b + +The Linux kernel will first issue a header request to obtain the VPD length before obtaining the VPD information. The BUF for obtaining the VPD length is less than 8 bytes. However, QEMU regards the header for obtaining the VPD length as obtaining all VPD information, and a memory access violation occurs when writing information to BUF. + +The specific memory out of bounds information is as follows: +==12430==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! + +==12430==WARNING: ASan is ignoring requested __asan_handle_no_return: stack top: +0x7fffebc1d000; bottom 0x7f61115ee000; size: 0x009eda62f000 (682268749824) + +False positive error reports may follow + +==12430==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200024d858 at pc 0x55767513791c bp 0x7f6111fcddc0 sp 0x7f6111fcddb0 + +WRITE of size 4 at 0x60200024d858 thread T0 + + #0 0x55767513791b in stl_he_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 + + #1 0x55767513791b in stl_be_p /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:464 + + #2 0x55767513791b in scsi_handle_inquiry_reply hw/scsi/scsi-generic.c:173 + + #3 0x55767513791b in scsi_read_complete hw/scsi/scsi-generic.c:318 + + #4 0x55767545d7c6 in blk_aio_complete block/block-backend.c:1425 + + #5 0x557675544d79 in coroutine_trampoline util/coroutine-ucontext.c:115 + + #6 0x7f611b9f14df (/lib/x86_64-linux-gnu/libc.so.6+0x5b4df) + +0x60200024d858 is located 4 bytes to the right of 4-byte region [0x60200024d850,0x60200024d854) + +allocated by thread T0 here: + + #0 0x557674a987f2 in malloc (/sf/bin/qemu-system-x86_64+0x7827f2) + + #1 0x7f6120141d41 in g_malloc (/usr/lib/libglib256-2.0.so.0+0x61d41) + + #2 0x557675137bb4 in scsi_send_command hw/scsi/scsi-generic.c:459 + + #3 0x55767513e902 in scsi_req_enqueue hw/scsi/scsi-bus.c:836 + + #4 0x557674c5f26e in virtio_scsi_handle_cmd_req_submit /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:589 + + #5 0x557674c5f26e in virtio_scsi_handle_cmd_vq /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi.c:634 + + #6 0x557674c61089 in virtio_scsi_data_plane_handle_cmd /root/hci/qemu/qemu-5.0.0/hw/scsi/virtio-scsi-dataplane.c:60 + + #7 0x557674c9a520 in virtio_queue_notify_aio_vq /root/hci/qemu/qemu-5.0.0/hw/virtio/virtio.c:2338 + + #8 0x55767552c7c4 in aio_dispatch_handler util/aio-posix.c:328 + +SUMMARY: AddressSanitizer: heap-buffer-overflow /root/hci/qemu/qemu-5.0.0/include/qemu/bswap.h:357 stl_he_p +Steps to reproduce: +1. QEMU Enable ASAN +2. Use a guest with a Linux kernel version greater than 5.19 and mount an scsi physical device +3. Upon startup, memory out of bounds access can be detected +Additional information: +At present, I have made some simple modifications, but I am not sure if this is the best solution and can serve as a reference. + +Make a judgment on buflen, ignore the header information issued by the Linux kernel, and write the VPD information when issuing the actual instruction to obtain VPD information. + +hw/scsi/scsi-generic.c:scsi_handle_inquiry_reply + +``` +if (r->buflen >= 12) { + stl_be_p(&r->buf[8], max_transfer); +} +if (r->buflen >= 16){ + /* Also take care of the opt xfer len. */ + stl_be_p(&r->buf[12], + MIN_NON_ZERO(max_transfer, ldl_be_p(&r->buf[12]))); +} +``` diff --git a/results/classifier/108/other/1654271 b/results/classifier/108/other/1654271 new file mode 100644 index 000000000..77000fd94 --- /dev/null +++ b/results/classifier/108/other/1654271 @@ -0,0 +1,233 @@ +other: 0.927 +KVM: 0.925 +permissions: 0.898 +performance: 0.882 +debug: 0.879 +vnc: 0.879 +boot: 0.866 +device: 0.859 +PID: 0.848 +socket: 0.831 +graphic: 0.815 +network: 0.786 +semantic: 0.785 +files: 0.720 + +host machine freezes + +When trying to install Radeon crimson relive 16.12.1, each host machine freezes at the machine environment check stage. +Even if you launch the installer in an environment where GPU is not installed, each host machine freezes in the same way. +When Gusest's CPU is changed from 4 to 1, the environment check is completed normally. +Even if FMA and AVX 2 are invalidated by CPU setting, environment check will be completed normally. +Since 1 CPU does not freeze, I thought that it would be better to fix the CPU, but I will still freeze. +Is it impossible to enable the function of AVX 2 (FMA?) In the virtual machine on KVM? + +HOST + Motherboard ： Asrock Z97 extream6 + CPU : Core i7-4790 + Memory : 24GB + OS : Ubuntu 16.04(kernel 4.7.2-040702) + qemu : 2.5+dfsg-5ubuntu10.6 + libvirt : 1.3.1-1ubuntu10.5 + ovmf : 0~20160408.ffea0a2c-2 + +Guest + BIOS : UEFI + OS : Windows10 Pro Build 14986 + Memory : 8GB + GPU : Radeon HD7770 + +----------------------------------------------------------- +<domain type='kvm'> + <name>WinPC01</name> + <uuid>4f784d78-4d5e-416a-bb43-82ecd2cad409</uuid> + <memory unit='KiB'>8388608</memory> + <currentMemory unit='KiB'>8388608</currentMemory> + <vcpu placement='static'>4</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/WinPC01_VARS.fd</nvram> + <bootmenu enable='yes'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + <hap/> + <hyperv> + <relaxed state='on'/> + <vapic state='on'/> + <spinlocks state='on' retries='8191'/> + </hyperv> + <kvm> + <hidden state='on'/> + </kvm> + </features> + <cpu mode='custom' match='exact'> + <model fallback='allow'>Haswell</model> + <vendor>Intel</vendor> + <topology sockets='1' cores='4' threads='1'/> + </cpu> + <clock offset='localtime'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + <timer name='hypervclock' present='yes'/> + </clock> + <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>/usr/bin/kvm-spice</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> + <source dev='/dev/mapper/vg_yoshi--kvm01_ssd-lv_WinPC01'/> + <target dev='sda' bus='scsi'/> + <boot order='1'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='native'/> + <source dev='/dev/mapper/vg_yoshi--kvm01_hdd-lv_WinPC01_Data'/> + <target dev='sdb' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <target dev='hdb' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </controller> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0f' function='0x0'/> + </controller> + <interface type='bridge'> + <mac address='52:54:00:0e:ca:c5'/> + <source bridge='br0'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <interface type='bridge'> + <mac address='52:54:00:7e:4e:dd'/> + <source bridge='br1'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </interface> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <input type='tablet' bus='usb'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice' port='5900' autoport='no' listen='0.0.0.0' keymap='ja'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> + <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='0x0'/> + </source> + <rom bar='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <source> + <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> + </source> + <rom bar='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <source> + <address domain='0x0000' bus='0x00' slot='0x14' function='0x0'/> + </source> + <rom bar='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> + </hostdev> + <hostdev mode='subsystem' type='pci' managed='yes'> + <source> + <address domain='0x0000' bus='0x00' slot='0x1d' function='0x0'/> + </source> + <rom bar='off'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> + </hostdev> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> + </memballoon> + </devices> +</domain> +----------------------------------------------------------- + +If you put the following designation in the CPU tag, it will not freeze. +----------------------------------------------------------- + <feature policy='disable' name='fma'/> + <feature policy='disable' name='avx2'/> +----------------------------------------------------------- + +Moving this to the Ubuntu-qemu bug tracker since you're apparently using Ubuntu's QEMU, not the upstream QEMU. + +So as far as I understand, when you take avx2/fma away from the guest things work, but if you keep them enabled (via cpu model) it fails? + +Generally those features should be supported, to most of it they are just processor features and passed through. + +By Default I think avx2 is passed but fma is not - maybe that was you case. +I checked with <cpu mode='host-passthrough'/> to get all I can and then check like /proc/cpuinfo which confirms I have them all. + +Since this is not emulation I'd hope that KVM itself isn't really involved in doing a lot after setting up initially. + +Is Radeon crimson relive even supported in a virtual guest? +If it freezes what is the qemu status? +Maybe check more of the status via https://en.wikibooks.org/wiki/QEMU/Monitor + +If you would find an equivalent test in a linux guest that I could retry that would very useful. + +The difference between host-passthrough and host-model (Haswell) was confirmed by Linux CPUinfo, but there was a difference. +Cpu family and model are the same, stepping is 3-> 1, flag is arch_perfmon, tsc_adjust is not host-model. + +AV2 and FMA are also valid in the CPU model of host-passthrough and host-model (Haswell). + + +Since the OS of the host machine hangs up, you can not check the status with the QEMU monitor. + +Hi, that stepping shouldn't be important but thanks for checking. + +I tried to find a few avx/fma test programs, but I only found super small ones and none triggered anything like your freeze. + +Since you have currently the only setup to trigger this, if you can you could try the far newer qemu/libvirt that is in Ubuntu Zesty (current release in development), but that is grasping for straws. What we really need is something we can reproduce this on :-/ + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1655 b/results/classifier/108/other/1655 new file mode 100644 index 000000000..c210853dc --- /dev/null +++ b/results/classifier/108/other/1655 @@ -0,0 +1,16 @@ +device: 0.851 +network: 0.727 +vnc: 0.678 +performance: 0.650 +socket: 0.581 +files: 0.556 +graphic: 0.514 +semantic: 0.440 +permissions: 0.435 +debug: 0.379 +PID: 0.371 +boot: 0.316 +other: 0.148 +KVM: 0.124 + +qemu-7.2.2 build failed diff --git a/results/classifier/108/other/1655700 b/results/classifier/108/other/1655700 new file mode 100644 index 000000000..54f64f818 --- /dev/null +++ b/results/classifier/108/other/1655700 @@ -0,0 +1,46 @@ +other: 0.749 +graphic: 0.726 +device: 0.571 +performance: 0.569 +vnc: 0.537 +PID: 0.416 +socket: 0.411 +files: 0.403 +network: 0.378 +semantic: 0.311 +KVM: 0.286 +permissions: 0.208 +boot: 0.188 +debug: 0.174 + +disas/libvixl/vixl/invalset.h: possible dodgy code in binary search ? + + +[qemu/disas/libvixl/vixl/invalset.h:442]: (style) Array index 'low' is used before limits check. + +Source code is + + while (!IsValid(elements[low]) && (low < high)) ++low; + +Also: + +qemu/disas/libvixl/vixl/invalset.h:450]: (style) Array index 'middle' is used before limits check. + +The source code is + + while (!IsValid(elements[high]) && (low < high)) --high; + +Mind you, these lines of code look similar but didn't get reported: + + while (!IsValid(elements[middle]) && (middle < high - 1)) ++middle; + while (!IsValid(elements[middle]) && (low + 1 < middle)) --middle; + +Given that binary search is notoriously tricky to get correct and a standard C library routine +I am puzzled as to why the standard library routine didn't get used, with of course a custom +comparison function. + +That doesn't look like a bounds check to me, so I think your checker is producing false positives. + +libvixl is third-party code in any case, so stylistic questions are better directed to them upstream. But I think the difference between this code and a standard binary search is (as the comment says) that it ignores invalid elements in the array. + + diff --git a/results/classifier/108/other/1655708 b/results/classifier/108/other/1655708 new file mode 100644 index 000000000..882762c03 --- /dev/null +++ b/results/classifier/108/other/1655708 @@ -0,0 +1,82 @@ +other: 0.855 +device: 0.812 +semantic: 0.811 +socket: 0.783 +PID: 0.745 +vnc: 0.741 +graphic: 0.661 +performance: 0.660 +boot: 0.654 +network: 0.587 +permissions: 0.583 +files: 0.555 +KVM: 0.520 +debug: 0.473 + +target/ppc/int_helper.c:2806: strange expression ? + +target/ppc/int_helper.c:2806:25: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] + +Source code is + + zone_digit = (i * 2) ? b->u8[BCD_DIG_BYTE(i * 2)] >> 4 : zone_lead; + +Which I read as + + zone_digit = (i * 2) ? (b->u8[BCD_DIG_BYTE(i * 2)] >> 4) : zone_lead; + +so I think the compiler warning is for the i * 2 lhs of the ?. + +I am not sure what to suggest as a bugfix. + +On 01/11/2017 10:41 AM, dcb wrote: +> Public bug reported: +> +> target/ppc/int_helper.c:2806:25: warning: ‘*’ in boolean context, +> suggest ‘&&’ instead [-Wint-in-bool-context] +> +> Source code is +> +> zone_digit = (i * 2) ? b->u8[BCD_DIG_BYTE(i * 2)] >> 4 : +> zone_lead; + +Also, looking at BCD_DIG_BYTE(): + +#if defined(HOST_WORDS_BIGENDIAN) +#define BCD_DIG_BYTE(n) (15 - (n/2)) +#else +#define BCD_DIG_BYTE(n) (n/2) +#endif + +Oops. n is under-parenthesized, and will cause invalid expansions for +some expressions. Let's fix that as well. + + +> so I think the compiler warning is for the i * 2 lhs of the ?. + +Yes - the compiler is complaining that 'i * 2' can only be non-zero if +'i' was non-zero (given that the code occurs in a loop for i between 0 +and 16), so it is just as easy to write 'i ? ...' instead of the weirder +'(i * 2) ? ...'. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +> so it is just as easy to write 'i ? ...' instead of the weirder +> '(i * 2) ? ...'. + +I suspect it is just possible that the i * 2 expression is a typo +for something else, perhaps i & 2 or i << 2 or i >> 2 or something else. + +I don't know the code so I am unable to offer better guidance. + + +Patch has been posted to the mailing list: +https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg02008.html + +Fix had been committed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=365206aeb3d0bb72043d + diff --git a/results/classifier/108/other/1655764 b/results/classifier/108/other/1655764 new file mode 100644 index 000000000..009e151d7 --- /dev/null +++ b/results/classifier/108/other/1655764 @@ -0,0 +1,43 @@ +other: 0.877 +graphic: 0.825 +device: 0.814 +semantic: 0.800 +performance: 0.766 +files: 0.705 +socket: 0.692 +vnc: 0.691 +permissions: 0.680 +boot: 0.662 +network: 0.656 +PID: 0.615 +debug: 0.474 +KVM: 0.417 + +qemu-img convert -c compression can't decompress + +Used -c compression option of qemu-img convert to compress qcow2, +then libvirt mount for compressed image don't work as well as decompression also +not working, tried glib-deflate to decompress + +Used openssl zlib -d < compressedfile but that also not working + +When tried zlib-flate -uncompress < cirros-0.3.4-x86_64-disk.img, +getting below error + +data: incorrect header check + +Which version of QEMU (or rather qemu-img) are you using? + +qemu-img version 2.1.2, Copyright (c) 2004-2008 Fabrice Bellard + +When reporting bugs, please always use the latest version of QEMU, old versions like 2.1 are not supported anymore. I just also noticed that Stefan Hajnoczi replied to the bug mail on the qemu-devel mailing list (see https://<email address hidden>/msg422186.html) - seems like the bridge did not mirror this to the bug tracker: + +"QEMU image compression uses the compression feature available in some + disk image formats (like qcow2). This is not the same as compressing a + file with gzip, bzip2, or similar tools. + Therefore this error is expected and not a bug." + +Yes used qcow2 format only when compressing, I don't think due to older version problem + +When converting qcow2 with -c option, then after not able to boot VM with compressed qcow2 image + diff --git a/results/classifier/108/other/1656 b/results/classifier/108/other/1656 new file mode 100644 index 000000000..2c200ea1a --- /dev/null +++ b/results/classifier/108/other/1656 @@ -0,0 +1,22 @@ +network: 0.783 +device: 0.762 +graphic: 0.596 +socket: 0.533 +files: 0.497 +performance: 0.497 +vnc: 0.488 +permissions: 0.464 +debug: 0.420 +KVM: 0.395 +PID: 0.344 +boot: 0.338 +other: 0.243 +semantic: 0.225 + +https://wiki.qemu.org/: TLS certificate has expired (`May 14 21:15:57 2023 GMT`) +Description of problem: +The ceritficate for https://wiki.qemu.org/ has expired on May 14 21:15:57 2023 GMT. +Steps to reproduce: +1. Browse https://wiki.qemu.org/ +Additional information: + diff --git a/results/classifier/108/other/1656676 b/results/classifier/108/other/1656676 new file mode 100644 index 000000000..daffad82b --- /dev/null +++ b/results/classifier/108/other/1656676 @@ -0,0 +1,40 @@ +graphic: 0.804 +vnc: 0.758 +device: 0.691 +semantic: 0.676 +performance: 0.644 +PID: 0.574 +other: 0.565 +debug: 0.490 +network: 0.466 +permissions: 0.322 +socket: 0.312 +files: 0.304 +boot: 0.159 +KVM: 0.136 + +nvram/fw_cfg.c ‘read’ may be used uninitialized + +Commit Number: b6af8ea60282df514f87d32e36afd1c9aeee28c8 + +The gcc version version 6.3.1 catches a new uninitialized variable in the master branch of QEMU on the Github. After looking through the function, it is really not properly assigned to a value in a certain path (the else condition of assigning read value in the code). +Here is the snippet of the condition assigning value: + if (dma.control & FW_CFG_DMA_CTL_READ) { + read = 1; + } else if (dma.control & FW_CFG_DMA_CTL_SKIP) { + read = 0; + } else { + dma.length = 0; + } + +Error (Warning) message is as following: +hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_transfer’: +hw/nvram/fw_cfg.c:372:16: error: ‘read’ may be used uninitialized in this function [-Werror=maybe-uninitialized] + +Solution: +You can fix this by either assign a proper initial value when defining it, or give a proper value in the else condition. +Sorry that I don't have a patch for this. I'm not sure whether to assign 1 or 0 in the else condition. + +This has been fixed here already: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=baf2d5bfbac#patch6 + diff --git a/results/classifier/108/other/1656710 b/results/classifier/108/other/1656710 new file mode 100644 index 000000000..9933b2398 --- /dev/null +++ b/results/classifier/108/other/1656710 @@ -0,0 +1,29 @@ +device: 0.875 +graphic: 0.870 +semantic: 0.868 +performance: 0.839 +network: 0.776 +permissions: 0.742 +files: 0.726 +other: 0.685 +vnc: 0.658 +boot: 0.550 +socket: 0.510 +debug: 0.497 +PID: 0.476 +KVM: 0.202 + +Please support Ctrl-Alt-= to zoom in + +With the GTK3 interface, qemu-system supports pressing Ctrl-Alt-plus +to zoom in and Ctrl-Alt-minus to zoom out. However, unlike many +programs that support similar zoom hotkeys, qemu-system actually +requires using '+', making the hotkey Ctrl-Alt-Shift-= . Most programs +with similar zoom hotkeys allow Ctrl-Alt-= as a synonym. + +Please consider accepting Ctrl-Alt-= as an additional zoom-in hotkey. + +(Observed in QEMU 2.8) + +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=66f6b82bf26cc15e33 + diff --git a/results/classifier/108/other/1656711 b/results/classifier/108/other/1656711 new file mode 100644 index 000000000..0142931da --- /dev/null +++ b/results/classifier/108/other/1656711 @@ -0,0 +1,38 @@ +graphic: 0.775 +device: 0.720 +other: 0.584 +performance: 0.543 +vnc: 0.461 +socket: 0.448 +semantic: 0.435 +PID: 0.434 +KVM: 0.433 +network: 0.396 +permissions: 0.393 +boot: 0.376 +debug: 0.335 +files: 0.293 + +GTK3 interface doesn't zoom-to-fit by default + +The SDL interface automatically scales the video output to +match the window size. The GTK3 interface has an off-by-default option +"Zoom To Fit" for that. As far as I can tell, no command-line option +exists to turn that option on. That makes it harder to quickly zoom a +freshly launched VM; instead of just hitting a maximize-window hotkey, I +also have to navigate through the menu to select "Zoom To Fit". + +Given that VMs typically start out running in a much lower-resolution +video mode than the host (and VMs not running a full graphical +environment often stay that way), this seriously impacts the usability +of qemu-system. + +(Observed in QEMU 2.8) + +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/108/other/1657 b/results/classifier/108/other/1657 new file mode 100644 index 000000000..3fd0fef9f --- /dev/null +++ b/results/classifier/108/other/1657 @@ -0,0 +1,48 @@ +graphic: 0.744 +device: 0.664 +performance: 0.389 +socket: 0.375 +semantic: 0.338 +debug: 0.327 +files: 0.319 +boot: 0.318 +network: 0.268 +PID: 0.246 +permissions: 0.222 +vnc: 0.220 +other: 0.153 +KVM: 0.091 + +Unable to use ide hard drive when using xlnx-zcu102 board +Description of problem: +I have only recently started using qemu and am reading content related to ahci. When I started QEMU using the above command line (I did not specify the Linux kernel because I only wanted to see which devices were initialized on the motherboard), I found the following devices in the device tree: + ``` +dev: sysbus-ahci, id "" + +gpio-out "sysbus-irq" 1 + +num-ports = 2 (0x2) + +mmio 00000000fd0c0000/0000000000001000 + +bus: ide.1 + +type IDE + +bus: ide.0 + +type IDE + ``` + +I think this is similar to the ICH9 ahci device, so I tried to mount an IDE hard drive（using command line：-drive file=./testide.img）but failed. QEMU shows + ``` +qemu-system-aarch64: -drive file=./ testide.img: machine type does not support if=ide,bus=0,unit=0 + ``` +So if the ide bus generated by sysbus ahci cannot mount a hard drive, what device should it mount? +It will be grateful if anyone can answer this question. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/108/other/1657010 b/results/classifier/108/other/1657010 new file mode 100644 index 000000000..28bda6628 --- /dev/null +++ b/results/classifier/108/other/1657010 @@ -0,0 +1,36 @@ +device: 0.827 +graphic: 0.789 +other: 0.746 +performance: 0.697 +network: 0.588 +permissions: 0.575 +semantic: 0.566 +boot: 0.540 +vnc: 0.527 +socket: 0.461 +files: 0.429 +PID: 0.391 +debug: 0.336 +KVM: 0.196 + +RFE: Please implement -cpu best or a CPU fallback option + +QEMU should implement a -cpu best option or some other way to make this work: + +qemu -M pc,accel=kvm:tcg -cpu best + +qemu -M pc,accel=kvm:tcg -cpu host:qemu64 + +See also: + +https://bugzilla.redhat.com/show_bug.cgi?id=1277744#c6 + +Instead of having a new CPU model called "best", we can simply make "-cpu host" available on TCG. I have submitted a patch for this yesterday: + +https://<email address hidden>/msg422959.html + +I think we've ended up with '-cpu max', present since QEMU 2.9 for x86 and perhaps for some other architectures, but not Arm yet. + + +As far as I can see, we have "-cpu max" now for x86, arm, ppc and s390x ... is that enough, so that we can close this bug now? + diff --git a/results/classifier/108/other/1657538 b/results/classifier/108/other/1657538 new file mode 100644 index 000000000..4dfc89eed --- /dev/null +++ b/results/classifier/108/other/1657538 @@ -0,0 +1,216 @@ +other: 0.716 +debug: 0.708 +graphic: 0.706 +permissions: 0.693 +vnc: 0.688 +device: 0.683 +KVM: 0.664 +network: 0.662 +PID: 0.651 +semantic: 0.633 +performance: 0.623 +socket: 0.621 +files: 0.617 +boot: 0.611 + +qemu 2.7.x 2.8 softmmu dont work on BE machine + +Build on Be machine qemu 2.7.1 and 2.8 in pure softmmu (tgc) dont work on big endian hardware . +tested with ppc-softmmu,i386-softmmu,arm-softmmu same result: + +with : + ./qemu-system-i386 +Gtk-Message: Failed to load module "overlay-scrollbar" +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + + +I try to add the -L option with ../pc-bios/bios.bin +and have the same result. + +note the ppc-softmmu and ppc64-softmmu work in kvm mode only emulated mode have issue. + + +tested on my hardware a Qriq P5040 and G5 4x970MP with Ubuntu Mate 16.10 +thanks +Luigi + +I can not reproduce this issue. QEMU 2.8 works fine here on a POWER8 big endian host (running RHEL7). Can you still run older versions of QEMU that used to work for you in the past, to check whether it is QEMU or whether it is Ubuntu 16.10 that is causing the trouble here? Could you please also post the full output of the "configure" run on your system? + +Something else to try: Could you please check whether you get any output when you run "qemu-system-ppc -nographic" on your system? So we can make sure that it is not related to GTK or something similar... + +Hi Thomas, +here the configure .. i made a clean one just with the target for have fastest build +will report soon the result with the nographic just the time of build + +src/qemu$ ./configure --target-list=i386-softmmu,ppc-softmmu,ppc64-softmmu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +module directory /usr/local/lib/qemu +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/amigaone/src/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler clang +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -DHAS_LIBSSH2_SFTP_FSYNC -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnu/glib-2.0/include -D_GNU_SOURCE -I/usr/include/ncursesw -m32 -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 -fwrapv -Wendif-labels -Wno-shift-negative-value -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/local/include/libpng12 -I/usr/local/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/libusb-1.0 +LDFLAGS -Wl,--warn-common -m32 -g +make make +install install +python python -B +smbd /usr/sbin/smbd +module support no +host CPU ppc +host big endian yes +target list i386-softmmu ppc-softmmu ppc64-softmmu +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +pixman system +SDL support yes (1.2.15) +GTK support yes (2.24.30) +GTK GL support no +VTE support no +TLS priority NORMAL +GNUTLS support no +GNUTLS rnd no +libgcrypt yes +libgcrypt kdf yes +nettle no +nettle kdf no +libtasn1 no +curses support yes +virgl support yes +curl support yes +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support yes +VNC support yes +VNC SASL support yes +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support yes +bluez support yes +Documentation yes +PIE no +vde support no +netmap support no +Linux AIO support yes +ATTR/XATTR support yes +Install blobs yes +KVM support yes +COLO support yes +RDMA support yes +TCG interpreter no +fdt support yes +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +libcap-ng support yes +vhost-net support yes +vhost-scsi support yes +vhost-vsock support yes +Trace backends log +spice support no +rbd support yes +xfsctl support yes +smartcard support yes +libusb yes +usb net redir yes +OpenGL support yes +OpenGL dmabufs yes +libiscsi support yes +libnfs support yes +build guest agent yes +QGA VSS support no +QGA w32 disk info no +QGA MSI support no +seccomp support yes +coroutine backend ucontext +coroutine pool yes +debug stack usage no +GlusterFS support no +Archipelago support no +gcov gcov +gcov enabled no +TPM support yes +libssh2 support yes +TPM passthrough no +QOM debugging yes +lzo support yes +snappy support yes +bzip2 support yes +NUMA host support yes +tcmalloc support no +jemalloc support no +avx2 optimization no +replication support yes + + + +i386-softmmu: +./qemu-system-i386 -nographic +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: and so and so + +./qemu-system-ppc -nographic +nothing happen ... no exit on console . + + +on 2.6.2 i have: + +qemu-system-ppc -nographic + +>> ============================================================= +>> OpenBIOS 1.1 [Apr 18 2016 08:20] +>> Configuration device id QEMU version 1 machine id 2 +>> CPUs: 1 +>> Memory: 128M +>> UUID: 00000000-0000-0000-0000-000000000000 +>> CPU type PowerPC,750 +milliseconds isn't unique. +Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:20 +Trying hd:,\\:tbxi... +Trying hd:,\ppc\bootinfo.txt... +Trying hd:,%BOOT... + + +note the 2.6.2 work, before on 2.6.1 i had the same issue of 2.7 and 2.8 + +I can reproduce the same problem on 2.7.0 on a PowerPC G5 for the x86, x86_64 and ppc softmmu targets (minus the Gtk problem, since I use this ported to Cocoa). As with Luigi this seems to be a regression from 2.6.2. There is no change with -nographic. + +See also: https://bugzilla.redhat.com/show_bug.cgi?id=1332449 + +The commenter indicates several BE issues were detected. I have not yet heard from him regarding his patches or whether they were upstreamed here. + +Oh my gosh the great Cameron Kaiser :) + +Looking through old bug tickets ... can you still reproduce the issue with the latest version of QEMU (v4.2) and a more recent Linux distribution? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1657841 b/results/classifier/108/other/1657841 new file mode 100644 index 000000000..f965f2055 --- /dev/null +++ b/results/classifier/108/other/1657841 @@ -0,0 +1,31 @@ +device: 0.699 +graphic: 0.685 +performance: 0.645 +boot: 0.605 +semantic: 0.508 +PID: 0.292 +vnc: 0.260 +other: 0.237 +socket: 0.202 +debug: 0.174 +files: 0.171 +network: 0.159 +permissions: 0.155 +KVM: 0.001 + +QEMU Intel HAX Windows + +Hi, + +Using the latest exe's from http://qemu.weilnetz.de/w32/ + +C:\Users\therock247uk\Desktop\jan\qemu-w64-setup-20170113>qemu-system-i386 --enable-hax -m 512 -cdrom C:\Users\therock247uk\Desktop\jan\en_windows_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso +HAX is working and emulator runs in fast virt mode. +Failed to allocate 20000000 memory + +The emulator seems to hang/get stuck during booting from the CD taking out --enable-hax allows it to boot. + +Which version were you exactly using? Can you still reproduce the problem 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/1658 b/results/classifier/108/other/1658 new file mode 100644 index 000000000..bdd28fb95 --- /dev/null +++ b/results/classifier/108/other/1658 @@ -0,0 +1,75 @@ +permissions: 0.753 +graphic: 0.736 +files: 0.732 +other: 0.731 +device: 0.728 +performance: 0.711 +network: 0.709 +vnc: 0.709 +semantic: 0.705 +debug: 0.685 +boot: 0.678 +PID: 0.657 +socket: 0.640 +KVM: 0.542 + +Zephyr TF-M IPC example triggers failed assertion !arm_feature(env, ARM_FEATURE_M) on recent Qemu +Description of problem: +I can't run the TrustedFirmware-M IPC example in the Zephyr repo with recent Qemu (in particular v8.0.0). + +By bisecting, I got the last commit OK : v7.2.0-351-gfaa1451e7b + +``` +$ qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio +[INF] Beginning TF-M provisioning +[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE +[Sec Thread] Secure image initializing! +Booting TF-M 8209cb2ed +Creating an empty ITS flash layout. +Creating an empty PS flash layout. +[INF][Crypto] Provisioning entropy seed... complete. +*** Booting Zephyr OS build zephyr-v3.3.0-4041-g7ba5ecf451ef *** +TF-M IPC on mps2_an521_ns +The version of the PSA Framework API is 257. +The PSA Crypto service minor version is 1. +Generating 256 bytes of random data: +71 03 DD 50 8E E5 00 C7 E0 61 7B EB 77 15 E9 38 +E9 A8 7D 0C 51 23 76 9F C3 61 E9 8B 8A 67 BD 14 +73 A3 2C 6E E5 8C E3 19 53 6B 50 55 A8 A7 F4 7B +56 03 60 AA 48 B6 DF 04 33 56 BE 84 43 FA 4E AC +D7 6E 2E 2E 1D 7E 46 69 D5 9B B0 42 5C 54 E4 09 +73 9E 4F 55 F8 3E 05 9E A3 DE 46 D3 E4 02 B0 9C +F3 21 9F 20 85 74 34 07 19 79 07 B8 02 B5 0E 90 +74 21 BE B5 09 4C D7 20 D8 43 F7 72 23 1C F0 3E +77 7B D3 70 29 72 69 D3 7F 1F 61 16 12 73 D5 89 +C5 8B D1 A3 7B 4B FD F5 11 C2 B1 9A C0 A5 F9 7B +16 3D 98 17 66 FE E9 F4 FE 37 76 62 E0 E6 83 99 +69 26 41 CD FF 0C 44 AC F9 F4 91 B8 CA 63 5E 1D +B9 C4 38 D6 0C 11 19 1B 94 BE C9 4F EC 2E 5A 05 +3F 72 5F 41 44 3C 91 39 AC 2D 50 75 DF FD D3 11 +39 F2 43 18 D7 69 B0 A3 99 0C C0 6E 83 84 1A A8 +B0 37 6C 8E 32 B2 8E 4F AA 12 97 09 09 87 D3 FD +qemu-system-arm: terminating on signal 2 +``` + +But after 452c67a427, for example v8.0.0-918-g6972ef1440, I get : + +``` +$ qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio +[INF] Beginning TF-M provisioning +[WRN] TFM_DUMMY_PROVISIONING is not suitable for production! This device is NOT SECURE +[Sec Thread] Secure image initializing! +Booting TF-M 8209cb2ed +Creating an empty ITS flash layout. +Creating an empty PS flash layout. +[INF][Crypto] Provisioning entropy seed... complete. +*** Booting Zephyr OS build zephyr-v3.3.0-4041-g7ba5ecf451ef *** +TF-M IPC on mps2_an521_ns +qemu-system-arm: ../target/arm/cpu.h:2396: arm_is_secure_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed. +Aborted +``` +Steps to reproduce: +1. Build the Zephyr tfm_merged.hex file from Zephyr 7ba5ecf451 https://github.com/zephyrproject-rtos/zephyr/commit/7ba5ecf451ef29f96b30dbe5f0e54c1865839093 : ``west -v build -p -b mps2_an521_ns ./samples/tfm_integration/tfm_ipc`` +2. Build qemu-system-arm and run : ``qemu-system-arm -M mps2-an521 -device loader,file=tfm_merged.hex -serial stdio`` +Additional information: +More info to build Zephyr TF-M IPC example on the official repo https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/tfm_integration/tfm_ipc diff --git a/results/classifier/108/other/1658120 b/results/classifier/108/other/1658120 new file mode 100644 index 000000000..ffbe6791d --- /dev/null +++ b/results/classifier/108/other/1658120 @@ -0,0 +1,225 @@ +permissions: 0.856 +graphic: 0.838 +other: 0.825 +semantic: 0.823 +performance: 0.778 +device: 0.766 +PID: 0.757 +debug: 0.724 +boot: 0.719 +KVM: 0.711 +vnc: 0.679 +files: 0.678 +socket: 0.666 +network: 0.660 + +building with gcc-aarch64-linux-gnu + +Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross-compiler I'm getting the following : + + +In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, + from /root/qemu/util/compatfd.c:21: +/root/qemu/util/compatfd.c: In function 'qemu_signalfd': +/root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) + ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); + ^ +/root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +/root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +make: *** [util/compatfd.o] Error 1 + + +I had configured it with : + +../configure --target-list=x86_64-linux-user --static --cpu=aarch64 + +And I'm on : + +Linux ubuntu-512mb-fra1-01 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Thanks + +On 20 January 2017 at 15:21, Bilal Amarni <email address hidden> wrote: +> Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross- +> compiler I'm getting the following : +> +> +> In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, +> from /root/qemu/util/compatfd.c:21: +> /root/qemu/util/compatfd.c: In function 'qemu_signalfd': +> /root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) +> ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); +> ^ +> /root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +> /root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +> make: *** [util/compatfd.o] Error 1 + +You can see from the error message that the compile has +pulled in the include file /usr/include/x86_64-linux-gnu/sys/syscall.h +from the host, which is the x86-64 version. This is an +indication that either your cross compiler is broken, or +you're not using it at all. + +> ../configure --target-list=x86_64-linux-user --static --cpu=aarch64 + +You haven't told configure to use a cross compiler at all, +so it is building with the x86 system compiler, which +doesn't work. You shouldn't need to use the --cpu argument +at all, because if you get the build to use the right +compiler it can figure that out itself. (Passing --cpu=aarch64 +tells configure "ignore the fact this is an x86 compiler +and assume it's aarch64 instead", which just results in +things breaking because that assumption is wrong.) + +You need to pass configure --cross-prefix=aarch64-linux-gnu- +You'll also need to ensure you have an aarch64-linux-gnu-pkg-config +and that you have cross versions of all QEMU's library +dependencies (notably zlib and glib) in the right place that +your cross-compiler can find them, and that your cross +pkg-config is set up to point to them. + +On Ubuntu, you may find it easier to set up a cross-architecture +chroot and do the build in that (where it looks like a native +build). Cross-compilation of software with non-trivial +dependencies is always an enormous pain in the neck. + +thanks +-- PMM + + + +Bilal Amarni <email address hidden> writes: + +> Public bug reported: +> +> Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross- +> compiler I'm getting the following : +> +> +> In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, +> from /root/qemu/util/compatfd.c:21: +> /root/qemu/util/compatfd.c: In function 'qemu_signalfd': +> /root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) +> ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); +> ^ +> /root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +> /root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +> make: *** [util/compatfd.o] Error 1 +> +> +> I had configured it with : +> +> ../configure --target-list=x86_64-linux-user --static --cpu=aarch64 +> +> And I'm on : +> +> Linux ubuntu-512mb-fra1-01 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 +> 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Do you have: + +/usr/include/aarch64-linux-gnu/bits/syscall.h + +In your system? + +When cross compiling it is these sort of problems come from not having +the architecture specific development files. On Ubuntu you want +something like: + + apt-get build-dep -a arm64 qemu + +-- +Alex Bennée + + +Thanks for your replies, + +I've managed to compile it using a chroot as suggested by Peter. I just grabbed a pre-built rootfs from here : https://wiki.debian.org/Arm64Port#Pre-built_Rootfses, then installed qemu-user-static with apt-get and run the build from the chroot. + +Somehow "apt-get build-dep -a arm64 qemu" didn't work, I had tried to do "dpkg --add-architecture arm64 && apt-get update" before running this command but it couldn't find the needed packages, not sure why. + +In any case thanks for your help :) + +this was an issue in my setup + +Hello everyone!! + +I am having a issue when build qemu using gcc aarch64-linux-gnu-* on ubuntu 16.04: + +dong02@dong:~/qemu$ ./configure \ +> --prefix=/usr --cross-prefix=/usr/bin/aarch64-linux-gnu- \ +> --target-list=aarch64-softmmu \ +> --enable-attr --enable-fdt --enable-kvm \ +> --enable-sdl --enable-system --enable-tools \ +> --audio-drv-list= \ +> --disable-bluez --disable-brlapi --disable-bsd-user \ +> --disable-cap-ng --disable-curl --disable-curses \ +> --disable-docs --disable-libiscsi --disable-linux-aio \ +> --disable-rbd --disable-seccomp --disable-slirp \ +> --disable-sparse --disable-spice --disable-strip \ +> --disable-usb-redir --disable-vde --disable-virtfs \ +> --disable-vnc --disable-werror --disable-xen + +ERROR: zlib check failed + Make sure to have the zlib libs and headers installed. + +I installed zlib library: sudo apt-get install zlib1g-dev. However, result no change +Please help me!! + + +Hi Cao Van Dong, + +you need to install zlib1g-dev:arm64, see: + +https://github.com/qemu/qemu/blob/master/tests/docker/dockerfiles/debian-arm64-cross.docker + +Regards, + +Phil. + + +Cao Van Dong <email address hidden> writes: + +> Hello everyone!! +> +> I am having a issue when build qemu using gcc aarch64-linux-gnu-* on +> ubuntu 16.04: +> +> dong02@dong:~/qemu$ ./configure \ +>> --prefix=/usr --cross-prefix=/usr/bin/aarch64-linux-gnu- \ +>> --target-list=aarch64-softmmu \ +>> --enable-attr --enable-fdt --enable-kvm \ +>> --enable-sdl --enable-system --enable-tools \ +>> --audio-drv-list= \ +>> --disable-bluez --disable-brlapi --disable-bsd-user \ +>> --disable-cap-ng --disable-curl --disable-curses \ +>> --disable-docs --disable-libiscsi --disable-linux-aio \ +>> --disable-rbd --disable-seccomp --disable-slirp \ +>> --disable-sparse --disable-spice --disable-strip \ +>> --disable-usb-redir --disable-vde --disable-virtfs \ +>> --disable-vnc --disable-werror --disable-xen +> +> ERROR: zlib check failed +> Make sure to have the zlib libs and headers installed. +> +> I installed zlib library: sudo apt-get install zlib1g-dev. However, result no change +> Please help me!! + +You will have installed the x86 version of the zlib1g-dev libraries. +Unfortunately headers are not uniform across all architectures. + +If you want to ensure you have all the appropriate headers for cross +compiling QEMU do: + + apt-get build-dep -a arm64 qemu + +But you may well run into problems if the distribution isn't fully +multi-arch clean. This is one of the reasons we use docker to isolate +our various cross build environments: + + make docker-test-build@debian-arm64-cross J=9 TARGET_LIST=aarch64-softmmu + +-- +Alex Bennée + + diff --git a/results/classifier/108/other/1658141 b/results/classifier/108/other/1658141 new file mode 100644 index 000000000..8777f0748 --- /dev/null +++ b/results/classifier/108/other/1658141 @@ -0,0 +1,87 @@ +other: 0.701 +semantic: 0.690 +device: 0.661 +KVM: 0.654 +permissions: 0.642 +boot: 0.617 +debug: 0.597 +graphic: 0.580 +PID: 0.558 +socket: 0.532 +performance: 0.520 +network: 0.495 +files: 0.477 +vnc: 0.358 + +QEMU's default msrs handling causes Windows 10 64 bit to crash + +Wine uses QEMU to run its conformance test suite on Windows virtual machines. Wine's conformance tests check the behavior of various Windows APIs and verify that they behave as expected. + +One such test checks handling of exceptions down. When run on Windows 10 64 bit in QEMU it triggers a "KMOD_EXCEPTION_NOT_HANDLED" BSOD in the VM. See: +https://bugs.winehq.org/show_bug.cgi?id=40240 + + +To reproduce this bug: +* Pick a Windows 10 64 bit VM on an Intel host. + +* Start the VM. I'm pretty sure any qemu command will do but here's what I used: + qemu-system-x86_64 -machine pc-i440fx-2.1,accel=kvm -cpu core2duo,+nx -m 2048 -hda /var/lib/libvirt/images/wtbw1064.qcow2 + +* Grab the attached source code. The tar file is a bit big at 85KB because I had to include some Wine headers. However the source file proper, exception.c, is only 85 lines, including the LGPL header. + +* Compile the source code with MinGW by typing 'make'. This produces a 32 bit exception.exe executable. I'll attach it for good measure. + +* Put exception.exe on the VM and run it. + + +After investigation it turns out this happens: + * Only for Windows 10 64 bit guests. Windows 10 32 bit and older Windows versions are unaffected. + + * Only on Intel hosts. At least both my Xeon E3-1226 v3 and i7-4790K hosts are impacted but not my Opteron 6128 one. + + * It does not seem to depend on the emulated CPU type: on the Intel hosts this happened with both +core2duo,nx and 'copy the host configuration' and did not depend on the number of emulated cpus/cores. + + * This happened with both QEMU 2.1 and 2.7, and both the 3.16.0 and 4.8.11 Linux kernels, both on Debian 8.6 and Debian Testing. + + +After searching for quite some time I discovered that the kvm kernel module was sneaking the following messages into /var/log/syslog precisely when the BSOD happens: + +Dec 16 13:43:48 vm3 kernel: [ 191.624802] kvm [2064]: vcpu0, guest rIP: 0xfffff803cb3c0bf3 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop +Dec 16 13:43:48 vm3 kernel: [ 191.624835] kvm [2064]: vcpu0, guest rIP: 0xfffff803cb3c0c5c unhandled rdmsr: 0x1c9 + +A search on the Internet turned up a post suggesting to change kvm's ignore_msrs setting: + + echo 1 >/sys/module/kvm/parameters/ignore_msrs + +https://www.reddit.com/r/VFIO/comments/42dj7n/some_games_crash_to_biosboot_on_launch/ + +This does actually work and provides a workaround at least. + + + + + +It appears this bug affects me too with very similar symptons, but this time, it's while launching the recently released game "Puyo Poyo Tetris" using Steam in the guest VM. + +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.] + +This bug is still present. +However the "ignore_msrs=1" workaround does not work with QEmu 3.1 anymore. To prevent Windows 10 from crashing one must upgrade QEmu to 5.0.14. + + +The bug is still present so changing the status back to New. + + +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/131 + + diff --git a/results/classifier/108/other/1658506 b/results/classifier/108/other/1658506 new file mode 100644 index 000000000..5247473aa --- /dev/null +++ b/results/classifier/108/other/1658506 @@ -0,0 +1,33 @@ +device: 0.718 +network: 0.641 +vnc: 0.580 +files: 0.573 +graphic: 0.487 +socket: 0.471 +other: 0.383 +performance: 0.362 +semantic: 0.298 +boot: 0.293 +PID: 0.283 +KVM: 0.221 +permissions: 0.165 +debug: 0.164 + +qemu/hw/intc/arm_gicv3_cpuif.c:2433: bad expression ? + +qemu/hw/intc/arm_gicv3_cpuif.c:2433]: (style) Expression '(X & 0x2000000000000000) == 0x1' is always false. + +Source code is + + ((lr & ICH_LR_EL2_HW) == 1 || (lr & ICH_LR_EL2_EOI) == 0)) { + +Maybe better code + + ((lr & ICH_LR_EL2_HW) != 0 || (lr & ICH_LR_EL2_EOI) == 0)) { + +Thanks for this bug report -- I have sent a patch making the proposed change: http://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg05030.html + + +Now fixed in git master, commit d87576e38df7. + + diff --git a/results/classifier/108/other/1658634 b/results/classifier/108/other/1658634 new file mode 100644 index 000000000..8e591c708 --- /dev/null +++ b/results/classifier/108/other/1658634 @@ -0,0 +1,415 @@ +graphic: 0.851 +network: 0.832 +other: 0.821 +debug: 0.818 +semantic: 0.805 +PID: 0.798 +permissions: 0.795 +device: 0.783 +performance: 0.770 +files: 0.756 +boot: 0.753 +socket: 0.746 +KVM: 0.734 +vnc: 0.669 + +Can't get correct display with latest QEMU and OVMF BIOS + +I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and OVMF UEFI BIOS, however I can't get correct display output with default vga configuration (-vga std). However, qemu works with a couple of different configurations: +1. "-vga cirrus" + "-bios OVMF.fd": works +2. "-vga std" + non-UEFI bios: works + +The same error with QEMU 2.8.0 release. Everything works well on 2.7.0/1. + +(1) What phase of the guest do you get invalid video output in? Do you see the TianoCore splash screen? Does the grub2 menu appear? + +(2) I cannot reproduce the issue (with a different guest OS anyway); I just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at 7cf59c854f35), with stdvga; this combo works fine. + +(3) Can you bisect QEMU from 2.7 through 2.8, using the same OVMF binary? + +(4) Side point: please *never* use "-bios OVMF.fd"; use two pflash chips instead. Libvirt (strongly recommended) will do this for you. + +Thanks. + +Splash screen and UEFI shell were displayed correctly. Grub2 menu and +Ubuntu login screen also appeared, however the display didn't seem right. I +got very blurry output. + +[image: Inline image 1] + +With QEMU 2.7.0 and the same OVMF.fd, everything works well. + +Please let me know if anything is not clear. + +Thanks, +Kai + +On Mon, Jan 23, 2017 at 4:50 AM, Laszlo Ersek (Red Hat) <email address hidden> +wrote: + +> (1) What phase of the guest do you get invalid video output in? Do you +> see the TianoCore splash screen? Does the grub2 menu appear? +> +> (2) I cannot reproduce the issue (with a different guest OS anyway); I +> just tried QEMU (at d1c82f7cc344) and OVMF (built from edk2 at +> 7cf59c854f35), with stdvga; this combo works fine. +> +> (3) Can you bisect QEMU from 2.7 through 2.8, using the same OVMF +> binary? +> +> (4) Side point: please *never* use "-bios OVMF.fd"; use two pflash chips +> instead. Libvirt (strongly recommended) will do this for you. +> +> Thanks. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1658634 +> +> Title: +> Can't get correct display with latest QEMU and OVMF BIOS +> +> Status in QEMU: +> New +> +> Bug description: +> I tried to install a Ubuntu 16.04.1 Desktop 64bits with latest QEMU and +> OVMF UEFI BIOS, however I can't get correct display output with default vga +> configuration (-vga std). However, qemu works with a couple of different +> configurations: +> 1. "-vga cirrus" + "-bios OVMF.fd": works +> 2. "-vga std" + non-UEFI bios: works +> +> The same error with QEMU 2.8.0 release. Everything works well on +> 2.7.0/1. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +> + + +I downloaded "ubuntu-16.04.1-desktop-amd64.iso" (MD5: 17643c29e3c4609818f26becf76d29a3), and I can reproduce the issue -- the grub2 display is corrupt. (I didn't even look further than that.) I also confirm that it works fine with the same firmware, but using QEMU 2.7. + +Here's the result of the bisection: + +cd958edb1fae85d0c7d1e1acbff82d22724e8d64 is the first bad commit +commit cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Author: Marc-André Lureau <email address hidden> +Date: Fri Aug 26 13:47:11 2016 +0400 + + console: skip same-size resize + + virtio-gpu does a set-scanout at each frame (it might be a driver + regression). qemu_console_resize() recreate a surface even if the size + didn't change, and this shows up in profiling reports because the + surface is cleared. With this patch, I get a +15-20% glmark2 + improvement. + + Signed-off-by: Marc-André Lureau <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Gerd Hoffmann <email address hidden> + +If I revert this commit on top of current master -- it reverts cleanly -- then the grub2 screen displays fine again. + +For reference, this is my script: + +ISO=ubuntu-16.04.1-desktop-amd64.iso +CODE=OVMF_CODE.fd +TMPL=OVMF_VARS.fd + +cp $TMPL vars.fd + +qemu-system-x86_64 \ + -m 1024 \ + -M pc,accel=kvm \ + -device VGA \ + -drive if=pflash,readonly,format=raw,file=$CODE \ + -drive if=pflash,format=raw,file=vars.fd \ + -drive id=cdrom,if=none,readonly,format=raw,file=$ISO \ + -device virtio-scsi-pci,id=scsi0 \ + -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \ + -debugcon file:debug.log \ + -global isa-debugcon.iobase=0x402 \ + -chardev stdio,signal=off,mux=on,id=char0 \ + -mon chardev=char0,mode=readline,default \ + -serial chardev:char0 + + +Added Marc-André and Gerd to the CC list. + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Cc: Marc-André Lureau <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index b9575f2..67c65b7 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +Hi + +On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <email address hidden> +wrote: + +> Only skip surface reallocation in case the old surface was created using +> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +> might end up with a DisplaySurface with the wrong backing storage. +> +> Cc: <email address hidden> +> Cc: Marc-André Lureau <email address hidden> +> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +> Signed-off-by: Gerd Hoffmann <email address hidden> +> --- +> ui/console.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/ui/console.c b/ui/console.c +> index b9575f2..67c65b7 100644 +> --- a/ui/console.c +> +++ b/ui/console.c +> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, +> int height) +> +> assert(s->console_type == GRAPHIC_CONSOLE); +> +> - if (s->surface && +> + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +> pixman_image_get_width(s->surface->image) == width && +> pixman_image_get_height(s->surface->image) == height) { +> return; +> + +You are missing the 's->' ! + +with that, +Reviewed-by: Marc-André Lureau <email address hidden> + + +-- +> 1.8.3.1 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1658634 +> +> Title: +> Can't get correct display with latest QEMU and OVMF BIOS +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +> +-- +Marc-André Lureau + + +> > - if (s->surface && +> > + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +> > pixman_image_get_width(s->surface->image) == width && +> > pixman_image_get_height(s->surface->image) == height) { +> > return; +> > +> +> You are missing the 's->' ! + +Good catch. /me wonders why gcc didn't throw a warning on that one. + +Fixed. + +thanks, + Gerd + + + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index b9575f2..d573351 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +On 01/24/17 11:37, elmarco wrote: +> Hi +> +> On Tue, Jan 24, 2017 at 2:31 PM Gerd Hoffmann <email address hidden> +> wrote: +> +>> Only skip surface reallocation in case the old surface was created using +>> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +>> might end up with a DisplaySurface with the wrong backing storage. +>> +>> Cc: <email address hidden> +>> Cc: Marc-André Lureau <email address hidden> +>> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +>> Signed-off-by: Gerd Hoffmann <email address hidden> +>> --- +>> ui/console.c | 2 +- +>> 1 file changed, 1 insertion(+), 1 deletion(-) +>> +>> diff --git a/ui/console.c b/ui/console.c +>> index b9575f2..67c65b7 100644 +>> --- a/ui/console.c +>> +++ b/ui/console.c +>> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, +>> int height) +>> +>> assert(s->console_type == GRAPHIC_CONSOLE); +>> +>> - if (s->surface && +>> + if (s->surface && (surface->flags & QEMU_ALLOCATED_FLAG) && +>> pixman_image_get_width(s->surface->image) == width && +>> pixman_image_get_height(s->surface->image) == height) { +>> return; +>> +> +> You are missing the 's->' ! +> +> with that, +> Reviewed-by: Marc-André Lureau <email address hidden> + +With that change: + +Tested-by: Laszlo Ersek <email address hidden> + +Also, + +Cc: <email address hidden> + +Thanks +Laszlo + + +> -- +>> 1.8.3.1 +>> +>> -- +>> You received this bug notification because you are subscribed to the bug +>> report. +>> https://bugs.launchpad.net/bugs/1658634 +>> +>> Title: +>> Can't get correct display with latest QEMU and OVMF BIOS +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1658634/+subscriptions +>> + + + +On 01/24/17 12:10, Gerd Hoffmann wrote: +> Only skip surface reallocation in case the old surface was created using +> qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +> might end up with a DisplaySurface with the wrong backing storage. +> +> Cc: <email address hidden> +> Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +> Signed-off-by: Gerd Hoffmann <email address hidden> +> Reviewed-by: Marc-André Lureau <email address hidden> +> --- +> ui/console.c | 2 +- +> 1 file changed, 1 insertion(+), 1 deletion(-) +> +> diff --git a/ui/console.c b/ui/console.c +> index b9575f2..d573351 100644 +> --- a/ui/console.c +> +++ b/ui/console.c +> @@ -2121,7 +2121,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) +> +> assert(s->console_type == GRAPHIC_CONSOLE); +> +> - if (s->surface && +> + if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && +> pixman_image_get_width(s->surface->image) == width && +> pixman_image_get_height(s->surface->image) == height) { +> return; +> + +Tested-by: Laszlo Ersek <email address hidden> +Cc: <email address hidden> + +Thanks +Laszlo + + +It works well on my side with the patch. Thanks! + +Only skip surface reallocation in case the old surface was created using +qemu_alloc_display (via qemu_create_displaysurface) too, otherwise we +might end up with a DisplaySurface with the wrong backing storage. + +Cc: <email address hidden> +Fixes: cd958edb1fae85d0c7d1e1acbff82d22724e8d64 +Signed-off-by: Gerd Hoffmann <email address hidden> +Reviewed-by: Marc-André Lureau <email address hidden> +Tested-by: Laszlo Ersek <email address hidden> +Message-id: <email address hidden> +--- + ui/console.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/ui/console.c b/ui/console.c +index fe03a66..e353c85 100644 +--- a/ui/console.c ++++ b/ui/console.c +@@ -2116,7 +2116,7 @@ void qemu_console_resize(QemuConsole *s, int width, int height) + + assert(s->console_type == GRAPHIC_CONSOLE); + +- if (s->surface && ++ if (s->surface && (s->surface->flags & QEMU_ALLOCATED_FLAG) && + pixman_image_get_width(s->surface->image) == width && + pixman_image_get_height(s->surface->image) == height) { + return; +-- +1.8.3.1 + + + +Fixed in commit 3ef0c573d37b ("console: fix console resize", 2017-01-31), released in v2.9.0. + + diff --git a/results/classifier/108/other/1659267 b/results/classifier/108/other/1659267 new file mode 100644 index 000000000..528109094 --- /dev/null +++ b/results/classifier/108/other/1659267 @@ -0,0 +1,35 @@ +other: 0.726 +graphic: 0.709 +network: 0.690 +performance: 0.627 +device: 0.618 +semantic: 0.561 +vnc: 0.490 +socket: 0.394 +permissions: 0.372 +PID: 0.370 +files: 0.320 +debug: 0.288 +boot: 0.268 +KVM: 0.184 + +It's not possible to start a VM with a network cable unplugged + +There should be a command line (sub)option to unplug a network cable. +While from the monitor interface I can issue: + +set_link virtio-net-pci.0 off + +There's no way to fire a VM from command line with that cable already unplugged. +As an example, virtualbox can do it. + +this would be really useful for testing resilliance and auto fall-over systems in a vm, to be able to quickly virtually "unplug" a network connection. + +Note that you can start QEMU with the "-S" flag which means CPUS are paused. This gives you ability to run the "set_link" monitor command above, and then run "cont" to actually start the VM. Less convenient that a CLI flag, but functionally it is eqivalent. + +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/1659901 b/results/classifier/108/other/1659901 new file mode 100644 index 000000000..faa2fb477 --- /dev/null +++ b/results/classifier/108/other/1659901 @@ -0,0 +1,42 @@ +debug: 0.838 +other: 0.811 +device: 0.770 +boot: 0.760 +graphic: 0.737 +semantic: 0.731 +performance: 0.649 +socket: 0.491 +permissions: 0.446 +PID: 0.380 +network: 0.348 +files: 0.296 +vnc: 0.282 +KVM: 0.029 + +Regression: SIGSEGV running Java + +I have a build script that bootstraps a Debian armhf image. Part of the process involves running a Java program while inside a chroot. I am using Debian's qemu-user-static package to run the armhf Java binary on an amd64 system. + +qemu-user-static version 1:2.7+dfsg-3~bpo8+2 works fine. Version 1:2.8+dfsg-1~bpo8+1 always causes Java to crash with a SIGSEGV. The location of the crash appears to be random and hasn't been the same twice. + +I am using the Azul Systems Zulu Embedded Java runtime, rather than the regular OpenJDK runtime, because the Zulu runtime has an arm32 JIT whereas OpenJDK is interpreter-only on arm32. + +I can reproduce the problem easily by mounting the image created by my build script and executing "java -XshowSettings -version" in a chroot. I can give you the image if that would help debug the problem. + +Additional investigation reveals the problem has something to do with the Azul ARM32 JIT. If I run Java with -Xint to force interpreter-only mode, this problem doesn't occur. + +Similar issue reported in two other places on the net: + +https://github.com/multiarch/qemu-user-static/issues/18 "qemu-arm-static 2.8 and Java+Maven setup not working" + +https://bugs.linaro.org/show_bug.cgi?id=3259#c4 Bug 3259 - Javac fails within qemu-aarch64-static chroot on x86 + +fyi, similar seen for Raspbian9: + +https://bugs.launchpad.net/raspbian/+bug/1732556 + +Hi -- I believe we fixed the Java crashes as part of work done for the 2.12 release (and perhaps 3.0, I forget). Does this still reproduce with the most recent release of QEMU (eg the 4.0 release candidate) ? + + +[Expired for QEMU because there has been no activity for 60 days.] + |