summary refs log tree commit diff stats
path: root/results/classifier/108/other/1924
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/192481
-rw-r--r--results/classifier/108/other/1924231131
-rw-r--r--results/classifier/108/other/1924603114
-rw-r--r--results/classifier/108/other/192466930
-rw-r--r--results/classifier/108/other/192473889
-rw-r--r--results/classifier/108/other/1924912195
-rw-r--r--results/classifier/108/other/1924914105
-rw-r--r--results/classifier/108/other/192498760
8 files changed, 805 insertions, 0 deletions
diff --git a/results/classifier/108/other/1924 b/results/classifier/108/other/1924
new file mode 100644
index 000000000..f0845d1fe
--- /dev/null
+++ b/results/classifier/108/other/1924
@@ -0,0 +1,81 @@
+other: 0.963
+permissions: 0.952
+debug: 0.940
+graphic: 0.939
+KVM: 0.930
+vnc: 0.928
+performance: 0.921
+files: 0.912
+semantic: 0.909
+device: 0.896
+PID: 0.890
+socket: 0.880
+network: 0.848
+boot: 0.823
+
+memory leak for pthread_create by valgrind
+Description of problem:
+qemu_thread_create calls pthread_create have memory leak 
+valgrind stack
+```
+==4075190== 1,776 bytes in 3 blocks are possibly lost in loss record 6,778 of 6,978
+==4075190==    at 0x4C3721A: calloc (vg_replace_malloc.c:760)
+==4075190==    by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so)
+==4075190==    by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581)
+==4075190==    by 0x9C470C: do_spawn_thread (thread-pool.c:145)
+==4075190==    by 0x9C47C0: worker_thread (thread-pool.c:82)
+==4075190==    by 0x9AFD89: qemu_thread_start (qemu-thread-posix.c:541)
+==4075190==    by 0xADA3149: start_thread (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0xB0B7DC2: clone (in /usr/lib64/libc-2.28.so)
+==4075190==
+==4075190== 2,368 bytes in 4 blocks are possibly lost in loss record 6,834 of 6,978
+==4075190==    at 0x4C3721A: calloc (vg_replace_malloc.c:760)
+==4075190==    by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so)
+==4075190==    by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581)
+==4075190==    by 0x827FA8: kvm_start_vcpu_thread (kvm-accel-ops.c:75)
+==4075190==    by 0x633672: qemu_init_vcpu (cpus.c:642)
+==4075190==    by 0x722EA7: x86_cpu_realizefn (cpu.c:7430)
+==4075190==    by 0x833E2E: device_set_realized (qdev.c:510)
+==4075190==    by 0x8371D5: property_set_bool (object.c:2299)
+==4075190==    by 0x839512: object_property_set (object.c:1434)
+==4075190==    by 0x83C58E: object_property_set_qobject (qom-qobject.c:28)
+==4075190==    by 0x839783: object_property_set_bool (object.c:1503)
+```
+
+If we do vcpu hotplug and hot unplug for virtual machine continuously, the virtual memory and RES memory of qemu is increasing.
+Steps to reproduce:
+1. start qemu：
+valgrind   --tool=memcheck --leak-check=full /home/qemu-system-x86_64  -accel kvm -cpu host -m 4G -smp 4,maxcpus=64,sockets=8,dies=1,cores=8,threads=1  -drive file=/home/centosx861.qcow2,if=none,id=drive0,cache=none  -device virtio-blk,drive=drive0,bootindex=1  -monitor stdio -vnc :0
+2. after boot successful
+ctl+c kill qemu
+
+```
+==4075190== 1,776 bytes in 3 blocks are possibly lost in loss record 6,778 of 6,978
+==4075190==    at 0x4C3721A: calloc (vg_replace_malloc.c:760)
+==4075190==    by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so)
+==4075190==    by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581)
+==4075190==    by 0x9C470C: do_spawn_thread (thread-pool.c:145)
+==4075190==    by 0x9C47C0: worker_thread (thread-pool.c:82)
+==4075190==    by 0x9AFD89: qemu_thread_start (qemu-thread-posix.c:541)
+==4075190==    by 0xADA3149: start_thread (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0xB0B7DC2: clone (in /usr/lib64/libc-2.28.so)
+==4075190==
+==4075190== 2,368 bytes in 4 blocks are possibly lost in loss record 6,834 of 6,978
+==4075190==    at 0x4C3721A: calloc (vg_replace_malloc.c:760)
+==4075190==    by 0x40129EB: _dl_allocate_tls (in /usr/lib64/ld-2.28.so)
+==4075190==    by 0xADA3DA2: pthread_create@@GLIBC_2.2.5 (in /usr/lib64/libpthread-2.28.so)
+==4075190==    by 0x9B0DA5: qemu_thread_create (qemu-thread-posix.c:581)
+==4075190==    by 0x827FA8: kvm_start_vcpu_thread (kvm-accel-ops.c:75)
+==4075190==    by 0x633672: qemu_init_vcpu (cpus.c:642)
+==4075190==    by 0x722EA7: x86_cpu_realizefn (cpu.c:7430)
+==4075190==    by 0x833E2E: device_set_realized (qdev.c:510)
+==4075190==    by 0x8371D5: property_set_bool (object.c:2299)
+==4075190==    by 0x839512: object_property_set (object.c:1434)
+==4075190==    by 0x83C58E: object_property_set_qobject (qom-qobject.c:28)
+==4075190==    by 0x839783: object_property_set_bool (object.c:1503)
+```
+Additional information:
+
diff --git a/results/classifier/108/other/1924231 b/results/classifier/108/other/1924231
new file mode 100644
index 000000000..56370c543
--- /dev/null
+++ b/results/classifier/108/other/1924231
@@ -0,0 +1,131 @@
+KVM: 0.714
+graphic: 0.597
+performance: 0.575
+other: 0.571
+vnc: 0.562
+permissions: 0.542
+PID: 0.507
+debug: 0.503
+semantic: 0.489
+device: 0.477
+files: 0.408
+network: 0.331
+boot: 0.322
+socket: 0.245
+
+Getting "qemu: uncaught target signal 11 (Segmentation fault)" when the installing "libc-bin" which "wget" depends on.
+
+the QEMU release version where the bug was found.
+
+apt list --installed | grep qemu
+qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.14 amd64 [installed]
+
+
+The installing "libc-bin" which "wget" depends on crashes as below when we execute docker image of Debian GNU/Linux bullseye for ARM64 on Ubuntu 20.04 for AMD64.
+This problem also occurs on CI(GitHub Actions)(https://github.com/groonga/groonga/runs/2338497272?check_suite_focus=true#step:11:127).
+Probably, The cause of this crash is https://bugs.launchpad.net/qemu/+bug/1749393.
+This bug has already been fixed in qemu-user-static pacakge for Ubuntu 20.10.
+
+However, this fix is not included in qemu-user-static pacakge for Ubuntu 20.04.
+Currently, GitHub Actions does not support Ubuntu 20.10.
+Therefore, this problem is still happening in CI.
+
+Would it be possible for you to backport this fix into Ubuntu 20.04?
+
+
+How to reproduce:
+
+sudo apt install -y qemu-user-static docker.io
+sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt install -y wget'
+
+WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
+
+Get:1 http://deb.debian.org/debian bullseye InRelease [142 kB]
+Get:2 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB]
+Get:3 http://deb.debian.org/debian bullseye-updates InRelease [40.1 kB]
+Get:4 http://deb.debian.org/debian bullseye/main arm64 Packages [8084 kB]
+Get:5 http://security.debian.org/debian-security bullseye-security/main arm64 Packages [808 B]
+Fetched 8311 kB in 4s (2001 kB/s)
+Reading package lists...
+Building dependency tree...
+Reading state information...
+2 packages can be upgraded. Run 'apt list --upgradable' to see them.
+
+WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
+
+Reading package lists...
+Building dependency tree...
+Reading state information...
+The following additional packages will be installed:
+  ca-certificates libpsl5 openssl publicsuffix
+The following NEW packages will be installed:
+  ca-certificates libpsl5 openssl publicsuffix wget
+0 upgraded, 5 newly installed, 0 to remove and 2 not upgraded.
+Need to get 2111 kB of archives.
+After this operation, 5844 kB of additional disk space will be used.
+Get:1 http://deb.debian.org/debian bullseye/main arm64 openssl arm64 1.1.1k-1 [829 kB]
+Get:2 http://deb.debian.org/debian bullseye/main arm64 ca-certificates all 20210119 [158 kB]
+Get:3 http://deb.debian.org/debian bullseye/main arm64 libpsl5 arm64 0.21.0-1.2 [57.1 kB]
+Get:4 http://deb.debian.org/debian bullseye/main arm64 wget arm64 1.21-1 [946 kB]
+Get:5 http://deb.debian.org/debian bullseye/main arm64 publicsuffix all 20210108.1309-1 [121 kB]
+debconf: delaying package configuration, since apt-utils is not installed
+Fetched 2111 kB in 0s (12.9 MB/s)
+Selecting previously unselected package openssl.
+(Reading database ... 6640 files and directories currently installed.)
+Preparing to unpack .../openssl_1.1.1k-1_arm64.deb ...
+Unpacking openssl (1.1.1k-1) ...
+Selecting previously unselected package ca-certificates.
+Preparing to unpack .../ca-certificates_20210119_all.deb ...
+Unpacking ca-certificates (20210119) ...
+Selecting previously unselected package libpsl5:arm64.
+Preparing to unpack .../libpsl5_0.21.0-1.2_arm64.deb ...
+Unpacking libpsl5:arm64 (0.21.0-1.2) ...
+Selecting previously unselected package wget.
+Preparing to unpack .../archives/wget_1.21-1_arm64.deb ...
+Unpacking wget (1.21-1) ...
+Selecting previously unselected package publicsuffix.
+Preparing to unpack .../publicsuffix_20210108.1309-1_all.deb ...
+Unpacking publicsuffix (20210108.1309-1) ...
+Setting up libpsl5:arm64 (0.21.0-1.2) ...
+Setting up wget (1.21-1) ...
+Setting up openssl (1.1.1k-1) ...
+Setting up publicsuffix (20210108.1309-1) ...
+Setting up ca-certificates (20210119) ...
+debconf: unable to initialize frontend: Dialog
+debconf: (TERM is not set, so the dialog frontend is not usable.)
+debconf: falling back to frontend: Readline
+debconf: unable to initialize frontend: Readline
+debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/aarch64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.)
+debconf: falling back to frontend: Teletype
+Updating certificates in /etc/ssl/certs...
+129 added, 0 removed; done.
+Processing triggers for libc-bin (2.31-11) ...
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+dpkg: error processing package libc-bin (--configure):
+ installed libc-bin package post-installation script subprocess returned error exit status 139
+Processing triggers for ca-certificates (20210119) ...
+Updating certificates in /etc/ssl/certs...
+0 added, 0 removed; done.
+Running hooks in /etc/ca-certificates/update.d...
+done.
+Errors were encountered while processing:
+ libc-bin
+E: Sub-process /usr/bin/dpkg returned an error code (1)
+
+This is the bug tracker for upstream QEMU. If you'd like to request Ubuntu to backport some fix into their packages of QEMU, you'll need to file it against the Ubuntu QEMU package bug tracker. Since those bugs are also tracked in Launchpad, I'll try re-componenting this bug report to the Ubuntu QEMU package...
+
+
+I'm sorry that I send a wrong destination of report.
+Thank you for re-componenting this bug report.
+
+Thank you for taking the time to report this bug and helping to make Ubuntu better.
+
+In Launchpad we use one bug per issue. Since this issue is already reported in bug 1749393, I'm marking this bug as a duplicate of that one.
+
+You're requesting to backport the fix to 20.04. We can track this in the other bug with a bug task, which I'll open now.
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
diff --git a/results/classifier/108/other/1924603 b/results/classifier/108/other/1924603
new file mode 100644
index 000000000..e865ca48e
--- /dev/null
+++ b/results/classifier/108/other/1924603
@@ -0,0 +1,114 @@
+semantic: 0.906
+permissions: 0.905
+other: 0.901
+KVM: 0.898
+graphic: 0.898
+debug: 0.885
+device: 0.854
+performance: 0.845
+files: 0.838
+PID: 0.836
+socket: 0.818
+network: 0.810
+boot: 0.787
+vnc: 0.782
+
+Incorrect feature negotiation for vhost-vdpa netdevice
+
+QEMU cmdline:
+=============
+./x86_64-softmmu/qemu-system-x86_64 -machine accel=kvm -m 2G -hda  /gautam/centos75_1.qcow2 -name gautam,process=gautam -enable-kvm -netdev vhost-vdpa,id=mynet0,vhostdev=/dev/vhost-vdpa-0 -device virtio-net-pci,netdev=mynet0,mac=02:AA:BB:DD:00:20,disable-modern=off,page-per-vq=on -cpu host --nographic
+
+Host OS:
+========
+Linux kernel 5.11 running on x86 host
+
+Guest OS:
+==========
+CentOS 7.5
+
+Root cause analysis:
+=====================
+
+For vhost-vdpa netdevice, the feature negotiation results in sending the superset of features received from device in call to get_features vdpa ops callback.
+
+During the feature-negotiation phase, the acknowledged feature bits are initialized with backend_features  and then checked for supported feature bits in vhost_ack_features():
+
+void vhost_net_ack_features(struct vhost_net *net, uint64_t features)
+{
+  net->dev.acked_features = net->dev.backend_features;
+  vhost_ack_features(&net->dev, vhost_net_get_feature_bits(net), features);
+}
+
+ 
+The vhost_ack_features() function just builds up on the dev.acked_features and never trims it down:
+
+void vhost_ack_features(struct vhost_dev *hdev, const int *feature_bits, uint64_t features)
+{     const int *bit = feature_bits;
+
+      while (*bit != VHOST_INVALID_FEATURE_BIT) {
+           uint64_t bit_mask = (1ULL << *bit);      
+
+            if (features & bit_mask)
+                 hdev->acked_features |= bit_mask;
+
+            bit++;
+       }
+}
+
+Because of this hdev->acked_features is always minimally equal to the value of device features and this is the value that is passed to the device in set_features callback:
+
+static int vhost_dev_set_features(struct vhost_dev *dev, bool enable_log)
+{
+       uint64_t *features = dev->acked_features;
+       .....
+       r = dev->vhost_ops->*vhost_set_features*(dev, features);
+}
+
+QEMU version: 5.1.0
+
+https://qemu-devel.nongnu.narkive.com/jUimpLt0/patch-vhost-net-initialize-acked-features-to-a-safe-value-during-ack
+This review of a patch that introduced "acked_features = backend_features" behaviour suggests that acked_features should be 0 by default, but it ended up pushing it as it is now (as they say that not setting acked_features to backend_features sometimes makes acked_features value 'unexpected')
+
+Other devices initialize acked_features to guest_features (basically what VM writes to driver_features ANDed with device_features), changing default value to any of those (0 as review initially suggested, or guest_features) should fix this problem for us
+
+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 ticket has been moved here (thanks, Gautam):
+https://gitlab.com/qemu-project/qemu/-/issues/331
+... thus I'm closing this on Launchpad now.
+
+Thanks Thomas Huth.
+
+I couldn't find an option to assign the issue on gitlab to anyone. Can you please help with that?
+
+Not sure who should be the assignee here ... maybe it's best if you write a mail to the people who have been involved in the original code (see https://gitlab.com/qemu-project/qemu/-/commit/108a64818e69be0a97c ) and ask them who could have a look at this issue.
+
diff --git a/results/classifier/108/other/1924669 b/results/classifier/108/other/1924669
new file mode 100644
index 000000000..499a8aeab
--- /dev/null
+++ b/results/classifier/108/other/1924669
@@ -0,0 +1,30 @@
+graphic: 0.830
+device: 0.568
+semantic: 0.542
+vnc: 0.489
+network: 0.455
+performance: 0.448
+other: 0.353
+PID: 0.266
+socket: 0.263
+permissions: 0.248
+debug: 0.236
+boot: 0.206
+KVM: 0.173
+files: 0.120
+
+VFP code cannot see CPACR write in the same TB
+
+If FPU is enabled by writing to CPACR, and the code is in the same translation block as the following VFP code, qemu generates "v7M NOCP UsageFault".
+
+This can be reproduced with git HEAD (commit 8fe9f1f891eff4e37f82622b7480ee748bf4af74).
+
+The target binary is attached. The qemu command is:
+qemu-system-arm -nographic -monitor null -serial null -semihosting -machine mps2-an505 -cpu cortex-m33 -kernel cpacr_vfp.elf -d in_asm,int,exec,cpu,cpu_reset,unimp,guest_errors,nochain -D log
+
+If the code is changed a little, so that they are not in the same block, VFP code can see the effect of CPACR, or -singlestep of qemu has the same result.
+
+
+
+Sorry, it's because a "ISB" is missing after CPACR is changed. Not bug of qemu.
+
diff --git a/results/classifier/108/other/1924738 b/results/classifier/108/other/1924738
new file mode 100644
index 000000000..d01ef7a3f
--- /dev/null
+++ b/results/classifier/108/other/1924738
@@ -0,0 +1,89 @@
+graphic: 0.910
+semantic: 0.885
+other: 0.862
+performance: 0.801
+debug: 0.760
+permissions: 0.739
+device: 0.677
+KVM: 0.673
+PID: 0.653
+network: 0.634
+socket: 0.627
+files: 0.591
+vnc: 0.589
+boot: 0.573
+
+Failed to restore domain - error load load virtio-balloon:virtio
+
+I noticed a domain restore error on my virtual machines.
+I can't reproduce the error on a test virtual machine.
+
+sudo virsh save linux2020 /var/lib/libvirt/qemu/save/linux2020.save
+Domain 'linux2020' saved to /var/lib/libvirt/qemu/save/linux2020.save
+
+sudo virsh restore /var/lib/libvirt/qemu/save/linux2020.save
+error: Failed to restore domain from /var/lib/libvirt/qemu/save/linux2020.save
+error: внутренняя ошибка: QEMU неожиданно завершил работу монитора: qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'server' deprecated
+Please use server=on instead
+qemu-system-x86_64: -chardev socket,id=charchannel0,fd=52,server,nowait: warning: short-form boolean option 'nowait' deprecated
+Please use wait=off instead
+qemu-system-x86_64: -spice port=5900,addr=0.0.0.0,disable-ticketing,image-compression=off,seamless-migration=on: warning: short-form boolean option 'disable-ticketing' deprecated
+Please use disable-ticketing=on instead
+2021-04-16T09:47:15.037700Z qemu-system-x86_64: VQ 0 size 0x80 < last_avail_idx 0x0 - used_idx 0xcccc
+2021-04-16T09:47:15.037737Z qemu-system-x86_64: Failed to load virtio-balloon:virtio
+2021-04-16T09:47:15.037744Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/virtio-balloon'
+2021-04-16T09:47:15.037849Z qemu-system-x86_64: load of migration failed: Operation not permitted
+
+If in the machine configuration replace
+<type arch="x86_64" machine="pc-i440fx-5.1">hvm</type>
+to
+<type arch="x86_64" machine="pc-i440fx-5.0">hvm</type>
+the virtual machine is recovering normally
+
+
+
+Can you just clarify:
+  a) Which version of qemu are you running?
+  b) Was the save done with the pc-i440fx-5.1 as well as the load?
+  c) What guest are you running?
+
+a) Checked for versions 5.2.0 and 6.0.0rc.
+b) Save and restore with pc-i440fx-5.1.
+c) Used OS Linux NixOS Unstable.
+If clean install NixOS system - the error is not reproduced. It was not possible to track what affects the restore domain.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know how to transfer the bug to the new system if
+(if still necessary). Thus we're setting the status to "Incomplete" now.
+
+In the unlikely case that the bug has already been fixed in the final
+6.0 release 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 should be
+moved to the new system, 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.]
+
+Ticket has been re-opened here :
+https://gitlab.com/qemu-project/qemu/-/issues/485
+
diff --git a/results/classifier/108/other/1924912 b/results/classifier/108/other/1924912
new file mode 100644
index 000000000..b61cc63aa
--- /dev/null
+++ b/results/classifier/108/other/1924912
@@ -0,0 +1,195 @@
+other: 0.857
+vnc: 0.812
+KVM: 0.808
+debug: 0.801
+semantic: 0.795
+permissions: 0.795
+device: 0.792
+graphic: 0.786
+performance: 0.785
+PID: 0.785
+socket: 0.782
+network: 0.773
+boot: 0.763
+files: 0.761
+
+VirtIO drivers don't work on Windows: "GLib: Too many handles to wait for!" crash
+
+I ran SerenityOS <https://github.com/SerenityOS/serenity> out of WSL2 with native Windows QEMU. The system runs fine on the Linux QEMU (with Windows X-Server). However, with Windows QEMU I get a hard crash after the following output:
+
+```
+[#0 colonel(0:0)]: Scheduler[0]: idle loop running
+[init_stage2(2:2)]: PCI [0000:00:00:00] PCI::ID [8086:1237]
+[init_stage2(2:2)]: PCI [0000:00:01:00] PCI::ID [8086:7000]
+[init_stage2(2:2)]: PCI [0000:00:01:01] PCI::ID [8086:7010]
+[init_stage2(2:2)]: PCI [0000:00:01:02] PCI::ID [8086:7020]
+[init_stage2(2:2)]: PCI [0000:00:01:03] PCI::ID [8086:7113]
+[init_stage2(2:2)]: PCI [0000:00:02:00] PCI::ID [1234:1111]
+[init_stage2(2:2)]: PCI [0000:00:03:00] PCI::ID [8086:2922]
+[init_stage2(2:2)]: PCI [0000:00:04:00] PCI::ID [1af4:1003]
+[init_stage2(2:2)]: PCI [0000:00:05:00] PCI::ID [1af4:1005]
+[init_stage2(2:2)]: PCI [0000:00:06:00] PCI::ID [8086:100e]
+[#0 init_stage2(2:2)]: BXVGA: framebuffer @ P0xf8000000
+[#0 init_stage2(2:2)]: BXVGADevice resolution set to 1024x768 (pitch=4096)
+[init_stage2(2:2)]: UHCI: Controller found PCI::ID [8086:7020] @ PCI [0000:00:01:02]
+[init_stage2(2:2)]: UHCI: I/O base IO c080
+[init_stage2(2:2)]: UHCI: Interrupt line: 11
+[#0 init_stage2(2:2)]: UHCI: Allocated framelist at physical address P0x00e40000
+[#0 init_stage2(2:2)]: UHCI: Framelist is at virtual address V0xc115d000
+[#0 init_stage2(2:2)]: UHCI: QH(0xc115f000) @ 14946304: link_ptr=14946338, element_link_ptr=1
+[#0 init_stage2(2:2)]: UHCI: QH(0xc115f020) @ 14946336: link_ptr=14946370, element_link_ptr=1
+[#0 init_stage2(2:2)]: UHCI: QH(0xc115f040) @ 14946368: link_ptr=14946402, element_link_ptr=1
+[#0 init_stage2(2:2)]: UHCI: QH(0xc115f060) @ 14946400: link_ptr=14946434, element_link_ptr=1
+[#0 init_stage2(2:2)]: UHCI: QH(0xc115f080) @ 14946432: link_ptr=14958593, element_link_ptr=1
+[#0 init_stage2(2:2)]: UHCI: Reset completed
+[#0 init_stage2(2:2)]: UHCI: Started
+[#0 init_stage2(2:2)]: DMIExpose: SMBIOS 32bit Entry point @ P0x000f5870
+[#0 init_stage2(2:2)]: DMIExpose: Data table @ P0x000f5890
+[#0 init_stage2(2:2)]: VirtIOConsole: Found @ PCI [0000:00:04:00]
+[#0 init_stage2(2:2)]: Trying to unregister unused handler (?)
+[#0 init_stage2(2:2)]: VirtIOConsole: Multi port is not yet supported!
+[#0 init_stage2(2:2)]: VirtIOConsole: cols: 0, rows: 0, max nr ports 0
+qemu-system-i386.exe: warning: GLib: Too many handles to wait for!
+```
+
+The lines starting with [ are SerenityOS output; QEMU warns "GLib: Too many handles to wait for!" and crashes right after (can't even Ctrl-C in the WSL command line, force-close in Windows necessary). A window is still spawned but as the OS already switched out of text mode, just a black screen is visible as QEMU crashes.
+
+I first thought this to be an issue with SerenityOS and reported it over there: <https://github.com/SerenityOS/serenity/issues/6422>. The kernel devs pointed out that this seems to be a VirtIO driver/device issue on the Windows build of QEMU, because the Serenity kernel tries to initialize VirtIO devices which apparently crashes QEMU. There will be mitigations from the SerenityOS side (by allowing to disable VirtIO on boot) but it would of course be great if QEMU handled this properly.
+
+Version info: Both QEMU 6.0.0-rc3 and 5.2.0 exhibit this issue. Windows release is 20H2, WSL2 is running Debian 10.9. SerenityOS has no proper version but it was reproduced on the most current commits as of 18/04/2021.
+
+Did you build your own Windows binary based on the official sources? Or did you use a precompiled binary? If yes, which one?
+
+Please describe the exact steps to reproduce the issue.
+
+I used the pre-built binaries with the versions described above. I did not change any install options so this can be reproduced after using the official install binaries for each version.
+
+Le 19/04/2021 à 12:39, Stefan Weil a écrit :
+> I can confirm the issue also with latest official QEMU sources.
+> 
+> Related issue URLs:
+> 
+> https://github.com/tesseract-ocr/tesseract/issues/2838
+> 
+> https://bugs.launchpad.net/qemu/+bug/1924912
+> 
+> Instructions and files required to reproduce the issue:
+> 
+> https://qemu.weilnetz.de/test/bugs/1924912/
+> 
+> Michael, Laurent, maybe you have an idea how to narrow down this issue?
+
+Could it be related to the number of file descriptors that can differ between linux an windows?
+
+We have a series of patches that sets the number of queues to the number of vCPU:
+
+a4eef0711b2c vhost-user-blk-pci: default num_queues to -smp N
+9445e1e15e66 virtio-blk-pci: default num_queues to -smp N
+6a558822849f virtio-scsi-pci: default num_queues to -smp N
+4e5163bd8444 virtio-scsi: introduce a constant for fixed virtqueues
+1436f32a84c3 virtio-pci: add virtio_pci_optimal_num_queues() helper
+
+And I think it can have inpact on the number of open file descriptors.
+
+You can try by specifiying "num_queues=1" with the virtio interfaces on the QEMU command line.
+(ot choose a machine type earlier than 5.2)
+
+Thanks,
+Laurent
+
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+Moved to https://gitlab.com/qemu-project/qemu/-/issues/332
+
+So it's a virtio console issue on a windows host.
+
+[#0 init_stage2(2:2)]: VirtIOConsole: Found @ PCI [0000:00:04:00]
+[#0 init_stage2(2:2)]: Trying to unregister unused handler (?)
+[#0 init_stage2(2:2)]: VirtIOConsole: Multi port is not yet supported!
+[#0 init_stage2(2:2)]: VirtIOConsole: cols: 0, rows: 0, max nr ports 0
+qemu-system-i386.exe: warning: GLib: Too many handles to wait for!
+
+Laurent?
+
+
+On Mon, Apr 19, 2021 at 04:30:23PM +0200, Laurent Vivier wrote:
+> Le 19/04/2021 à 12:39, Stefan Weil a écrit :
+> > I can confirm the issue also with latest official QEMU sources.
+> > 
+> > Related issue URLs:
+> > 
+> > https://github.com/tesseract-ocr/tesseract/issues/2838
+> > 
+> > https://bugs.launchpad.net/qemu/+bug/1924912
+> > 
+> > Instructions and files required to reproduce the issue:
+> > 
+> > https://qemu.weilnetz.de/test/bugs/1924912/
+> > 
+> > Michael, Laurent, maybe you have an idea how to narrow down this issue?
+> 
+> Could it be related to the number of file descriptors that can differ between linux an windows?
+> 
+> We have a series of patches that sets the number of queues to the number of vCPU:
+> 
+> a4eef0711b2c vhost-user-blk-pci: default num_queues to -smp N
+> 9445e1e15e66 virtio-blk-pci: default num_queues to -smp N
+> 6a558822849f virtio-scsi-pci: default num_queues to -smp N
+> 4e5163bd8444 virtio-scsi: introduce a constant for fixed virtqueues
+> 1436f32a84c3 virtio-pci: add virtio_pci_optimal_num_queues() helper
+> 
+> And I think it can have inpact on the number of open file descriptors.
+> 
+> You can try by specifiying "num_queues=1" with the virtio interfaces on the QEMU command line.
+> (ot choose a machine type earlier than 5.2)
+> 
+> Thanks,
+> Laurent
+
+
+
+Le 26/05/2021 à 11:47, mst a écrit :
+> So it's a virtio console issue on a windows host.
+> 
+> [#0 init_stage2(2:2)]: VirtIOConsole: Found @ PCI [0000:00:04:00]
+> [#0 init_stage2(2:2)]: Trying to unregister unused handler (?)
+> [#0 init_stage2(2:2)]: VirtIOConsole: Multi port is not yet supported!
+> [#0 init_stage2(2:2)]: VirtIOConsole: cols: 0, rows: 0, max nr ports 0
+> qemu-system-i386.exe: warning: GLib: Too many handles to wait for!
+> 
+> Laurent?
+
+I will answer on gitlab issue:
+
+https://gitlab.com/qemu-project/qemu/-/issues/332
+
+
diff --git a/results/classifier/108/other/1924914 b/results/classifier/108/other/1924914
new file mode 100644
index 000000000..0d276ecb1
--- /dev/null
+++ b/results/classifier/108/other/1924914
@@ -0,0 +1,105 @@
+KVM: 0.803
+permissions: 0.768
+other: 0.752
+graphic: 0.706
+performance: 0.687
+device: 0.684
+debug: 0.683
+vnc: 0.676
+semantic: 0.667
+boot: 0.642
+network: 0.624
+PID: 0.611
+files: 0.587
+socket: 0.541
+
+Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver)
+
+System is Arch Linux (guest and host OS).
+
+Problem:
+
+Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands.
+
+This is the command I use to run my guest:
+
+qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22
+
+This doesn't happen when I use X with i3-wm.
+
+
+
+I can't get it to happen with -vga qxl.
+
+I can't reproduce it with weston.
+
+-cpu host -smp 4 makes the hang/freeze go away.
+
+From the dmesg above:
+
+[  573.935889] Oops: 0000 [#1] PREEMPT SMP PTI
+[  573.935892] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.11.11-arch1-1 #1
+[  573.935896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.14.0-1 04/01/2014
+[  573.935899] Workqueue: events_unbound commit_work [drm_kms_helper]
+[  573.935949] RIP: 0010:dma_fence_wait_timeout+0x20/0x110
+[  573.935953] Code: 5c 41 5d 41 5e 41 5f c3 66 90 0f 1f 44 00 00 41 54 55 53 48 83 ec 08 48 85 d2 0f 88 da 00 00 00 48 89 fd 89 f3 0f 1f 44 00 00 <48> 8b 45 08 0f b6 f3 48 89 ef 48 8b 40 28 48 85 c0 0f 84 ac 00 00
+[  573.935956] RSP: 0018:ffffbbf100043db0 EFLAGS: 00010206
+[  573.935958] RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000001
+[  573.935959] RDX: 7fffffffffffffff RSI: 0000000000000001 RDI: 0000000000000000
+[  573.935961] RBP: 0000000000000000 R08: 0000000000000001 R09: ffff90631e171bc0
+[  573.935962] R10: 0000000000000001 R11: 0000000000000001 R12: ffff906408336000
+[  573.935964] R13: ffff906380260cc0 R14: ffff906401700000 R15: 0000000000000005
+[  573.935966] FS:  0000000000000000(0000) GS:ffff90643bc00000(0000) knlGS:0000000000000000
+[  573.935967] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[  573.935969] CR2: 0000000000000008 CR3: 000000011ed86000 CR4: 00000000000006f0
+[  573.935973] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[  573.935974] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[  573.935976] Call Trace:
+[  573.935983]  ? virtio_gpu_notify+0x46/0x60 [virtio_gpu]
+[  573.935995]  virtio_gpu_cursor_plane_update+0x1c3/0x2a0 [virtio_gpu]
+[  573.936005]  drm_atomic_helper_commit_planes+0xb7/0x220 [drm_kms_helper]
+[  573.936024]  drm_atomic_helper_commit_tail+0x42/0x80 [drm_kms_helper]
+[  573.936038]  commit_tail+0xce/0x130 [drm_kms_helper]
+[  573.936050]  process_one_work+0x214/0x3e0
+[  573.936054]  worker_thread+0x4d/0x3d0
+[  573.936056]  ? rescuer_thread+0x3c0/0x3c0
+[  573.936058]  kthread+0x133/0x150
+[  573.936061]  ? __kthread_bind_mask+0x60/0x60
+[  573.936064]  ret_from_fork+0x22/0x30
+[  573.936072] Modules linked in: cfg80211 rfkill ghash_generic gf128mul cryptd gcm ccm algif_aead des_generic libdes cbc ecb algif_skcipher cmac md4 algif_hash af_alg ppdev pktcdvd parport_pc parport i2c_piix4 joydev mousedev mac_hid psmouse qemu_fw_cfg pcspkr pkcs8_key_parser speakup_soft speakup fuse bpf_preload ip_tables x_tables overlay squashfs loop isofs sr_mod cdrom ata_generic pata_acpi virtio_gpu virtio_dma_buf drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm intel_agp intel_gtt serio_raw e1000 virtio_pci ata_piix agpgart floppy
+[  573.936161] CR2: 0000000000000008
+[  573.936163] ---[ end trace 0f1e24b3ea0a35cd ]---
+[  573.936165] RIP: 0010:dma_fence_wait_timeout+0x20/0x110
+
+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/other/1924987 b/results/classifier/108/other/1924987
new file mode 100644
index 000000000..5fd1f0d20
--- /dev/null
+++ b/results/classifier/108/other/1924987
@@ -0,0 +1,60 @@
+graphic: 0.883
+files: 0.781
+other: 0.750
+device: 0.698
+performance: 0.688
+semantic: 0.611
+permissions: 0.592
+network: 0.519
+PID: 0.514
+vnc: 0.452
+debug: 0.444
+socket: 0.358
+boot: 0.311
+KVM: 0.305
+
+Storage | Two decimal digits precision
+
+Tested on: Fedora 34; Component: qemu-img-5.2.0-5.fc34.1.x86_64
+
+Hello. A two decimal digits precision is most appropriated on systems whose storage capacities have to be saved. That is one of the reason why such precision is supported in the context of creation of virtual machines in several Unix/Linux virtualization platforms; virt-manager is one of them. That last exhibits virtual disks size values with such precision – 128.00 GiB – nevertheless it lacks yet a mention illustrating physical disks size values. 
+
+Storage values exhibited in qemu-img and virt-manager are already according to a clear format; thus, values are not attached to their measure units (#value# #units#).
+
+$ qemu-img info ~/.local/share/libvirt/images/fedora_default.img | sed -n '2,4p'
+file format: qcow2
+virtual size: 128 GiB (137438953472 bytes)
+disk size: 147 MiB
+
+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.]
+