add 18th iteration of classifier

533 files changed, 22586 insertions, 0 deletions

diff --git a/results/classifier/118/device/1014 b/results/classifier/118/device/1014
new file mode 100644
index 00000000..a4139805
--- /dev/null
+++ b/results/classifier/118/device/1014
@@ -0,0 +1,33 @@
+device: 0.896
+mistranslation: 0.611
+assembly: 0.575
+arm: 0.560
+network: 0.557
+architecture: 0.508
+semantic: 0.506
+kernel: 0.504
+debug: 0.429
+graphic: 0.400
+hypervisor: 0.356
+peripherals: 0.343
+boot: 0.340
+ppc: 0.277
+i386: 0.235
+TCG: 0.232
+KVM: 0.225
+user-level: 0.213
+PID: 0.211
+risc-v: 0.210
+permissions: 0.205
+x86: 0.185
+performance: 0.182
+VMM: 0.179
+socket: 0.157
+vnc: 0.138
+virtual: 0.122
+register: 0.099
+files: 0.013
+
+Make -chardev, -serial and others accept stderr like they accept stdio
+Additional information:
+It's not clear what should happen when the guest tries to read from (instead of write to) the character device. On the other hand, I don't think the specific behavior matters very much.
diff --git a/results/classifier/118/device/1016 b/results/classifier/118/device/1016
new file mode 100644
index 00000000..b746531b
--- /dev/null
+++ b/results/classifier/118/device/1016
@@ -0,0 +1,33 @@
+device: 0.830
+assembly: 0.790
+architecture: 0.670
+network: 0.592
+arm: 0.515
+graphic: 0.447
+semantic: 0.337
+socket: 0.296
+performance: 0.295
+virtual: 0.279
+register: 0.277
+ppc: 0.237
+boot: 0.232
+vnc: 0.164
+risc-v: 0.146
+mistranslation: 0.123
+debug: 0.091
+permissions: 0.087
+hypervisor: 0.070
+VMM: 0.069
+PID: 0.063
+i386: 0.063
+kernel: 0.062
+TCG: 0.044
+x86: 0.027
+files: 0.020
+user-level: 0.013
+peripherals: 0.012
+KVM: 0.002
+
+In-process sandboxing of the majority of QEMU via WebAssembly or similar
+Additional information:
+This would be in addition to other sandboxes, such as sVirt.
diff --git a/results/classifier/118/device/1017793 b/results/classifier/118/device/1017793
new file mode 100644
index 00000000..35509814
--- /dev/null
+++ b/results/classifier/118/device/1017793
@@ -0,0 +1,38 @@
+device: 0.816
+graphic: 0.787
+architecture: 0.759
+semantic: 0.650
+mistranslation: 0.574
+risc-v: 0.569
+socket: 0.556
+network: 0.533
+peripherals: 0.506
+vnc: 0.477
+performance: 0.454
+register: 0.426
+PID: 0.381
+kernel: 0.378
+permissions: 0.364
+debug: 0.336
+boot: 0.333
+hypervisor: 0.326
+virtual: 0.326
+user-level: 0.304
+arm: 0.278
+ppc: 0.269
+files: 0.246
+TCG: 0.226
+VMM: 0.224
+assembly: 0.205
+KVM: 0.027
+x86: 0.020
+i386: 0.008
+
+S3 Trio64V+ support
+
+Is it possible to add S3 Trio emulation to QEMU at all? Since 0.12.3 the Cirrus Logic seems no longer working properly (bad font render/corrupted video). Also, S3 is a widely supported device on many OSes and architectures, which will give more compatibility for QEMU.
+
+Thanks!
+
+Sorry, seems like nobody got interested in adding S3 emulation to QEMU within the last 6 years, so this is very unlikely going to happen. Thus I'm closing this bug ticket now.
+
diff --git a/results/classifier/118/device/1021 b/results/classifier/118/device/1021
new file mode 100644
index 00000000..5d6b4920
--- /dev/null
+++ b/results/classifier/118/device/1021
@@ -0,0 +1,39 @@
+device: 0.874
+KVM: 0.687
+boot: 0.657
+debug: 0.651
+architecture: 0.638
+graphic: 0.508
+vnc: 0.503
+socket: 0.493
+network: 0.470
+performance: 0.445
+register: 0.443
+risc-v: 0.421
+hypervisor: 0.392
+virtual: 0.348
+kernel: 0.335
+peripherals: 0.322
+x86: 0.318
+i386: 0.307
+arm: 0.304
+ppc: 0.300
+permissions: 0.271
+semantic: 0.269
+TCG: 0.263
+PID: 0.238
+VMM: 0.146
+files: 0.104
+mistranslation: 0.100
+user-level: 0.067
+assembly: 0.062
+
+nVMX: QEMU does not clear nVMX state through KVM(L0) when guest(L2) trigger a reboot event through I/O-Port(0xCF9)
+Description of problem:
+#
+Steps to reproduce:
+Guest(L2) write 0xCF9 to trigger a platform reboot.
+
+#
+Additional information:
+
diff --git a/results/classifier/118/device/1024 b/results/classifier/118/device/1024
new file mode 100644
index 00000000..bdff3e3c
--- /dev/null
+++ b/results/classifier/118/device/1024
@@ -0,0 +1,40 @@
+device: 0.935
+graphic: 0.916
+architecture: 0.846
+files: 0.778
+register: 0.728
+debug: 0.726
+performance: 0.710
+network: 0.704
+PID: 0.695
+socket: 0.692
+vnc: 0.671
+boot: 0.627
+semantic: 0.626
+kernel: 0.602
+mistranslation: 0.540
+risc-v: 0.533
+permissions: 0.529
+ppc: 0.469
+user-level: 0.447
+arm: 0.446
+peripherals: 0.437
+TCG: 0.367
+VMM: 0.351
+assembly: 0.348
+hypervisor: 0.255
+i386: 0.148
+virtual: 0.117
+x86: 0.103
+KVM: 0.035
+
+Unable to build QEMU with dbus display support on Windows
+Description of problem:
+When building QEMU on Windows with `./configure --enable-dbus-display --enable-modules`, the following error appears:
+
+`ERROR: Modules are not available for Windows`
+Steps to reproduce:
+1. Attempt to build QEMU on Windows (MSYS2 MinGW) with dbus display support
+Additional information:
+Attempting to build with only `--enable-dbus-display` does not work either, as it requires `--enable-modules`, which does not work on Windows:
+`../meson.build:1598:0: ERROR: Feature dbus_display cannot be enabled: -display dbus requires --enable-modules`
diff --git a/results/classifier/118/device/1033 b/results/classifier/118/device/1033
new file mode 100644
index 00000000..96229de6
--- /dev/null
+++ b/results/classifier/118/device/1033
@@ -0,0 +1,57 @@
+architecture: 0.972
+device: 0.962
+graphic: 0.936
+semantic: 0.894
+debug: 0.835
+PID: 0.807
+arm: 0.780
+ppc: 0.765
+user-level: 0.689
+performance: 0.681
+peripherals: 0.616
+register: 0.604
+network: 0.590
+risc-v: 0.568
+kernel: 0.515
+files: 0.492
+mistranslation: 0.449
+vnc: 0.435
+hypervisor: 0.423
+permissions: 0.410
+socket: 0.386
+VMM: 0.298
+virtual: 0.294
+i386: 0.246
+x86: 0.205
+boot: 0.199
+TCG: 0.186
+assembly: 0.138
+KVM: 0.044
+
+fakeroot under qemu fails with 'semop(1): encountered an error: Function not implemented'
+Description of problem:
+Appears to be the same issue as that discussed and reportedly fixed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965109
+
+Running raspberry pi os in a chroot (using schroot). Execution of fakeroot as part of dpkg-buildpackage results in:
+
+```
+dpkg-buildpackage: info: source package clementine
+dpkg-buildpackage: info: source version 1.4.0rc1-836-g4665916ba~bullseye
+dpkg-buildpackage: info: source distribution bullseye
+dpkg-buildpackage: info: source changed by David Sansome <me@davidsansome.com>
+dpkg-buildpackage: info: host architecture armhf
+ dpkg-source --before-build .
+ fakeroot debian/rules clean
+semop(1): encountered an error: Function not implemented
+dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 1
+```
+
+This is the same error as reported in bug 965109, but I'm running the most recent version of qemu - I built it from the git repo, so it should include the fix for 965109.
+Steps to reproduce:
+1. Setup (s)chroot with arm architecture (although the architecture may not matter) 
+2. Run fakeroot in the chroot
+3. Observe the failure related to the semop syscall
+Additional information:
+- Not sure what other information I can provide to be helpful.
+- The command line listed above is what I gather from ps; it's how qemu-arm-static is called by schroot. I've not been able to figure out _how_ schroot calls qemu-arm-static, I only know it does.
+- I compiled qemu from source using my own user id, and ran into an issue with make install, so I manually used install to deploy the executable to /usr/local/bin... And then had to symlink that to /usr/bin as schroot apparently hardcodes the location of qemu-arm-static (at least it did not pick up the version I'd placed in /usr/local/bin).
diff --git a/results/classifier/118/device/1034980 b/results/classifier/118/device/1034980
new file mode 100644
index 00000000..a972fdeb
--- /dev/null
+++ b/results/classifier/118/device/1034980
@@ -0,0 +1,52 @@
+device: 0.923
+graphic: 0.892
+ppc: 0.891
+architecture: 0.839
+peripherals: 0.825
+register: 0.804
+socket: 0.802
+PID: 0.770
+performance: 0.754
+network: 0.727
+vnc: 0.701
+permissions: 0.649
+mistranslation: 0.641
+files: 0.577
+risc-v: 0.566
+semantic: 0.564
+boot: 0.551
+arm: 0.517
+kernel: 0.500
+VMM: 0.473
+debug: 0.472
+virtual: 0.424
+hypervisor: 0.398
+user-level: 0.386
+TCG: 0.313
+i386: 0.182
+KVM: 0.142
+assembly: 0.118
+x86: 0.074
+
+pseries machine: vscsi scsi qemu cd-rom does not work in win32
+
+On Win32, the cd-rom device is not detected at all in the pseries machine (SLOF):
+   
+   qemu-system-ppc64 -M pseries -m 512 -cdrom img.iso
+      ....etc.
+   VSCSI: Looking for disks
+   Populating /pci@800000020000001,0
+
+
+On Linux however, the scsi qemu cd-rom device is detected and works fine in the pseries machine:
+
+   qemu-system-ppc64 -M pseries -m 512 -cdrom img.iso
+      ....etc.
+   VSCSI: Looking for disks
+      SCSI ID 2 CD-ROM   : "QEMU     QEMU CD-ROM      1.1."
+   Populating /pci@800000020000001,0
+
+This started to work in version 1.2, thanks!
+
+Closing this bug, since it is working now according to comment #1
+
diff --git a/results/classifier/118/device/1038070 b/results/classifier/118/device/1038070
new file mode 100644
index 00000000..8f364fcb
--- /dev/null
+++ b/results/classifier/118/device/1038070
@@ -0,0 +1,149 @@
+arm: 0.935
+device: 0.932
+permissions: 0.929
+assembly: 0.927
+PID: 0.920
+semantic: 0.920
+register: 0.915
+risc-v: 0.910
+architecture: 0.899
+performance: 0.898
+KVM: 0.897
+graphic: 0.896
+hypervisor: 0.890
+mistranslation: 0.883
+user-level: 0.880
+debug: 0.872
+ppc: 0.864
+VMM: 0.858
+virtual: 0.851
+x86: 0.849
+boot: 0.848
+vnc: 0.844
+files: 0.844
+kernel: 0.837
+TCG: 0.827
+network: 0.825
+socket: 0.824
+peripherals: 0.817
+i386: 0.635
+
+> qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore
+
+Linux Distro: Gentoo
+
+Smartcard Activkey doesn't work anymore. I use it without problem till version
+qemu-kvm-1.0.1.
+
+Follow a log extraction:
+2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 :
+internal error Process exited while reading console log output: char device
+redirected to /dev/pts/40
+ccid-card-emulated: failed to initialize vcard
+qemu-system-x86_64: -device
+ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device
+'ccid-card-emulated' could not be initialized
+
+2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 :
+internal error Process exited while reading console log output: char device
+redirected to /dev/pts/40
+ccid-card-emulated: failed to initialize vcard
+qemu-system-x86_64: -device
+ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device
+'ccid-card-emulated' could not be initialized
+
+If you need any other info please tell me. 
+
+I've tried with git version with same problem.
+
+On Fri, Aug 17, 2012 at 12:50:14PM -0000, linuxale wrote:
+> Public bug reported:
+> 
+> Linux Distro: Gentoo
+> 
+> Smartcard Activkey doesn't work anymore. I use it without problem till version
+> qemu-kvm-1.0.1.
+> 
+> Follow a log extraction:
+> 2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 :
+> internal error Process exited while reading console log output: char device
+> redirected to /dev/pts/40
+> ccid-card-emulated: failed to initialize vcard
+> qemu-system-x86_64: -device
+> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device
+> 'ccid-card-emulated' could not be initialized
+> 
+> 2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 :
+> internal error Process exited while reading console log output: char device
+> redirected to /dev/pts/40
+> ccid-card-emulated: failed to initialize vcard
+> qemu-system-x86_64: -device
+> ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device
+> 'ccid-card-emulated' could not be initialized
+> 
+> If you need any other info please tell me.
+
+I've tried 1.1.1 and current upstream with a Windows 7 guest and the
+device seems to show up and function properly in both cases.
+
+One way that I *can* reproduce the error is by running your command-line
+with an NSS database at some place other than the default search path
+(/etc/pki/nssdb in 1.1 and upstream). I don't think this has changed
+since 1.0, but maybe something changed on the distro side?
+
+Can you try reproducing by compiling from upstream source?
+
+> 
+> I've tried with git version with same problem.
+> 
+> ** 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/1038070
+> 
+> Title:
+>   > qemu-kvm-1.1.1-r1 - USB activkey doesn't work anymore
+> 
+> Status in QEMU:
+>   New
+> 
+> Bug description:
+>   Linux Distro: Gentoo
+> 
+>   Smartcard Activkey doesn't work anymore. I use it without problem till version
+>   qemu-kvm-1.0.1.
+> 
+>   Follow a log extraction:
+>   2012-08-14 16:27:34.751+0000: 5487: error : qemuProcessReadLogOutput:1298 :
+>   internal error Process exited while reading console log output: char device
+>   redirected to /dev/pts/40
+>   ccid-card-emulated: failed to initialize vcard
+>   qemu-system-x86_64: -device
+>   ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device
+>   'ccid-card-emulated' could not be initialized
+> 
+>   2012-08-14 16:28:01.018+0000: 5486: error : qemuProcessReadLogOutput:1298 :
+>   internal error Process exited while reading console log output: char device
+>   redirected to /dev/pts/40
+>   ccid-card-emulated: failed to initialize vcard
+>   qemu-system-x86_64: -device
+>   ccid-card-emulated,backend=nss-emulated,id=smartcard0,bus=ccid0.0: Device
+>   'ccid-card-emulated' could not be initialized
+> 
+>   If you need any other info please tell me.
+> 
+>   I've tried with git version with same problem.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1038070/+subscriptions
+> 
+
+
+Have you ever tried to reproduce this with the upstream QEMU version?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1049 b/results/classifier/118/device/1049
new file mode 100644
index 00000000..5d6d320e
--- /dev/null
+++ b/results/classifier/118/device/1049
@@ -0,0 +1,31 @@
+device: 0.915
+performance: 0.695
+VMM: 0.535
+vnc: 0.531
+architecture: 0.524
+TCG: 0.521
+risc-v: 0.464
+network: 0.448
+PID: 0.443
+arm: 0.387
+i386: 0.380
+ppc: 0.377
+KVM: 0.350
+mistranslation: 0.325
+x86: 0.318
+peripherals: 0.298
+socket: 0.288
+graphic: 0.286
+hypervisor: 0.273
+debug: 0.237
+virtual: 0.236
+semantic: 0.224
+assembly: 0.210
+boot: 0.197
+permissions: 0.184
+user-level: 0.158
+register: 0.143
+kernel: 0.130
+files: 0.117
+
+Have DeviceRealize return boolean indicating error
diff --git a/results/classifier/118/device/1050823 b/results/classifier/118/device/1050823
new file mode 100644
index 00000000..ad1f6767
--- /dev/null
+++ b/results/classifier/118/device/1050823
@@ -0,0 +1,52 @@
+device: 0.952
+network: 0.934
+ppc: 0.900
+socket: 0.885
+graphic: 0.821
+peripherals: 0.786
+vnc: 0.779
+PID: 0.766
+debug: 0.700
+semantic: 0.680
+register: 0.651
+kernel: 0.631
+files: 0.630
+KVM: 0.614
+architecture: 0.613
+boot: 0.570
+performance: 0.528
+arm: 0.494
+mistranslation: 0.484
+user-level: 0.438
+risc-v: 0.425
+permissions: 0.369
+TCG: 0.348
+VMM: 0.348
+i386: 0.338
+x86: 0.316
+hypervisor: 0.218
+virtual: 0.198
+assembly: 0.103
+
+segmentation fault when using usb-net and -netdev tap
+
+The following command causes a Segmentation fault:
+
+qemu-kvm -usb -device usb-net,netdev=net0 -netdev tap,id=net0
+Segmentation fault
+
+The following command does not:
+
+qemu-kvm -usb -device usb-net,netdev=net0 -netdev user,id=net0
+
+Program received signal SIGSEGV, Segmentation fault.
+usbnet_can_receive (nc=0x55555657dc20)
+    at /home/pbonzini/work/upstream/qemu/hw/usb/dev-network.c:1292
+1292	    if (is_rndis(s) && s->rndis_state != RNDIS_DATA_INITIALIZED) {
+
+First reported at https://bugzilla.redhat.com/show_bug.cgi?id=843310
+
+Patch has been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=278412d0e710e2e848c
+... so I think it should be OK now to close this ticket.
+
diff --git a/results/classifier/118/device/107 b/results/classifier/118/device/107
new file mode 100644
index 00000000..7a82b3fd
--- /dev/null
+++ b/results/classifier/118/device/107
@@ -0,0 +1,31 @@
+device: 0.845
+graphic: 0.747
+performance: 0.596
+virtual: 0.485
+network: 0.435
+hypervisor: 0.416
+VMM: 0.394
+architecture: 0.369
+mistranslation: 0.368
+debug: 0.333
+semantic: 0.297
+vnc: 0.261
+permissions: 0.248
+register: 0.222
+i386: 0.199
+ppc: 0.197
+user-level: 0.153
+arm: 0.143
+PID: 0.142
+x86: 0.138
+boot: 0.131
+assembly: 0.113
+TCG: 0.109
+files: 0.109
+kernel: 0.095
+risc-v: 0.076
+socket: 0.057
+peripherals: 0.029
+KVM: 0.013
+
+qemu-img fixed vhd issues
diff --git a/results/classifier/118/device/1072 b/results/classifier/118/device/1072
new file mode 100644
index 00000000..5e99353c
--- /dev/null
+++ b/results/classifier/118/device/1072
@@ -0,0 +1,54 @@
+device: 0.903
+graphic: 0.836
+performance: 0.834
+architecture: 0.826
+debug: 0.813
+files: 0.775
+PID: 0.659
+kernel: 0.655
+network: 0.650
+socket: 0.634
+semantic: 0.634
+arm: 0.630
+register: 0.625
+x86: 0.595
+peripherals: 0.589
+permissions: 0.575
+vnc: 0.572
+hypervisor: 0.559
+ppc: 0.553
+i386: 0.489
+TCG: 0.479
+risc-v: 0.471
+user-level: 0.449
+VMM: 0.419
+virtual: 0.339
+boot: 0.328
+KVM: 0.313
+mistranslation: 0.301
+assembly: 0.207
+
+different behavior when remote debugger is used
+Description of problem:
+I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: 
+
+1. Is this intended behavior?
+1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below)
+1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference.
+
+The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR)
+The preprocessed code is as follows:
+   if (((((st.st_mode)) & 0170000) == (0020000))) 
+
+I then compared two different approaches to run Qemu:
+
+1. I used the following command line to collect the trace:  qemu_aarch64 -strace  -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR
+1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). 
+
+Thanks!
+Steps to reproduce:
+1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64)
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/118/device/1077 b/results/classifier/118/device/1077
new file mode 100644
index 00000000..ba21bdab
--- /dev/null
+++ b/results/classifier/118/device/1077
@@ -0,0 +1,31 @@
+device: 0.948
+network: 0.890
+performance: 0.843
+hypervisor: 0.841
+architecture: 0.757
+debug: 0.568
+graphic: 0.534
+virtual: 0.523
+register: 0.521
+semantic: 0.430
+arm: 0.410
+socket: 0.380
+files: 0.353
+peripherals: 0.349
+vnc: 0.340
+permissions: 0.307
+boot: 0.293
+mistranslation: 0.290
+user-level: 0.284
+risc-v: 0.255
+ppc: 0.254
+PID: 0.233
+assembly: 0.183
+kernel: 0.059
+i386: 0.054
+TCG: 0.052
+VMM: 0.041
+x86: 0.016
+KVM: 0.006
+
+Qemu - Can't connect to ESXi guest
diff --git a/results/classifier/118/device/1080 b/results/classifier/118/device/1080
new file mode 100644
index 00000000..602c46b1
--- /dev/null
+++ b/results/classifier/118/device/1080
@@ -0,0 +1,31 @@
+device: 0.827
+performance: 0.642
+user-level: 0.519
+graphic: 0.475
+architecture: 0.473
+network: 0.454
+semantic: 0.445
+arm: 0.374
+peripherals: 0.330
+PID: 0.318
+ppc: 0.307
+permissions: 0.300
+register: 0.269
+hypervisor: 0.248
+debug: 0.248
+files: 0.244
+kernel: 0.241
+mistranslation: 0.240
+virtual: 0.209
+risc-v: 0.155
+vnc: 0.148
+i386: 0.125
+boot: 0.109
+assembly: 0.103
+TCG: 0.096
+socket: 0.088
+x86: 0.082
+VMM: 0.035
+KVM: 0.002
+
+Qemu build fails on Ubuntu
diff --git a/results/classifier/118/device/1083 b/results/classifier/118/device/1083
new file mode 100644
index 00000000..6133eac6
--- /dev/null
+++ b/results/classifier/118/device/1083
@@ -0,0 +1,31 @@
+device: 0.881
+architecture: 0.843
+performance: 0.587
+semantic: 0.496
+virtual: 0.463
+mistranslation: 0.431
+graphic: 0.358
+register: 0.355
+boot: 0.311
+arm: 0.279
+kernel: 0.215
+ppc: 0.194
+network: 0.182
+PID: 0.181
+permissions: 0.137
+user-level: 0.122
+files: 0.117
+assembly: 0.107
+debug: 0.101
+vnc: 0.094
+socket: 0.089
+risc-v: 0.077
+x86: 0.076
+hypervisor: 0.068
+VMM: 0.019
+i386: 0.018
+peripherals: 0.010
+TCG: 0.008
+KVM: 0.002
+
+Qemu on Windows - Emulate 64Bit CPU
diff --git a/results/classifier/118/device/1088 b/results/classifier/118/device/1088
new file mode 100644
index 00000000..98489a51
--- /dev/null
+++ b/results/classifier/118/device/1088
@@ -0,0 +1,31 @@
+device: 0.820
+network: 0.813
+architecture: 0.770
+socket: 0.690
+arm: 0.630
+performance: 0.615
+peripherals: 0.532
+files: 0.518
+boot: 0.486
+debug: 0.475
+vnc: 0.470
+hypervisor: 0.452
+PID: 0.437
+graphic: 0.410
+register: 0.405
+permissions: 0.401
+kernel: 0.397
+risc-v: 0.361
+ppc: 0.348
+VMM: 0.290
+semantic: 0.286
+TCG: 0.263
+assembly: 0.227
+x86: 0.218
+i386: 0.207
+virtual: 0.189
+user-level: 0.129
+mistranslation: 0.083
+KVM: 0.007
+
+QEMU 7.0.0 fails to build with linker that does not support --dynamic-list
diff --git a/results/classifier/118/device/1090558 b/results/classifier/118/device/1090558
new file mode 100644
index 00000000..1b3b989e
--- /dev/null
+++ b/results/classifier/118/device/1090558
@@ -0,0 +1,44 @@
+device: 0.815
+socket: 0.807
+vnc: 0.780
+network: 0.752
+ppc: 0.731
+architecture: 0.685
+register: 0.683
+kernel: 0.676
+graphic: 0.670
+arm: 0.666
+risc-v: 0.587
+files: 0.568
+boot: 0.509
+semantic: 0.472
+mistranslation: 0.455
+debug: 0.452
+TCG: 0.421
+performance: 0.408
+i386: 0.389
+x86: 0.365
+PID: 0.327
+permissions: 0.309
+user-level: 0.297
+VMM: 0.247
+assembly: 0.205
+virtual: 0.194
+peripherals: 0.192
+hypervisor: 0.156
+KVM: 0.026
+
+hw/mc146818: error reading RTC_HOURS_ALARM
+
+get_next_alarm() doesn't read the RTC_HOURS_ALARM field correctly.
+
+- Bit 7 must be masked before conversion from BCD.
+- Care must be taken to check the don't care condition before masking.
+- The PM bit must be read from RTC_HOURS_ALARM, not from RTC_HOURS (as is done in convert_hour()).
+
+Seen in commit e376a788ae130454ad5e797f60cb70d0308babb6.
+
+The problem is obviously there, but I tried pretty hard to make it fail and couldn't so it seems latent.  If you can, please provide a patch to tests/rtc-test.c that shows the bug.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1090602 b/results/classifier/118/device/1090602
new file mode 100644
index 00000000..5c239beb
--- /dev/null
+++ b/results/classifier/118/device/1090602
@@ -0,0 +1,48 @@
+device: 0.919
+graphic: 0.780
+network: 0.658
+socket: 0.637
+files: 0.623
+semantic: 0.617
+register: 0.605
+permissions: 0.594
+mistranslation: 0.589
+architecture: 0.564
+performance: 0.556
+risc-v: 0.553
+vnc: 0.549
+debug: 0.525
+peripherals: 0.525
+i386: 0.523
+PID: 0.505
+VMM: 0.489
+ppc: 0.485
+x86: 0.473
+hypervisor: 0.467
+kernel: 0.439
+boot: 0.430
+user-level: 0.427
+arm: 0.409
+KVM: 0.408
+TCG: 0.385
+assembly: 0.374
+virtual: 0.286
+
+RFE: Allow specifying usb-host device by serial number
+
+Currently you can pass through a host USB device to the guest like
+
+  -device usb-host,vendorid=0x1234,productid=0x5678
+
+Which is all well and good, but has problems if you are trying to assign to identical USB devices to the same guest.
+
+It would be useful if there was an additional option that allow matching against the device's serial number, which should allow differentiating between two devices with the same product+vendor.
+
+This was originally filed at https://bugzilla.redhat.com/show_bug.cgi?id=640332
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1103903 b/results/classifier/118/device/1103903
new file mode 100644
index 00000000..6c567e91
--- /dev/null
+++ b/results/classifier/118/device/1103903
@@ -0,0 +1,73 @@
+device: 0.842
+mistranslation: 0.832
+files: 0.830
+PID: 0.812
+virtual: 0.795
+vnc: 0.742
+kernel: 0.741
+register: 0.701
+socket: 0.701
+performance: 0.692
+network: 0.662
+x86: 0.635
+arm: 0.629
+VMM: 0.626
+ppc: 0.619
+permissions: 0.592
+architecture: 0.588
+hypervisor: 0.583
+semantic: 0.575
+graphic: 0.572
+TCG: 0.514
+i386: 0.514
+peripherals: 0.513
+boot: 0.485
+risc-v: 0.474
+user-level: 0.409
+debug: 0.401
+KVM: 0.378
+assembly: 0.340
+
+drive_mirror on a resized image creates file with wrong size
+
+Repro steps:
+
+qemu-img create -f qcow2 base 32M
+qemu-img create -f qcow2 -o backing_file=base disk
+qemu-img resize /home/vishvananda/disk 64M
+qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio
+QEMU 1.3.0 monitor - type 'help' for more information
+(qemu) drive_mirror vda test
+Formatting 'test', fmt=qcow2 size=33554432 backing_file='base' backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off
+
+the file is 32M instead of 64M:
+
+qemu-img info test
+image: test
+file format: qcow2
+virtual size: 32M (33554432 bytes)
+disk size: 196K
+cluster_size: 65536
+backing file: base
+backing file format: qcow2
+
+Workaround is to precreate the new file of the proper size and pass -n
+
+qemu-img create -f qcow2 base 32M
+qemu-img create -f qcow2 -o backing_file=base disk
+qemu-img resize /home/vishvananda/disk 64M
+qemu-img create -f qcow2 -o backing_file=base test 64M
+qemu-system-x86_64 -drive file=disk,id=vda -vnc :1 -monitor stdio
+QEMU 1.3.0 monitor - type 'help' for more information
+(qemu) drive_mirror vda test -n
+
+
+
+reformatted patch and submitted upstream:
+
+http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg04584.html
+
+Patch has been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=8689907266b649b757c220
+... so I think it should be OK to close this bug ticket now.
+
diff --git a/results/classifier/118/device/1106 b/results/classifier/118/device/1106
new file mode 100644
index 00000000..bc16b672
--- /dev/null
+++ b/results/classifier/118/device/1106
@@ -0,0 +1,39 @@
+device: 0.889
+graphic: 0.884
+peripherals: 0.706
+register: 0.654
+performance: 0.640
+semantic: 0.623
+mistranslation: 0.480
+arm: 0.470
+VMM: 0.434
+architecture: 0.429
+i386: 0.421
+vnc: 0.396
+ppc: 0.395
+x86: 0.392
+TCG: 0.390
+PID: 0.381
+network: 0.372
+risc-v: 0.343
+permissions: 0.308
+debug: 0.296
+socket: 0.287
+KVM: 0.282
+kernel: 0.267
+boot: 0.260
+user-level: 0.218
+files: 0.181
+hypervisor: 0.142
+virtual: 0.141
+assembly: 0.040
+
+undefined address access cause failure
+Description of problem:
+Hi,
+I used serial device as below:
+qemu/hw/char/serial.c
+It defines only support 8 registers address space(offset 0x00-0x32). And in guest os, the hardware is synopsys dw_apb_uart which is compatible with 16550.
+when it access low 8 registers, it works ok. but it may access high address(0x8c) which serial.c not defined, then fail occur.
+
+Is there anyway to handle this, access address which device not defined, expect it no handle, but not cause system crash. like read is zero and write ignore.
diff --git a/results/classifier/118/device/1108 b/results/classifier/118/device/1108
new file mode 100644
index 00000000..7aae7917
--- /dev/null
+++ b/results/classifier/118/device/1108
@@ -0,0 +1,31 @@
+device: 0.867
+performance: 0.601
+arm: 0.554
+network: 0.486
+graphic: 0.388
+boot: 0.377
+architecture: 0.282
+vnc: 0.245
+PID: 0.235
+ppc: 0.213
+risc-v: 0.211
+i386: 0.203
+x86: 0.200
+semantic: 0.189
+debug: 0.186
+TCG: 0.150
+socket: 0.135
+KVM: 0.126
+user-level: 0.122
+peripherals: 0.096
+virtual: 0.083
+register: 0.068
+mistranslation: 0.064
+VMM: 0.063
+hypervisor: 0.058
+kernel: 0.047
+assembly: 0.034
+permissions: 0.025
+files: 0.008
+
+D-Bus display does fails to build if libgdm is not detected
diff --git a/results/classifier/118/device/112 b/results/classifier/118/device/112
new file mode 100644
index 00000000..7e0370d0
--- /dev/null
+++ b/results/classifier/118/device/112
@@ -0,0 +1,31 @@
+device: 0.937
+network: 0.804
+architecture: 0.773
+performance: 0.723
+peripherals: 0.492
+debug: 0.319
+assembly: 0.289
+graphic: 0.284
+socket: 0.260
+semantic: 0.236
+boot: 0.231
+files: 0.205
+register: 0.186
+arm: 0.169
+risc-v: 0.131
+user-level: 0.126
+hypervisor: 0.122
+mistranslation: 0.114
+permissions: 0.112
+virtual: 0.101
+PID: 0.101
+kernel: 0.077
+VMM: 0.052
+x86: 0.045
+TCG: 0.044
+KVM: 0.027
+ppc: 0.025
+vnc: 0.016
+i386: 0.004
+
+setting unsupported timeout for i6300esb watchdog causes hw reset
diff --git a/results/classifier/118/device/1124 b/results/classifier/118/device/1124
new file mode 100644
index 00000000..7c3ba993
--- /dev/null
+++ b/results/classifier/118/device/1124
@@ -0,0 +1,31 @@
+device: 0.916
+architecture: 0.846
+network: 0.780
+performance: 0.767
+ppc: 0.759
+debug: 0.726
+peripherals: 0.657
+graphic: 0.650
+arm: 0.591
+hypervisor: 0.535
+mistranslation: 0.313
+register: 0.292
+semantic: 0.290
+permissions: 0.268
+user-level: 0.232
+files: 0.194
+boot: 0.151
+virtual: 0.150
+PID: 0.120
+vnc: 0.083
+kernel: 0.083
+VMM: 0.078
+assembly: 0.070
+socket: 0.065
+risc-v: 0.042
+TCG: 0.035
+x86: 0.035
+i386: 0.007
+KVM: 0.003
+
+AIX 5 not working with qemu-system-ppc64
diff --git a/results/classifier/118/device/1133 b/results/classifier/118/device/1133
new file mode 100644
index 00000000..1b9c7e78
--- /dev/null
+++ b/results/classifier/118/device/1133
@@ -0,0 +1,40 @@
+device: 0.877
+debug: 0.622
+graphic: 0.592
+performance: 0.556
+register: 0.532
+ppc: 0.454
+socket: 0.410
+vnc: 0.376
+files: 0.364
+boot: 0.347
+network: 0.338
+semantic: 0.334
+mistranslation: 0.288
+risc-v: 0.247
+user-level: 0.244
+VMM: 0.229
+PID: 0.215
+architecture: 0.215
+permissions: 0.171
+peripherals: 0.145
+arm: 0.122
+virtual: 0.119
+assembly: 0.118
+TCG: 0.107
+i386: 0.090
+kernel: 0.019
+hypervisor: 0.012
+KVM: 0.005
+x86: 0.003
+
+unused memory filled with 0x00 instead of 0xFF
+Description of problem:
+Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem?
+
+Refer to
+https://bugs.launchpad.net/qemu/+bug/1180923
+Steps to reproduce:
+1.
+2.
+3.
diff --git a/results/classifier/118/device/1134 b/results/classifier/118/device/1134
new file mode 100644
index 00000000..a0ca5446
--- /dev/null
+++ b/results/classifier/118/device/1134
@@ -0,0 +1,33 @@
+device: 0.936
+mistranslation: 0.750
+peripherals: 0.740
+semantic: 0.554
+graphic: 0.418
+boot: 0.293
+performance: 0.233
+permissions: 0.165
+register: 0.157
+debug: 0.152
+vnc: 0.106
+virtual: 0.085
+ppc: 0.084
+network: 0.083
+architecture: 0.068
+arm: 0.060
+user-level: 0.040
+files: 0.037
+assembly: 0.032
+risc-v: 0.027
+VMM: 0.027
+i386: 0.017
+x86: 0.013
+socket: 0.009
+TCG: 0.008
+hypervisor: 0.008
+PID: 0.007
+kernel: 0.006
+KVM: 0.001
+
+Make ivshmem more generic not only a PCI device
+Additional information:
+It will also benefit from making it more portable, see https://gitlab.com/qemu-project/qemu/-/issues/666
diff --git a/results/classifier/118/device/1140 b/results/classifier/118/device/1140
new file mode 100644
index 00000000..66a372aa
--- /dev/null
+++ b/results/classifier/118/device/1140
@@ -0,0 +1,31 @@
+architecture: 0.971
+device: 0.952
+performance: 0.944
+graphic: 0.853
+arm: 0.840
+permissions: 0.603
+risc-v: 0.568
+ppc: 0.449
+semantic: 0.384
+debug: 0.358
+PID: 0.305
+mistranslation: 0.291
+user-level: 0.285
+TCG: 0.253
+boot: 0.217
+VMM: 0.208
+vnc: 0.189
+register: 0.181
+hypervisor: 0.161
+virtual: 0.106
+assembly: 0.034
+network: 0.016
+files: 0.011
+kernel: 0.002
+i386: 0.001
+socket: 0.001
+KVM: 0.001
+x86: 0.001
+peripherals: 0.000
+
+High CPU usage on AMD after migrating guests
diff --git a/results/classifier/118/device/1142 b/results/classifier/118/device/1142
new file mode 100644
index 00000000..19990a0c
--- /dev/null
+++ b/results/classifier/118/device/1142
@@ -0,0 +1,76 @@
+device: 0.885
+boot: 0.849
+kernel: 0.825
+i386: 0.805
+files: 0.803
+ppc: 0.795
+socket: 0.793
+architecture: 0.758
+graphic: 0.745
+register: 0.740
+vnc: 0.704
+performance: 0.703
+permissions: 0.681
+PID: 0.655
+risc-v: 0.626
+network: 0.618
+semantic: 0.577
+debug: 0.519
+hypervisor: 0.516
+KVM: 0.504
+arm: 0.500
+virtual: 0.498
+VMM: 0.487
+TCG: 0.469
+mistranslation: 0.441
+peripherals: 0.408
+x86: 0.404
+assembly: 0.398
+user-level: 0.216
+
+Measurements fail with direct kernel boot for AMD SEV confidential virtualization with 7.1 machine type
+Description of problem:
+When booting the QEMU with the 'kernel-hashes:true' property set for 'sev-guest' confidential virtualization, the contents of the `-kernel` file are measured by the firmware.
+
+A remote tenant can then validate the measurement against its expected contents to see if the boot was trustworthy.
+
+With the pc-q35-7.1 machine type the measurement always fails to validate against expected state.
+
+Making the following code change 
+
+```
+diff --git a/hw/i386/pc.c b/hw/i386/pc.c
+index 7280c02ce3..3a4bf5cba3 100644
+--- a/hw/i386/pc.c
++++ b/hw/i386/pc.c
+@@ -1899,6 +1899,8 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
+     pcmc->rsdp_in_ram = true;
+     pcmc->smbios_defaults = true;
+     pcmc->smbios_uuid_encoded = true;
++    pcmc->legacy_no_rng_seed = true;
++
+     pcmc->gigabyte_align = true;
+     pcmc->has_reserved_memory = true;
+     pcmc->kvmclock_enabled = true;
+```
+
+results in successfully validating the measurement.
+
+THis is not surprising, the RNG seed patch introduced in 
+
+```
+commit 67f7e426e53833a5db75b0d813e8d537b8a75bd2
+Author: Jason A. Donenfeld <Jason@zx2c4.com>
+Date:   Thu Jul 21 14:56:36 2022 +0200
+
+    hw/i386: pass RNG seed via setup_data entry
+```
+
+intentionally modifies the contents of the kernel image before passing it to the firmware, to inject a random seed. This will ensure the boot measuremnts are different every time.
+
+This RNG seed functionality must NOT be used when AMD SEV is active.
+Steps to reproduce:
+1. Create an AMD SEV guest with kernel-hashes=true and pc-q35-7.1 machine type
+2. Attempt to validate the boot measurement
+Additional information:
+
diff --git a/results/classifier/118/device/115 b/results/classifier/118/device/115
new file mode 100644
index 00000000..28abdc17
--- /dev/null
+++ b/results/classifier/118/device/115
@@ -0,0 +1,31 @@
+device: 0.845
+performance: 0.781
+network: 0.733
+arm: 0.729
+architecture: 0.566
+graphic: 0.543
+risc-v: 0.495
+debug: 0.462
+files: 0.441
+VMM: 0.439
+ppc: 0.433
+TCG: 0.361
+boot: 0.347
+PID: 0.341
+register: 0.339
+peripherals: 0.335
+mistranslation: 0.255
+vnc: 0.248
+kernel: 0.232
+permissions: 0.224
+socket: 0.194
+assembly: 0.192
+semantic: 0.176
+virtual: 0.164
+hypervisor: 0.148
+x86: 0.097
+KVM: 0.073
+user-level: 0.059
+i386: 0.047
+
+shmat fails on 32-to-64 setup
diff --git a/results/classifier/118/device/1155677 b/results/classifier/118/device/1155677
new file mode 100644
index 00000000..10360955
--- /dev/null
+++ b/results/classifier/118/device/1155677
@@ -0,0 +1,57 @@
+device: 0.816
+graphic: 0.723
+x86: 0.692
+performance: 0.635
+architecture: 0.615
+peripherals: 0.595
+semantic: 0.577
+network: 0.576
+debug: 0.508
+mistranslation: 0.457
+register: 0.456
+PID: 0.455
+virtual: 0.444
+kernel: 0.433
+boot: 0.428
+permissions: 0.417
+hypervisor: 0.415
+user-level: 0.373
+ppc: 0.369
+socket: 0.331
+vnc: 0.313
+arm: 0.306
+i386: 0.298
+VMM: 0.213
+risc-v: 0.202
+assembly: 0.185
+TCG: 0.164
+KVM: 0.087
+files: 0.041
+
+snapshot=on fails with non file-based storage
+
+The snapshot=on option doesn't work with an nbd block device:
+
+/usr/bin/qemu-system-x86_64 \
+[...]
+    -device virtio-scsi-pci,id=scsi \
+    -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none \
+    -device scsi-hd,drive=hd0 \
+[...]
+
+gives the error:
+
+qemu-system-x86_64: -drive file=nbd:localhost:61930,snapshot=on,format=raw,id=hd0,if=none: could not open disk image nbd:localhost:61930: No such file or directory
+
+If you remove the snapshot=on flag, it works (although that of course means that the block device is writable which we don't want).
+
+Previously reported here:
+
+  http://permalink.gmane.org/gmane.comp.emulators.qemu/148390
+
+and I can confirm this still happens in qemu 1.4.0.
+
+Triaging old bug tickets... I think this has likely been fixed in 2013 ... or can you still reproduce this issue with the latest version of QEMU? Could we close this ticket nowadays?
+
+Let's close this.  libguestfs doesn't use snapshot=on any longer.
+
diff --git a/results/classifier/118/device/116 b/results/classifier/118/device/116
new file mode 100644
index 00000000..4cbe74ad
--- /dev/null
+++ b/results/classifier/118/device/116
@@ -0,0 +1,31 @@
+device: 0.929
+architecture: 0.757
+performance: 0.742
+graphic: 0.627
+network: 0.522
+debug: 0.457
+peripherals: 0.456
+arm: 0.380
+boot: 0.355
+semantic: 0.224
+permissions: 0.223
+user-level: 0.132
+mistranslation: 0.130
+register: 0.106
+PID: 0.089
+kernel: 0.087
+socket: 0.078
+risc-v: 0.076
+ppc: 0.061
+virtual: 0.059
+TCG: 0.054
+hypervisor: 0.053
+vnc: 0.040
+VMM: 0.038
+i386: 0.022
+assembly: 0.021
+files: 0.020
+x86: 0.005
+KVM: 0.001
+
+qemu fails under NeXTStep 3.3 when accessing ROM in SCSI-Adapter am53c974
diff --git a/results/classifier/118/device/117 b/results/classifier/118/device/117
new file mode 100644
index 00000000..10b2fd60
--- /dev/null
+++ b/results/classifier/118/device/117
@@ -0,0 +1,31 @@
+device: 0.808
+network: 0.765
+architecture: 0.683
+files: 0.652
+vnc: 0.551
+arm: 0.527
+boot: 0.512
+TCG: 0.482
+kernel: 0.457
+VMM: 0.341
+risc-v: 0.318
+debug: 0.309
+graphic: 0.276
+PID: 0.253
+performance: 0.246
+register: 0.200
+semantic: 0.148
+permissions: 0.147
+ppc: 0.101
+socket: 0.077
+mistranslation: 0.067
+KVM: 0.046
+virtual: 0.023
+i386: 0.019
+x86: 0.009
+user-level: 0.008
+peripherals: 0.008
+assembly: 0.005
+hypervisor: 0.001
+
+nested 9p filesystem with security_model=mapped-xattr
diff --git a/results/classifier/118/device/1171 b/results/classifier/118/device/1171
new file mode 100644
index 00000000..24416193
--- /dev/null
+++ b/results/classifier/118/device/1171
@@ -0,0 +1,33 @@
+device: 0.893
+network: 0.707
+i386: 0.533
+graphic: 0.528
+x86: 0.509
+hypervisor: 0.429
+architecture: 0.391
+boot: 0.357
+semantic: 0.293
+PID: 0.237
+virtual: 0.234
+ppc: 0.210
+debug: 0.192
+peripherals: 0.157
+register: 0.151
+socket: 0.150
+mistranslation: 0.096
+user-level: 0.088
+vnc: 0.086
+files: 0.066
+performance: 0.063
+assembly: 0.060
+VMM: 0.055
+permissions: 0.051
+TCG: 0.045
+risc-v: 0.043
+arm: 0.010
+kernel: 0.005
+KVM: 0.003
+
+tulip: DMA reentrancy issue leads to stack overflow (CVE-2022-2962)
+Description of problem:
+A DMA reentrancy issue was found in the tulip emulation. When tulip reads or writes to  rx/tx descriptor ( tulip_desc_read/write ) or copies  rx/tx frame(tulip_copy_rx_bytes / tulip_copy_tx_buffers), it doesn't check whether the destination address is its own MMIO address. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host.
diff --git a/results/classifier/118/device/118 b/results/classifier/118/device/118
new file mode 100644
index 00000000..4f6ced4a
--- /dev/null
+++ b/results/classifier/118/device/118
@@ -0,0 +1,31 @@
+mistranslation: 0.966
+device: 0.938
+peripherals: 0.928
+debug: 0.816
+network: 0.706
+performance: 0.663
+architecture: 0.662
+arm: 0.659
+socket: 0.648
+boot: 0.551
+graphic: 0.524
+risc-v: 0.519
+register: 0.383
+VMM: 0.370
+vnc: 0.327
+ppc: 0.324
+permissions: 0.322
+TCG: 0.316
+PID: 0.312
+virtual: 0.247
+semantic: 0.214
+kernel: 0.154
+user-level: 0.082
+files: 0.060
+assembly: 0.056
+i386: 0.055
+KVM: 0.040
+hypervisor: 0.032
+x86: 0.006
+
+USB device 1.1 not correctly passedthru from Linux host to Windows guest
diff --git a/results/classifier/118/device/1181354 b/results/classifier/118/device/1181354
new file mode 100644
index 00000000..061bdfd7
--- /dev/null
+++ b/results/classifier/118/device/1181354
@@ -0,0 +1,40 @@
+device: 0.815
+architecture: 0.728
+graphic: 0.725
+performance: 0.721
+vnc: 0.648
+debug: 0.598
+ppc: 0.551
+user-level: 0.532
+semantic: 0.522
+risc-v: 0.515
+network: 0.499
+boot: 0.440
+socket: 0.438
+files: 0.414
+PID: 0.409
+register: 0.408
+arm: 0.392
+peripherals: 0.258
+permissions: 0.241
+VMM: 0.240
+kernel: 0.191
+mistranslation: 0.172
+TCG: 0.158
+virtual: 0.136
+i386: 0.125
+x86: 0.077
+hypervisor: 0.072
+assembly: 0.030
+KVM: 0.005
+
+assert failed in scsi-bus.c line 1539 in SCSI_XFER_NONE
+
+Every time I format a SCSI hard disk (on ID 0) with Windows NT or DOS, QEMU crashes with an assertion failure on scsi-bus.c, any help?
+
+this happens from 1.3.0 to the latest git release.
+
+Does this problem still occur with the latest version of QEMU (currently it's 2.7.0)? If so, can you please post the exact assertion message, and if possible a stack trace (taken with gdb)? Thanks!
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1187 b/results/classifier/118/device/1187
new file mode 100644
index 00000000..fc1b55b3
--- /dev/null
+++ b/results/classifier/118/device/1187
@@ -0,0 +1,31 @@
+device: 0.862
+performance: 0.823
+network: 0.743
+architecture: 0.617
+kernel: 0.559
+arm: 0.450
+user-level: 0.421
+TCG: 0.398
+risc-v: 0.393
+graphic: 0.370
+peripherals: 0.357
+ppc: 0.349
+VMM: 0.339
+vnc: 0.335
+semantic: 0.275
+mistranslation: 0.242
+register: 0.203
+boot: 0.203
+permissions: 0.195
+debug: 0.191
+PID: 0.179
+files: 0.151
+socket: 0.132
+KVM: 0.070
+hypervisor: 0.054
+virtual: 0.052
+assembly: 0.030
+i386: 0.020
+x86: 0.003
+
+can not handler real-time signal (signal number > 30) by sigqueue on linux user mode
diff --git a/results/classifier/118/device/1187529 b/results/classifier/118/device/1187529
new file mode 100644
index 00000000..ed81c897
--- /dev/null
+++ b/results/classifier/118/device/1187529
@@ -0,0 +1,47 @@
+device: 0.915
+KVM: 0.892
+peripherals: 0.859
+x86: 0.847
+graphic: 0.703
+vnc: 0.668
+architecture: 0.636
+ppc: 0.573
+performance: 0.572
+semantic: 0.445
+network: 0.416
+mistranslation: 0.404
+boot: 0.377
+PID: 0.343
+socket: 0.336
+files: 0.308
+register: 0.293
+virtual: 0.251
+permissions: 0.246
+kernel: 0.243
+i386: 0.232
+hypervisor: 0.217
+risc-v: 0.186
+TCG: 0.185
+assembly: 0.171
+VMM: 0.171
+user-level: 0.153
+arm: 0.105
+debug: 0.102
+
+Devices on PCI bridge stop working when live-migrated
+
+qemu version: 1.4.50 (0ca5aa4f4c4a8bcc73988dd52a536241d35e5223)
+host: x86_64, Linux 3.6.10 (Fedora 17)
+client: x86_64 Centos 6.3 (doesn't matter, really)
+
+If a device, e.g. an lsi53c895a, is on a pci-bridge, after migration, the device stops working (e.g., commands like "poweroff"
+get an Input/Output error. Fails under either xen or kvm. If "top" was running, some cpus go to ~100% wait.
+
+Sample KVM invocation line:
+qemu-system-x86_64 -machine type=pc,accel=kvm -m 4096 -device pci-bridgemsi=on,chassis_nr=1,id=pciBridge1.0,addr=0x11.0 -device lsi53c895a,id=sas,bus=pciBridge1.0,addr=0x1.0x0 -drive if=none,id=disk0,file=/path/to/disk/image -device scsi-disk,bus=sas.0,scsi-id=0,drive=disk0 -vnc 127.0.0.1:0,to=99 -serial pty -boot order=cda -smp 4,maxcpus=4 -monitor vc
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/119 b/results/classifier/118/device/119
new file mode 100644
index 00000000..596e964c
--- /dev/null
+++ b/results/classifier/118/device/119
@@ -0,0 +1,31 @@
+device: 0.926
+mistranslation: 0.806
+performance: 0.696
+semantic: 0.627
+graphic: 0.565
+architecture: 0.495
+hypervisor: 0.415
+user-level: 0.339
+permissions: 0.220
+network: 0.219
+peripherals: 0.140
+boot: 0.137
+assembly: 0.134
+socket: 0.122
+debug: 0.109
+virtual: 0.074
+register: 0.064
+arm: 0.057
+TCG: 0.043
+VMM: 0.037
+PID: 0.034
+i386: 0.031
+files: 0.029
+ppc: 0.029
+vnc: 0.022
+x86: 0.017
+KVM: 0.013
+kernel: 0.010
+risc-v: 0.008
+
+USB assert failure on hcd-uhci.c
diff --git a/results/classifier/118/device/1191 b/results/classifier/118/device/1191
new file mode 100644
index 00000000..ff2c76da
--- /dev/null
+++ b/results/classifier/118/device/1191
@@ -0,0 +1,39 @@
+device: 0.930
+graphic: 0.867
+boot: 0.835
+performance: 0.685
+mistranslation: 0.667
+debug: 0.469
+arm: 0.464
+semantic: 0.446
+register: 0.417
+PID: 0.410
+risc-v: 0.359
+vnc: 0.279
+ppc: 0.272
+socket: 0.266
+permissions: 0.245
+kernel: 0.166
+files: 0.148
+TCG: 0.145
+network: 0.144
+architecture: 0.142
+VMM: 0.099
+i386: 0.089
+x86: 0.078
+KVM: 0.070
+hypervisor: 0.062
+peripherals: 0.058
+user-level: 0.054
+virtual: 0.052
+assembly: 0.010
+
+AC97+CoreAudio no audio when out frequency not 44,1KHz & always forces host to use 44,1KHz (or less if frequency not supported)
+Description of problem:
+AC97+CoreAudio outputs no audio when output frequency not 44,1KHz. Also always forces host to use 44,1KHz (or less if frequency not supported on host output)
+Steps to reproduce:
+1. Boot any OS with (only) AC97 audio on macOS
+2. Attempt to play audio with output frequency in guest set to 48KHz
+3. Observe lack of output
+Additional information:
+I'm using QEMU to test a Custom OS written by me, but this shouldn't be a code issue on our side, rather an issue with QEMU itself, if this is mistaken, please inform us.
diff --git a/results/classifier/118/device/1196 b/results/classifier/118/device/1196
new file mode 100644
index 00000000..2979716c
--- /dev/null
+++ b/results/classifier/118/device/1196
@@ -0,0 +1,42 @@
+device: 0.882
+graphic: 0.870
+ppc: 0.828
+vnc: 0.763
+network: 0.676
+PID: 0.675
+risc-v: 0.630
+peripherals: 0.595
+VMM: 0.561
+performance: 0.559
+register: 0.490
+boot: 0.444
+TCG: 0.416
+semantic: 0.416
+arm: 0.399
+socket: 0.384
+kernel: 0.355
+debug: 0.332
+hypervisor: 0.318
+KVM: 0.297
+mistranslation: 0.292
+files: 0.271
+architecture: 0.264
+i386: 0.257
+permissions: 0.250
+x86: 0.155
+virtual: 0.094
+assembly: 0.083
+user-level: 0.050
+
+Guest could not enable pci AtomicOp requests for passthrough device
+Description of problem:
+Guest could not enable pci AtomicOp requests for passthrough device. 
+
+sudo setpci -v -d *:706t 8c.b=40 // enable pci AtomicOp requests bit in the guest os.
+
+Host could not see the bit by command "sudo lspci -vvv -s 03:00.0".
+Steps to reproduce:
+1. sudo setpci -v -d *:706t 8c.b=40 // in the guest os
+2. sudo lspci -vvv -s 03:00.0 // in the host os
+Additional information:
+
diff --git a/results/classifier/118/device/1198350 b/results/classifier/118/device/1198350
new file mode 100644
index 00000000..11e8fd22
--- /dev/null
+++ b/results/classifier/118/device/1198350
@@ -0,0 +1,82 @@
+device: 0.943
+boot: 0.911
+kernel: 0.878
+user-level: 0.876
+graphic: 0.861
+virtual: 0.857
+socket: 0.835
+semantic: 0.830
+architecture: 0.828
+peripherals: 0.827
+mistranslation: 0.824
+PID: 0.815
+VMM: 0.802
+network: 0.798
+i386: 0.797
+files: 0.793
+hypervisor: 0.766
+assembly: 0.762
+performance: 0.760
+register: 0.759
+vnc: 0.746
+debug: 0.714
+permissions: 0.711
+ppc: 0.675
+x86: 0.646
+arm: 0.591
+risc-v: 0.555
+KVM: 0.510
+TCG: 0.491
+
+USB pass-through fails with USBDEVFS_DISCONNECT: Invalid argument
+
+Host Gentoo linux 32bit
+Guest Windows XP SP3
+qemu 1.4.2 and
+qemu fresh get clone and build 2013-07-04 (version1.5.50)
+qemu command line
+
+qemu-system-i386 -enable-kvm localtime -m 2047 -boot d /archive3/qemu/WindowsXP.img -net nic,model=rtl8139 -net user -usb -device usb-ehci,id=ehci -usbdevice host:1493:19
+
+The device I am trying to use with the guest is an interface for the Suunto Ambit 2 GPS watch which has no linux support.
+
+When the USB device is plugged in qemu reports to the command line:
+
+USBDEVFS_DISCONNECT: Invalid argument
+Invalid argument
+
+dmesg shows
+
+[237755.495968] usb 2-1.5: new full-speed USB device number 34 using ehci-pci
+[237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0
+[237755.582781] usb 2-1.5: config 1 has no interface number 0
+[237755.583628] usb 2-1.5: New USB device found, idVendor=1493, idProduct=0019
+[237755.583631] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
+[237755.583633] usb 2-1.5: Product: Ambit
+[237755.583634] usb 2-1.5: Manufacturer: Suunto
+[237755.583636] usb 2-1.5: SerialNumber: CE83095110000700
+[237756.584937] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci
+[237756.832658] usb 2-1.5: reset full-speed USB device number 34 using ehci-pci
+[237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use
+
+In the windows guest Device Manager a HID device is listed but nothing else happens, no found new hardware dialog or the Suunto software (which is sitting there waiting) is not triggered as it should be.
+
+I have tried successfully with several other devices (flash drive, mouse, printer and video capture device). Because this device pretends to be an HID device my kernel's hid-generic driver was picking it up first until I modified hid-core.c to ignore this vendorid/productid. But still no joy.
+
+I'm guessing it has something to do with the the dmesg lines:
+
+[237755.582778] usb 2-1.5: config 1 has an invalid interface number: 1 but max is 0
+[237755.582781] usb 2-1.5: config 1 has no interface number 0
+
+But read that these warnings are not important though I don't get them for other devices. Nor do I get:
+
+[237757.143585] usb 2-1.5: usbfs: process 12684 (qemu-system-i38) did not claim interface 1 before use
+
+I've done alot of searching and I've run out of ideas. Any help would be great.
+
+I also have this issue. Does anyone have a work around? (it works with Virtual Box)
+
+Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU (currently v2.9)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1208 b/results/classifier/118/device/1208
new file mode 100644
index 00000000..e1149079
--- /dev/null
+++ b/results/classifier/118/device/1208
@@ -0,0 +1,39 @@
+device: 0.953
+ppc: 0.923
+semantic: 0.649
+graphic: 0.544
+PID: 0.414
+register: 0.393
+arm: 0.300
+files: 0.299
+boot: 0.296
+mistranslation: 0.286
+architecture: 0.278
+debug: 0.222
+performance: 0.148
+VMM: 0.141
+vnc: 0.133
+socket: 0.131
+peripherals: 0.126
+virtual: 0.118
+user-level: 0.110
+permissions: 0.102
+network: 0.075
+assembly: 0.044
+TCG: 0.037
+i386: 0.036
+risc-v: 0.031
+kernel: 0.015
+x86: 0.006
+hypervisor: 0.003
+KVM: 0.001
+
+Raspberry Pi 4 Model B
+Additional information:
+There have been some attempts at implementing this a few years ago: see:
+* https://gitlab.com/philmd/qemu/-/tree/raspi4_wip
+* https://github.com/0xMirasio/qemu-patch-raspberry4
+
+
+
+Thanks!
diff --git a/results/classifier/118/device/1210 b/results/classifier/118/device/1210
new file mode 100644
index 00000000..aac64918
--- /dev/null
+++ b/results/classifier/118/device/1210
@@ -0,0 +1,38 @@
+device: 0.859
+graphic: 0.816
+performance: 0.667
+files: 0.644
+semantic: 0.605
+network: 0.536
+debug: 0.464
+architecture: 0.436
+permissions: 0.316
+boot: 0.311
+ppc: 0.226
+peripherals: 0.224
+arm: 0.211
+user-level: 0.198
+mistranslation: 0.195
+PID: 0.176
+hypervisor: 0.169
+risc-v: 0.135
+vnc: 0.097
+i386: 0.093
+kernel: 0.091
+virtual: 0.076
+TCG: 0.069
+VMM: 0.066
+socket: 0.059
+x86: 0.057
+register: 0.043
+KVM: 0.034
+assembly: 0.005
+
+qemu segfaults on PNG screendump
+Description of problem:
+Attempting to produce a screendump via the monitor in the PNG format leads to a segmentation fault (but the screen dump is produced correctly).
+Steps to reproduce:
+1. Launch QEMU
+2. Go to the monitoring screen ()
+3. execute the command: `screendump /tmp/dump.png -f png`
+4. observe the crash (segfault)
diff --git a/results/classifier/118/device/1211 b/results/classifier/118/device/1211
new file mode 100644
index 00000000..25de8c90
--- /dev/null
+++ b/results/classifier/118/device/1211
@@ -0,0 +1,37 @@
+device: 0.854
+graphic: 0.562
+risc-v: 0.527
+peripherals: 0.379
+debug: 0.375
+boot: 0.229
+semantic: 0.184
+user-level: 0.136
+PID: 0.109
+arm: 0.100
+files: 0.089
+register: 0.077
+x86: 0.057
+architecture: 0.045
+vnc: 0.038
+network: 0.029
+mistranslation: 0.024
+performance: 0.022
+ppc: 0.021
+i386: 0.019
+socket: 0.018
+assembly: 0.012
+virtual: 0.012
+permissions: 0.012
+kernel: 0.011
+KVM: 0.010
+VMM: 0.009
+hypervisor: 0.007
+TCG: 0.006
+
+Bad fonts in "cirrus" VGA card.
+Description of problem:
+Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file.
+Steps to reproduce:
+Similar to #988.
+Additional information:
+
diff --git a/results/classifier/118/device/1221 b/results/classifier/118/device/1221
new file mode 100644
index 00000000..5266c193
--- /dev/null
+++ b/results/classifier/118/device/1221
@@ -0,0 +1,59 @@
+device: 0.965
+network: 0.907
+hypervisor: 0.899
+performance: 0.891
+architecture: 0.890
+ppc: 0.879
+kernel: 0.876
+files: 0.866
+mistranslation: 0.862
+KVM: 0.861
+vnc: 0.858
+x86: 0.852
+PID: 0.852
+virtual: 0.841
+peripherals: 0.827
+assembly: 0.826
+VMM: 0.824
+socket: 0.816
+risc-v: 0.805
+TCG: 0.798
+register: 0.788
+permissions: 0.771
+i386: 0.769
+semantic: 0.757
+graphic: 0.748
+arm: 0.691
+debug: 0.605
+boot: 0.577
+user-level: 0.311
+
+qga return "frozen" when vm just been created from snapfile
+Steps to reproduce:
+1. virsh create lisa.xml  
+Domain lisa created from lisa.xml
+
+2. virsh domblklist lisa  
+ vda      /mnt/a/b/srv.qcow2
+
+3. virsh snapshot-create-as lisa  --disk-only --diskspec vda,file=/tmp/f1,snapfile=/tmp/sp1  --no-metadata --quiesce  
+Domain snapshot 20220919165217 created
+
+4. virsh shutdown lisa  
+Domain lisa is being shutdown
+
+5. modify lisa.xml: replace /mnt/a/b/srv/qcow2 with /tmp/sp1
+
+6. virsh create lisa.xml  
+Domain lisa created from lisa.xml
+
+7. virsh domblklist lisa  
+ vda      /tmp/sp1
+ 
+8. virsh qemu-agent-command lisa '{"execute":"guest-fsfreeze-status"}'  
+{"return":"frozen"}
+
+9. virsh snapshot-create-as lisa  --disk-only --diskspec vda,file=/tmp/f2,snapfile=/tmp/sp2  --no-metadata --quiesce  
+error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': The command guest-fsfreeze-freeze has been disabled for this instance
+Additional information:
+Is "frozen" a normal value in step8? If not, what's the best way to avoid this?
diff --git a/results/classifier/118/device/1225 b/results/classifier/118/device/1225
new file mode 100644
index 00000000..452d4ae7
--- /dev/null
+++ b/results/classifier/118/device/1225
@@ -0,0 +1,31 @@
+device: 0.950
+performance: 0.783
+architecture: 0.760
+mistranslation: 0.714
+network: 0.677
+socket: 0.665
+user-level: 0.661
+files: 0.652
+semantic: 0.648
+risc-v: 0.648
+register: 0.645
+arm: 0.619
+debug: 0.612
+peripherals: 0.577
+graphic: 0.563
+ppc: 0.540
+permissions: 0.537
+PID: 0.451
+vnc: 0.440
+hypervisor: 0.406
+assembly: 0.397
+VMM: 0.391
+virtual: 0.380
+TCG: 0.321
+kernel: 0.273
+boot: 0.172
+KVM: 0.078
+i386: 0.064
+x86: 0.047
+
+Can't update to Windows 11 22H2
diff --git a/results/classifier/118/device/1226 b/results/classifier/118/device/1226
new file mode 100644
index 00000000..677f1819
--- /dev/null
+++ b/results/classifier/118/device/1226
@@ -0,0 +1,55 @@
+device: 0.847
+graphic: 0.818
+boot: 0.697
+PID: 0.620
+files: 0.513
+ppc: 0.397
+peripherals: 0.345
+performance: 0.339
+virtual: 0.335
+architecture: 0.327
+semantic: 0.325
+socket: 0.252
+risc-v: 0.227
+hypervisor: 0.207
+vnc: 0.206
+kernel: 0.205
+mistranslation: 0.168
+register: 0.160
+TCG: 0.152
+x86: 0.148
+debug: 0.148
+VMM: 0.125
+arm: 0.123
+KVM: 0.096
+assembly: 0.085
+network: 0.081
+i386: 0.080
+user-level: 0.034
+permissions: 0.020
+
+wheel-axis=false does not get applied at hardware init stage
+Description of problem:
+`-device virtio-tablet,id=touch0,wheel-axis=false` does not get applied at initalization stage, causing android to see it and treat the device as a pointer instead of a tablet. it seems to look for the prop at init stage, I have verified that this is an issue by fixing it with a quick hack below. ~~setting `-device virtio-tablet,id=touch0,wheel-axis=true` will still work fine and cause android to pick it up as a pointer again~~
+
+
+EDIT: It does not seem to work actually. if set when the default is set to false
+Steps to reproduce:
+1. Boot android based VM
+2. test an app that forces touch only over pointer
+Additional information:
+```
+diff --git a/hw/input/virtio-input-hid.c b/hw/input/virtio-input-hid.c
+index a7a244a95d..3175f9c7d5 100644
+--- a/hw/input/virtio-input-hid.c
++++ b/hw/input/virtio-input-hid.c
+@@ -477,7 +477,7 @@ static struct virtio_input_config virtio_tablet_config_v2[] = {
+ };
+ 
+ static Property virtio_tablet_properties[] = {
+-    DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, true),
++    DEFINE_PROP_BOOL("wheel-axis", VirtIOInputHID, wheel_axis, false),
+     DEFINE_PROP_END_OF_LIST(),
+ };
+ 
+```
diff --git a/results/classifier/118/device/1230 b/results/classifier/118/device/1230
new file mode 100644
index 00000000..62a81fb1
--- /dev/null
+++ b/results/classifier/118/device/1230
@@ -0,0 +1,53 @@
+device: 0.859
+graphic: 0.786
+PID: 0.781
+architecture: 0.778
+socket: 0.765
+network: 0.747
+vnc: 0.746
+ppc: 0.742
+semantic: 0.732
+TCG: 0.729
+arm: 0.682
+VMM: 0.669
+performance: 0.659
+kernel: 0.652
+x86: 0.603
+files: 0.603
+register: 0.595
+permissions: 0.582
+i386: 0.566
+hypervisor: 0.554
+risc-v: 0.531
+mistranslation: 0.527
+debug: 0.509
+boot: 0.480
+KVM: 0.469
+peripherals: 0.431
+assembly: 0.366
+virtual: 0.319
+user-level: 0.236
+
+qtest-aarch64/migration-test non-deterministic test failure
+Description of problem:
+The test suite fails:
+```
+Summary of Failures:
+
+ 32/619 qemu:qtest+qtest-aarch64 / qtest-aarch64/migration-test                   ERROR          161.19s   killed by signal 6 SIGABRT
+
+
+Ok:                 552 
+Expected Fail:      0   
+Fail:               1   
+Unexpected Pass:    0   
+Skipped:            66  
+Timeout:            0   
+
+Full log written to /tmp/guix-build-qemu-7.1.0.drv-0/qemu-7.1.0/b/qemu/meson-logs/testlog.txt
+make: *** [Makefile.mtest:25: do-meson-check] Error 1
+```
+
+See the full build log below.
+Additional information:
+[qt60pm4fcc63jcbwfgz86z6cwqgx4zgm-qemu-7.1.0.txt.gz](/uploads/6d7f0da152193213a7fe694e2d535879/qt60pm4fcc63jcbwfgz86z6cwqgx4zgm-qemu-7.1.0.txt.gz)
diff --git a/results/classifier/118/device/1237 b/results/classifier/118/device/1237
new file mode 100644
index 00000000..a282e0d9
--- /dev/null
+++ b/results/classifier/118/device/1237
@@ -0,0 +1,31 @@
+device: 0.934
+KVM: 0.898
+performance: 0.787
+network: 0.663
+debug: 0.640
+peripherals: 0.553
+graphic: 0.549
+VMM: 0.430
+arm: 0.411
+PID: 0.400
+kernel: 0.351
+i386: 0.294
+ppc: 0.271
+x86: 0.269
+semantic: 0.244
+register: 0.241
+TCG: 0.236
+boot: 0.230
+mistranslation: 0.195
+vnc: 0.157
+permissions: 0.123
+risc-v: 0.121
+files: 0.099
+architecture: 0.039
+socket: 0.038
+virtual: 0.033
+user-level: 0.027
+hypervisor: 0.026
+assembly: 0.009
+
+after OS upgrade usb-redir connection broken during migration and qemu-kvm: terminating on signal 15
diff --git a/results/classifier/118/device/1244 b/results/classifier/118/device/1244
new file mode 100644
index 00000000..4b4518f6
--- /dev/null
+++ b/results/classifier/118/device/1244
@@ -0,0 +1,75 @@
+device: 0.910
+debug: 0.908
+graphic: 0.907
+vnc: 0.877
+PID: 0.864
+architecture: 0.839
+arm: 0.835
+files: 0.834
+socket: 0.826
+network: 0.813
+TCG: 0.768
+ppc: 0.767
+register: 0.765
+assembly: 0.737
+i386: 0.722
+VMM: 0.697
+peripherals: 0.691
+semantic: 0.646
+risc-v: 0.604
+permissions: 0.599
+performance: 0.592
+virtual: 0.584
+hypervisor: 0.534
+x86: 0.511
+boot: 0.467
+user-level: 0.467
+kernel: 0.352
+mistranslation: 0.317
+KVM: 0.062
+
+macOS 12.x ld: warning: -undefined dynamic_lookup may not work with chained fixups
+Description of problem:
+Not sure if this is a serious or negligible problem and if it has any significant runtime implications but reporting it anyway:
+
+```
+$ ld -v
+@(#)PROGRAM:ld  PROJECT:ld64-819.6
+BUILD 14:58:44 Aug  5 2022
+configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
+LTO support using: LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29, runtime is 29)
+TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11)
+
+$ ninja -C build
+ninja: Entering directory `build'
+[314/2946] Linking static target libevent-loop-base.a
+warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: libevent-loop-base.a the table of contents is empty (no object file members in the library define global symbols)
+[2044/2946] Generating qemu-system-aarch64 with a custom command
+qemu-system-aarch64.tmp: replacing existing signature
+[2584/2946] Linking target tests/plugin/libempty.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2585/2946] Linking target tests/plugin/libbb.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2588/2946] Linking target tests/plugin/libinsn.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2589/2946] Linking target tests/plugin/libmem.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2592/2946] Linking target tests/plugin/libsyscall.dylib
+ld: warning: -undefined dynamic_lookup may not work with chained fixups
+[2946/2946] Linking target tests/qtest/test-arm-mptimer
+```
+
+I saw a similar discussions in Bazel building system, CPython, and Ruby:
+- https://github.com/bazelbuild/bazel/issues/16413
+- https://github.com/python/cpython/issues/97524
+- https://github.com/ruby/ruby/pull/6193
+- https://issues.guix.gnu.org/issue/57849
+Steps to reproduce:
+1. ` ./configure --target-list=aarch64-softmmu,arm-softmmu --enable-cocoa --enable-plugins` (note that target list is not that important in this case though)
+2. `ninja -C build`
+3. Observe the warnings
+Additional information:
+See "New Features" subsection under "Linking" section for chained fixup
+https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes for more information:
+
+> All programs and dylibs built with a deployment target of macOS 12 or iOS 15 or later now use the chained fixups format. This uses different load commands and LINKEDIT data, and won’t run or load on older OS versions. (49851380)
diff --git a/results/classifier/118/device/1246 b/results/classifier/118/device/1246
new file mode 100644
index 00000000..ef2553d9
--- /dev/null
+++ b/results/classifier/118/device/1246
@@ -0,0 +1,31 @@
+device: 0.894
+files: 0.839
+performance: 0.686
+network: 0.660
+kernel: 0.608
+mistranslation: 0.608
+VMM: 0.601
+semantic: 0.570
+arm: 0.543
+architecture: 0.523
+hypervisor: 0.513
+peripherals: 0.506
+graphic: 0.479
+TCG: 0.473
+register: 0.446
+permissions: 0.442
+vnc: 0.428
+ppc: 0.391
+socket: 0.386
+PID: 0.384
+user-level: 0.378
+risc-v: 0.359
+virtual: 0.357
+debug: 0.341
+boot: 0.291
+KVM: 0.242
+assembly: 0.197
+x86: 0.053
+i386: 0.010
+
+Win11_22H2_English_x64.iso won't boot
diff --git a/results/classifier/118/device/1248469 b/results/classifier/118/device/1248469
new file mode 100644
index 00000000..c43d4c0b
--- /dev/null
+++ b/results/classifier/118/device/1248469
@@ -0,0 +1,38 @@
+device: 0.957
+boot: 0.918
+architecture: 0.833
+performance: 0.794
+network: 0.715
+peripherals: 0.706
+graphic: 0.610
+permissions: 0.599
+socket: 0.588
+register: 0.481
+semantic: 0.436
+hypervisor: 0.427
+arm: 0.414
+files: 0.408
+kernel: 0.385
+debug: 0.345
+ppc: 0.344
+vnc: 0.314
+PID: 0.265
+mistranslation: 0.210
+VMM: 0.196
+user-level: 0.192
+risc-v: 0.158
+TCG: 0.119
+virtual: 0.098
+assembly: 0.082
+x86: 0.037
+KVM: 0.015
+i386: 0.008
+
+qemu 1.6.1 q35 ioh3420 not work in windows 7 32bit
+
+boot windows 7 32bit guest with -readconfig q35-chipset.cfg paramter,in guest's device manager,there's a device 3420 not work,it shows error "This device cannot find enough free resources that it can use(code 12)".
+
+Can you still reproduce this problem with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1256826 b/results/classifier/118/device/1256826
new file mode 100644
index 00000000..94f4ccb8
--- /dev/null
+++ b/results/classifier/118/device/1256826
@@ -0,0 +1,46 @@
+device: 0.836
+graphic: 0.816
+PID: 0.704
+semantic: 0.669
+architecture: 0.669
+performance: 0.621
+kernel: 0.591
+network: 0.548
+mistranslation: 0.505
+ppc: 0.495
+files: 0.478
+debug: 0.452
+vnc: 0.439
+boot: 0.415
+socket: 0.385
+peripherals: 0.356
+arm: 0.349
+virtual: 0.348
+user-level: 0.312
+risc-v: 0.283
+register: 0.283
+x86: 0.271
+VMM: 0.265
+hypervisor: 0.263
+KVM: 0.235
+permissions: 0.232
+TCG: 0.182
+assembly: 0.135
+i386: 0.090
+
+INT instruction bug in WindowsXP
+
+This bug is in -no-kvm mode.
+
+In windowsXP at IDT entry 2&8 is Task gate
+
+when application use INT 2 or INT 8 it will cause blue screen in XP.
+
+I found it should cause #GP not generate hw interrupt.
+
+also I check this bug with -enable-kvm and works correctly.
+
+Which QEMU version did you use here? Can you still reproduce this problem with the latest version of QEMU (currently 2.8)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1262 b/results/classifier/118/device/1262
new file mode 100644
index 00000000..503ec59f
--- /dev/null
+++ b/results/classifier/118/device/1262
@@ -0,0 +1,31 @@
+device: 0.817
+network: 0.766
+performance: 0.712
+graphic: 0.394
+boot: 0.342
+arm: 0.317
+architecture: 0.299
+semantic: 0.275
+vnc: 0.269
+debug: 0.269
+risc-v: 0.260
+permissions: 0.230
+ppc: 0.198
+hypervisor: 0.176
+mistranslation: 0.151
+register: 0.150
+VMM: 0.145
+TCG: 0.118
+kernel: 0.116
+PID: 0.106
+virtual: 0.101
+user-level: 0.083
+files: 0.075
+i386: 0.062
+x86: 0.047
+peripherals: 0.036
+assembly: 0.036
+socket: 0.020
+KVM: 0.003
+
+avocado test framework fails to report when QEMU exits unexpectedly
diff --git a/results/classifier/118/device/1266 b/results/classifier/118/device/1266
new file mode 100644
index 00000000..3a291c5e
--- /dev/null
+++ b/results/classifier/118/device/1266
@@ -0,0 +1,31 @@
+device: 0.890
+performance: 0.789
+architecture: 0.456
+arm: 0.428
+graphic: 0.398
+network: 0.362
+boot: 0.318
+semantic: 0.301
+ppc: 0.291
+VMM: 0.289
+hypervisor: 0.272
+permissions: 0.268
+TCG: 0.227
+debug: 0.224
+vnc: 0.219
+i386: 0.151
+register: 0.149
+peripherals: 0.130
+files: 0.103
+user-level: 0.098
+virtual: 0.089
+mistranslation: 0.079
+assembly: 0.076
+PID: 0.062
+risc-v: 0.057
+socket: 0.042
+x86: 0.028
+kernel: 0.028
+KVM: 0.024
+
+Assert in resettable_phase_enter through virtio-scsi
diff --git a/results/classifier/118/device/1273 b/results/classifier/118/device/1273
new file mode 100644
index 00000000..f333ce73
--- /dev/null
+++ b/results/classifier/118/device/1273
@@ -0,0 +1,31 @@
+device: 0.897
+debug: 0.589
+mistranslation: 0.355
+graphic: 0.318
+performance: 0.306
+network: 0.221
+hypervisor: 0.200
+ppc: 0.170
+vnc: 0.149
+user-level: 0.140
+i386: 0.138
+semantic: 0.129
+register: 0.111
+risc-v: 0.095
+arm: 0.083
+boot: 0.078
+virtual: 0.075
+architecture: 0.041
+permissions: 0.035
+peripherals: 0.035
+PID: 0.035
+socket: 0.029
+assembly: 0.017
+TCG: 0.008
+kernel: 0.007
+files: 0.007
+VMM: 0.006
+x86: 0.004
+KVM: 0.001
+
+QEMU log problem
diff --git a/results/classifier/118/device/1275 b/results/classifier/118/device/1275
new file mode 100644
index 00000000..88201c32
--- /dev/null
+++ b/results/classifier/118/device/1275
@@ -0,0 +1,39 @@
+device: 0.884
+graphic: 0.700
+performance: 0.613
+vnc: 0.535
+network: 0.535
+debug: 0.468
+arm: 0.467
+socket: 0.373
+architecture: 0.367
+VMM: 0.332
+PID: 0.329
+files: 0.264
+register: 0.243
+kernel: 0.236
+peripherals: 0.195
+semantic: 0.193
+virtual: 0.146
+risc-v: 0.140
+boot: 0.127
+mistranslation: 0.115
+TCG: 0.108
+ppc: 0.103
+user-level: 0.092
+permissions: 0.086
+hypervisor: 0.073
+x86: 0.060
+i386: 0.051
+assembly: 0.010
+KVM: 0.001
+
+javac command stuck forever in qemu vm which does not use hardware virtualization
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/118/device/1280521 b/results/classifier/118/device/1280521
new file mode 100644
index 00000000..d7b5b13f
--- /dev/null
+++ b/results/classifier/118/device/1280521
@@ -0,0 +1,38 @@
+device: 0.824
+boot: 0.753
+network: 0.748
+graphic: 0.675
+ppc: 0.671
+socket: 0.461
+mistranslation: 0.461
+register: 0.433
+performance: 0.418
+arm: 0.410
+semantic: 0.368
+risc-v: 0.344
+vnc: 0.343
+architecture: 0.297
+peripherals: 0.250
+user-level: 0.191
+permissions: 0.180
+debug: 0.135
+hypervisor: 0.135
+virtual: 0.094
+files: 0.071
+x86: 0.068
+kernel: 0.053
+i386: 0.047
+assembly: 0.036
+KVM: 0.035
+PID: 0.032
+TCG: 0.031
+VMM: 0.007
+
+Plan 9 can't use GUI well emulating a RTL8139 card
+
+The OS Plan 9 from Bell Labs runs fine in QEMU/KVM for the most part buy is unable to boot its GUI when emulating a RTL8139 WiFi card. I hear someone was able to get it working under a Windows XP host but I can't seem to do it under a Gentoo host. If you have any idea what may be doing this I would love to hear it.
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1282 b/results/classifier/118/device/1282
new file mode 100644
index 00000000..ccf880a7
--- /dev/null
+++ b/results/classifier/118/device/1282
@@ -0,0 +1,33 @@
+device: 0.962
+architecture: 0.927
+graphic: 0.866
+network: 0.855
+semantic: 0.545
+boot: 0.502
+socket: 0.476
+i386: 0.423
+debug: 0.375
+assembly: 0.365
+performance: 0.360
+x86: 0.291
+PID: 0.246
+ppc: 0.213
+files: 0.202
+VMM: 0.158
+risc-v: 0.129
+TCG: 0.118
+peripherals: 0.095
+register: 0.092
+permissions: 0.089
+user-level: 0.083
+virtual: 0.074
+vnc: 0.043
+mistranslation: 0.043
+kernel: 0.015
+arm: 0.014
+hypervisor: 0.005
+KVM: 0.003
+
+sdhci: DMA reentrancy issue leads to an infinite loop
+Description of problem:
+When sdhci transfers multiple blocks, it doesnot check if the dma-write buffer pointer overlaps with its MMIO region, crafted content can cause DoS because of infinite loop and CPU consumption.
diff --git a/results/classifier/118/device/1284 b/results/classifier/118/device/1284
new file mode 100644
index 00000000..048fc8be
--- /dev/null
+++ b/results/classifier/118/device/1284
@@ -0,0 +1,44 @@
+device: 0.946
+graphic: 0.919
+architecture: 0.623
+debug: 0.620
+semantic: 0.551
+peripherals: 0.530
+mistranslation: 0.428
+boot: 0.295
+arm: 0.281
+user-level: 0.279
+PID: 0.225
+permissions: 0.194
+register: 0.183
+performance: 0.181
+risc-v: 0.157
+ppc: 0.145
+network: 0.136
+socket: 0.102
+vnc: 0.088
+files: 0.081
+hypervisor: 0.067
+TCG: 0.061
+VMM: 0.054
+virtual: 0.038
+kernel: 0.032
+x86: 0.027
+assembly: 0.019
+i386: 0.018
+KVM: 0.004
+
+macOS QXL VGA not available
+Description of problem:
+```
+qemu-system-aarch64: QXL VGA not available
+```
+```
+qemu-system-aarch64: -device qxl-vga: 'qxl-vga' is not a valid device model name
+```
+Steps to reproduce:
+1. Build QEMU on macOS with SPICE support (meson)
+2. Run commands listed above
+3. Observe QXL not working
+Additional information:
+I'm wiring up QEMU SPICE support on Darwin for Nixpkgs. The same issue can be observed in macports qemu builds with spice. Could this be a packaging issue?
diff --git a/results/classifier/118/device/1290 b/results/classifier/118/device/1290
new file mode 100644
index 00000000..c9394bb8
--- /dev/null
+++ b/results/classifier/118/device/1290
@@ -0,0 +1,31 @@
+device: 0.836
+performance: 0.764
+network: 0.725
+mistranslation: 0.591
+arm: 0.560
+kernel: 0.513
+TCG: 0.447
+ppc: 0.446
+boot: 0.437
+register: 0.386
+socket: 0.311
+graphic: 0.309
+debug: 0.306
+PID: 0.305
+architecture: 0.280
+vnc: 0.239
+permissions: 0.232
+risc-v: 0.223
+VMM: 0.222
+semantic: 0.197
+files: 0.175
+user-level: 0.142
+KVM: 0.057
+virtual: 0.052
+i386: 0.046
+hypervisor: 0.045
+peripherals: 0.012
+assembly: 0.007
+x86: 0.003
+
+IO alignment probing delivers incorrect results on Linux when used with e.g. dm-crypt
diff --git a/results/classifier/118/device/1292 b/results/classifier/118/device/1292
new file mode 100644
index 00000000..056c105f
--- /dev/null
+++ b/results/classifier/118/device/1292
@@ -0,0 +1,33 @@
+device: 0.909
+graphic: 0.882
+architecture: 0.788
+network: 0.543
+performance: 0.482
+semantic: 0.450
+arm: 0.428
+boot: 0.422
+debug: 0.397
+register: 0.372
+mistranslation: 0.345
+PID: 0.269
+files: 0.251
+socket: 0.227
+risc-v: 0.156
+peripherals: 0.123
+virtual: 0.116
+vnc: 0.110
+hypervisor: 0.109
+permissions: 0.108
+ppc: 0.090
+i386: 0.079
+kernel: 0.075
+user-level: 0.074
+VMM: 0.054
+assembly: 0.032
+x86: 0.030
+TCG: 0.023
+KVM: 0.003
+
+Default jemalloc config doesn't work on Asahi Linux
+Description of problem:
+M1 Macs use 16KB pages, jemalloc builds with 4KB page by default.
diff --git a/results/classifier/118/device/1293 b/results/classifier/118/device/1293
new file mode 100644
index 00000000..dd1e4215
--- /dev/null
+++ b/results/classifier/118/device/1293
@@ -0,0 +1,31 @@
+device: 0.897
+performance: 0.610
+network: 0.508
+semantic: 0.496
+boot: 0.416
+graphic: 0.327
+permissions: 0.313
+architecture: 0.308
+arm: 0.301
+mistranslation: 0.300
+kernel: 0.286
+files: 0.285
+register: 0.256
+debug: 0.195
+hypervisor: 0.191
+socket: 0.158
+peripherals: 0.113
+ppc: 0.094
+vnc: 0.092
+i386: 0.056
+TCG: 0.048
+virtual: 0.045
+assembly: 0.044
+user-level: 0.036
+PID: 0.031
+risc-v: 0.030
+VMM: 0.020
+x86: 0.017
+KVM: 0.017
+
+Trusted Firmware stopped booting on SBSA-ref
diff --git a/results/classifier/118/device/1300 b/results/classifier/118/device/1300
new file mode 100644
index 00000000..65f60756
--- /dev/null
+++ b/results/classifier/118/device/1300
@@ -0,0 +1,41 @@
+device: 0.961
+x86: 0.950
+graphic: 0.940
+VMM: 0.915
+peripherals: 0.890
+network: 0.880
+files: 0.868
+vnc: 0.859
+socket: 0.807
+semantic: 0.804
+PID: 0.793
+kernel: 0.740
+debug: 0.736
+architecture: 0.697
+boot: 0.693
+TCG: 0.681
+permissions: 0.666
+ppc: 0.654
+hypervisor: 0.643
+register: 0.639
+arm: 0.589
+virtual: 0.562
+risc-v: 0.553
+assembly: 0.552
+i386: 0.499
+user-level: 0.390
+performance: 0.348
+mistranslation: 0.251
+KVM: 0.202
+
+Build failure when configuring CONFIG_VHOST_USER_FS/CONFIG_VIRTIO
+Description of problem:
+Attempting to configure CONFIG_VHOST_USER_FS or CONFIG_VIRTIO results in a build failure. Complete build log (with configure output) is attached.
+Steps to reproduce:
+1. Add `CONFIG_VIRTIO` and `CONFIG_VHOST_USER_FS` (`y` *or* `n`) to `configs/devices/x86_64-softmmu/gentoo.mak` (done via the [ebuild](https://github.com/gentoo/gentoo/blob/master/app-emulation/qemu/qemu-7.1.0.ebuild))
+2. Configure with `--with-devices-x86_64=gentoo`
+3. Attempt building
+Additional information:
+[build.log](/uploads/72fc1284f5245d9384e521d3b1c65953/build.log)
+
+Reported downstream [here](https://bugs.gentoo.org/873190).
diff --git a/results/classifier/118/device/1302 b/results/classifier/118/device/1302
new file mode 100644
index 00000000..301f8add
--- /dev/null
+++ b/results/classifier/118/device/1302
@@ -0,0 +1,47 @@
+device: 0.832
+graphic: 0.750
+socket: 0.719
+performance: 0.705
+x86: 0.679
+kernel: 0.667
+hypervisor: 0.618
+semantic: 0.584
+PID: 0.556
+network: 0.536
+ppc: 0.521
+architecture: 0.519
+vnc: 0.498
+risc-v: 0.465
+arm: 0.443
+debug: 0.440
+mistranslation: 0.439
+files: 0.418
+boot: 0.417
+register: 0.391
+i386: 0.388
+peripherals: 0.341
+TCG: 0.339
+permissions: 0.327
+KVM: 0.304
+VMM: 0.273
+assembly: 0.256
+virtual: 0.182
+user-level: 0.172
+
+Per-thread logging flag must be made immutable
+Description of problem:
+The problem is that the code assumes it isn't possible to switch from global logging to per-thread logging and vice-versa per design, but it lags appropriate checks to enforce it. Enabling or disabling per-thread logging at runtime from the monitor causes unexpected results.
+Steps to reproduce:
+Enabling per-thread logging at runtime:
+
+1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d`
+2. Enable per-thread logging from the HMP monitor : `(qemu) log tid`
+3. Fails with `Filename template with '%d' required for 'tid'` even though such a template was passed with `-D`.
+
+Disabling per-thread logging at runtime:
+
+1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d -d tid,cpu_reset`
+2. Disable per-thread logging from the HMP monitor: `(qemu) log cpu_reset`
+3. QEMU creates a log file with a bogus `qemu.log.%d` name.
+Additional information:
+[Series](https://patchew.org/QEMU/20221104120059.678470-1-groug@kaod.org/) posted and already reviewed by @rth7680 .
diff --git a/results/classifier/118/device/1305 b/results/classifier/118/device/1305
new file mode 100644
index 00000000..05d9a169
--- /dev/null
+++ b/results/classifier/118/device/1305
@@ -0,0 +1,44 @@
+device: 0.924
+socket: 0.922
+virtual: 0.847
+network: 0.813
+architecture: 0.804
+vnc: 0.798
+performance: 0.779
+graphic: 0.761
+hypervisor: 0.758
+semantic: 0.725
+peripherals: 0.712
+mistranslation: 0.669
+PID: 0.655
+VMM: 0.655
+register: 0.646
+kernel: 0.615
+risc-v: 0.613
+permissions: 0.602
+debug: 0.595
+boot: 0.557
+assembly: 0.530
+arm: 0.476
+TCG: 0.474
+user-level: 0.470
+KVM: 0.452
+ppc: 0.443
+files: 0.442
+i386: 0.439
+x86: 0.382
+
+qemu will detach usbredir if backend chardev socket disconnect
+Description of problem:
+When using the usbredir device in the VM, initiate a hot migration to the VM.  
+After the migration is completed, the drive letter of the usb in the VM has changed.  
+Actually the device has been unplugged and re-plugged in the VM.  
+I think we should keep the plugged state of the device after the migration?
+Steps to reproduce:
+1. Start a usbredirserver `usbredirserver -p 7000 -v 4 5-2`;
+2. Start a VM with a usbredir device attached to it;
+3. Mount the usb device in the VM;
+4. Migrate the VM, after the migration done, wait a minute，the drive letter of the usb in the VM has changed.
+Additional information:
+I've found this bug https://bugzilla.redhat.com/show_bug.cgi?id=1254971, this is just to allow the chardev to be reconnected in time when it is disconnected.   
+Can we make chardev reconnect without unpluging the usbredir device?
diff --git a/results/classifier/118/device/131 b/results/classifier/118/device/131
new file mode 100644
index 00000000..fe49c9df
--- /dev/null
+++ b/results/classifier/118/device/131
@@ -0,0 +1,31 @@
+device: 0.862
+performance: 0.818
+architecture: 0.620
+arm: 0.521
+network: 0.451
+graphic: 0.446
+semantic: 0.343
+register: 0.214
+socket: 0.177
+files: 0.174
+risc-v: 0.170
+debug: 0.168
+boot: 0.166
+hypervisor: 0.142
+peripherals: 0.142
+ppc: 0.139
+mistranslation: 0.138
+user-level: 0.097
+virtual: 0.086
+PID: 0.078
+vnc: 0.067
+permissions: 0.033
+assembly: 0.019
+TCG: 0.015
+i386: 0.012
+x86: 0.012
+kernel: 0.006
+VMM: 0.004
+KVM: 0.000
+
+QEMU's default msrs handling causes Windows 10 64 bit to crash
diff --git a/results/classifier/118/device/1315 b/results/classifier/118/device/1315
new file mode 100644
index 00000000..df9d0f0a
--- /dev/null
+++ b/results/classifier/118/device/1315
@@ -0,0 +1,31 @@
+device: 0.874
+network: 0.863
+architecture: 0.657
+performance: 0.598
+hypervisor: 0.546
+debug: 0.512
+graphic: 0.438
+VMM: 0.431
+virtual: 0.355
+arm: 0.308
+assembly: 0.269
+ppc: 0.255
+semantic: 0.254
+peripherals: 0.200
+PID: 0.180
+mistranslation: 0.171
+permissions: 0.162
+x86: 0.122
+TCG: 0.121
+boot: 0.115
+i386: 0.110
+risc-v: 0.103
+user-level: 0.101
+socket: 0.091
+vnc: 0.085
+register: 0.075
+KVM: 0.066
+files: 0.014
+kernel: 0.009
+
+Assertion failure in vmxnet3_activate_device
diff --git a/results/classifier/118/device/1318 b/results/classifier/118/device/1318
new file mode 100644
index 00000000..aee574a8
--- /dev/null
+++ b/results/classifier/118/device/1318
@@ -0,0 +1,49 @@
+x86: 0.956
+device: 0.945
+peripherals: 0.914
+graphic: 0.910
+architecture: 0.874
+network: 0.865
+hypervisor: 0.861
+kernel: 0.813
+PID: 0.801
+performance: 0.796
+socket: 0.766
+ppc: 0.759
+virtual: 0.748
+permissions: 0.700
+register: 0.679
+semantic: 0.655
+vnc: 0.647
+debug: 0.575
+assembly: 0.569
+risc-v: 0.533
+VMM: 0.507
+arm: 0.454
+TCG: 0.440
+KVM: 0.409
+boot: 0.403
+i386: 0.399
+user-level: 0.383
+files: 0.341
+mistranslation: 0.287
+
+vsock device fails with "qemu-system-x86_64: vhost_set_features failed: Operation not supported (95)" when queue_reset=true
+Description of problem:
+Immediately after guest vsock driver initialize, qemu prints error messages.  I'm not able to connect to the guest with vsock:
+
+```
+[    0.654463] Run /init as init process
+[    0.679778] NET: Registered PF_VSOCK protocol family
+qemu-system-x86_64: vhost_set_features failed: Operation not supported (95)
+qemu-system-x86_64: Error starting vhost: 95
+ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 
+# 
+```
+Steps to reproduce:
+1. Clone `git://passt.top/passt`
+2. In `passt/test`, run `make mbuto.img`
+3. Run `qemu-system-x86_64 -enable-kvm -m 2048 -kernel KERNEL -initrd mbuto.img -nographic -serial stdio -nodefaults -append "console=ttyS0" -device vhost-vsock-pci,guest-cid=31415,queue_reset=true` replacing KERNEL with the host kernel image.
+Additional information:
+- Problem goes away if `queue_reset=false`, which means it goes away with default options prior to `69e1c14aa222` ("virtio: core: vq reset feature negotation support")
+- Occurs both with and without KVM
diff --git a/results/classifier/118/device/132 b/results/classifier/118/device/132
new file mode 100644
index 00000000..ab19415a
--- /dev/null
+++ b/results/classifier/118/device/132
@@ -0,0 +1,31 @@
+device: 0.923
+architecture: 0.847
+debug: 0.825
+virtual: 0.758
+register: 0.735
+assembly: 0.510
+arm: 0.469
+kernel: 0.418
+graphic: 0.417
+x86: 0.412
+performance: 0.400
+i386: 0.344
+mistranslation: 0.304
+hypervisor: 0.301
+semantic: 0.300
+network: 0.235
+peripherals: 0.216
+risc-v: 0.214
+boot: 0.210
+VMM: 0.199
+ppc: 0.182
+user-level: 0.059
+vnc: 0.042
+permissions: 0.036
+PID: 0.035
+TCG: 0.014
+socket: 0.006
+files: 0.006
+KVM: 0.004
+
+AVX instruction VMOVDQU implementation error for YMM registers
diff --git a/results/classifier/118/device/1332234 b/results/classifier/118/device/1332234
new file mode 100644
index 00000000..5ad6be08
--- /dev/null
+++ b/results/classifier/118/device/1332234
@@ -0,0 +1,87 @@
+device: 0.945
+semantic: 0.903
+user-level: 0.870
+graphic: 0.838
+mistranslation: 0.825
+permissions: 0.821
+ppc: 0.801
+PID: 0.795
+architecture: 0.760
+hypervisor: 0.710
+register: 0.703
+assembly: 0.701
+vnc: 0.693
+performance: 0.692
+x86: 0.680
+kernel: 0.670
+socket: 0.659
+risc-v: 0.654
+boot: 0.643
+files: 0.639
+network: 0.621
+VMM: 0.582
+KVM: 0.555
+i386: 0.539
+peripherals: 0.523
+TCG: 0.518
+arm: 0.498
+debug: 0.462
+virtual: 0.190
+
+qemu-system-ppc no longer able to read real cdrom
+
+When I use to send the -cdrom /dev/cdrom option to QEMU, I would be able to use a real cdrom. With QEMU v2.0.0, real cdroms don't work. A quick look at the output from the "info block" command shows this:
+
+ide1-cd0: /dev/cdrom (raw, read-only)
+      Removable device: not locked, tray closed
+
+This indicates that the cdrom is set to /dev/cdrom. I remember versions of QEMU prior to 1.5 were able to use a real cdrom. 
+
+qemu-system-ppc is being run on Mac OS 10.6.8.
+
+According to https://bugs.launchpad.net/qemu/+bug/588691 CD-ROM drives should be working again, so I assume we can close this bug nowadays? Or can you still reproduce it with the latest version of QEMU?
+
+
+> On Sep 24, 2018, at 5:14 AM, Thomas Huth <email address hidden> wrote:
+> 
+> According to https://bugs.launchpad.net/qemu/+bug/588691 CD-ROM drives
+> should be working again, so I assume we can close this bug nowadays? Or
+> can you still reproduce it with the latest version of QEMU?
+> 
+> ** Changed in: qemu
+>       Status: New => Incomplete
+
+
+I cannot reproduce this issue with QEMU. This report can now be closed. Thank you.
+
+
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1332234
+> 
+> Title:
+>  qemu-system-ppc no longer able to read real cdrom
+> 
+> Status in QEMU:
+>  Incomplete
+> 
+> Bug description:
+>  When I use to send the -cdrom /dev/cdrom option to QEMU, I would be
+>  able to use a real cdrom. With QEMU v2.0.0, real cdroms don't work. A
+>  quick look at the output from the "info block" command shows this:
+> 
+>  ide1-cd0: /dev/cdrom (raw, read-only)
+>        Removable device: not locked, tray closed
+> 
+>  This indicates that the cdrom is set to /dev/cdrom. I remember
+>  versions of QEMU prior to 1.5 were able to use a real cdrom.
+> 
+>  qemu-system-ppc is being run on Mac OS 10.6.8.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1332234/+subscriptions
+
+
+
diff --git a/results/classifier/118/device/1334397 b/results/classifier/118/device/1334397
new file mode 100644
index 00000000..34837e5a
--- /dev/null
+++ b/results/classifier/118/device/1334397
@@ -0,0 +1,45 @@
+device: 0.823
+kernel: 0.819
+graphic: 0.797
+boot: 0.767
+architecture: 0.748
+i386: 0.742
+x86: 0.729
+semantic: 0.708
+user-level: 0.665
+mistranslation: 0.664
+risc-v: 0.640
+network: 0.634
+performance: 0.577
+PID: 0.576
+files: 0.564
+arm: 0.542
+socket: 0.525
+TCG: 0.514
+VMM: 0.509
+vnc: 0.505
+debug: 0.492
+ppc: 0.472
+permissions: 0.459
+register: 0.442
+peripherals: 0.431
+hypervisor: 0.372
+virtual: 0.332
+KVM: 0.285
+assembly: 0.186
+
+cmos RTC alarms no longer wake system from suspend
+
+Running QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.1), booting Linux kernels with qemu-system-x86_64 and qemu-system-i386, I no longer see the system resume from suspend when an RTC alarm is set.
+
+My simple test application can be found here:
+https://github.com/johnstultz-work/timetests/blob/master/alarmtimer-suspend.c
+
+Previously this worked w/ QEMU 1.5  (bascially up until I upgraded from Ubuntu 13.10 to Ubuntu 14.04, which came with 2.0).
+
+If a fix has already been committed, is there a branch or tag in the qemu git repo I should validate this with?
+
+I went back and tried the 1.7 and 1.6 releases, and they both seem to have been broken as well wrt cmos alarms waking from suspend.
+
+I assume this has been fixed in v2.1.0 or newer, like the "Fix committed" state indicates, so closing as "Fix released" now. In case there still something left to do here, feel free to re-open it.
+
diff --git a/results/classifier/118/device/1335 b/results/classifier/118/device/1335
new file mode 100644
index 00000000..26a46036
--- /dev/null
+++ b/results/classifier/118/device/1335
@@ -0,0 +1,31 @@
+device: 0.851
+performance: 0.735
+VMM: 0.694
+risc-v: 0.684
+vnc: 0.657
+graphic: 0.641
+boot: 0.577
+PID: 0.572
+TCG: 0.564
+debug: 0.536
+network: 0.536
+arm: 0.493
+ppc: 0.441
+KVM: 0.427
+mistranslation: 0.413
+kernel: 0.393
+architecture: 0.351
+i386: 0.338
+peripherals: 0.315
+x86: 0.314
+socket: 0.290
+files: 0.269
+virtual: 0.193
+semantic: 0.192
+hypervisor: 0.192
+permissions: 0.192
+register: 0.173
+user-level: 0.139
+assembly: 0.073
+
+hot to dump bitmap to disk
diff --git a/results/classifier/118/device/1342 b/results/classifier/118/device/1342
new file mode 100644
index 00000000..17a589ab
--- /dev/null
+++ b/results/classifier/118/device/1342
@@ -0,0 +1,54 @@
+device: 0.933
+graphic: 0.860
+network: 0.811
+VMM: 0.739
+kernel: 0.728
+vnc: 0.707
+PID: 0.693
+arm: 0.692
+ppc: 0.684
+risc-v: 0.665
+register: 0.664
+socket: 0.622
+architecture: 0.620
+semantic: 0.577
+peripherals: 0.542
+boot: 0.499
+performance: 0.474
+TCG: 0.463
+permissions: 0.429
+x86: 0.426
+mistranslation: 0.402
+i386: 0.387
+debug: 0.384
+files: 0.353
+virtual: 0.337
+assembly: 0.332
+hypervisor: 0.280
+KVM: 0.199
+user-level: 0.151
+
+Default machine setting of force-legacy=true causes problems for any modern VirtIO device using MMIO
+Description of problem:
+The default causes problems if you enable any non-legacy VirtIO device which has the VIRTIO_F_VERSION_1 feature bit will not properly read all feature bits. This is because reading VIRTIO_MMIO_VERSION returns VIRT_VERSION_LEGACY which in turn results in the driver not reading all feature bits, e.g. the qtest access:
+
+```
+static uint64_t qvirtio_mmio_get_features(QVirtioDevice *d)
+{
+    QVirtioMMIODevice *dev = container_of(d, QVirtioMMIODevice, vdev);
+    uint64_t lo;
+    uint64_t hi = 0;
+
+    qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 0);
+    lo = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES);
+
+    if (dev->version >= 2) {
+        qtest_writel(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES_SEL, 1);
+        hi = qtest_readl(dev->qts, dev->addr + QVIRTIO_MMIO_HOST_FEATURES);
+    }
+
+    return (hi << 32) | lo;
+}
+```
+Additional information:
+
diff --git a/results/classifier/118/device/1346 b/results/classifier/118/device/1346
new file mode 100644
index 00000000..b5ae1e06
--- /dev/null
+++ b/results/classifier/118/device/1346
@@ -0,0 +1,65 @@
+device: 0.940
+graphic: 0.929
+x86: 0.917
+performance: 0.890
+kernel: 0.862
+architecture: 0.852
+hypervisor: 0.805
+debug: 0.791
+semantic: 0.785
+PID: 0.772
+files: 0.768
+mistranslation: 0.758
+register: 0.720
+socket: 0.706
+user-level: 0.698
+ppc: 0.695
+permissions: 0.690
+vnc: 0.683
+TCG: 0.659
+network: 0.653
+peripherals: 0.642
+virtual: 0.626
+risc-v: 0.626
+VMM: 0.602
+boot: 0.583
+KVM: 0.515
+arm: 0.501
+assembly: 0.469
+i386: 0.410
+
+simulate x86_64 virtio-gpu-gl qemu report error
+Description of problem:
+when I run the below command, it can run ok, and myos can get the virtio-gpu feature,but it less 3d feature.
+   ```
+   ./qemu-system-x86_64 -nographic -M q35 -m 1024 -cpu Nehalem -smp 8 -kernel myos -device virtio-gpu
+   ```
+so I delete ```-nographic``` and modify the device to :
+```
+-device virtio-gpu-gl -display sdl,gl=on
+```
+but qemu tells me ERROR:
+```
+qemu-system-x86_64: ../ui/console-gl.c:105: surface_gl_update_texture: Assertion `gls' failed.
+```
+Additional information:
+I modify the code qemu/ui/sdl2-gl.c function sdl2_gl_switch():
+
+`    
+#if 0
+if (is_placeholder(new_surface) && qemu_console_get_index(dcl->con)) {
+        qemu_gl_fini_shader(scon->gls);
+        scon->gls = NULL;
+        sdl2_window_destroy(scon);
+        return;
+    }
+#endif
+`
+and, qemu can run myos with ```-nographic```, and i can get 3d feature:
+   ```
+   ./qemu-system-x86_64 -nographic -M q35 -m 1024 -cpu Nehalem -smp 8 -kernel myos -device virtio-gpu-gl -display sdl,gl=on
+   ```
+
+I think there is something bug.
+
+thanks
diff --git a/results/classifier/118/device/1354 b/results/classifier/118/device/1354
new file mode 100644
index 00000000..ea4b8d42
--- /dev/null
+++ b/results/classifier/118/device/1354
@@ -0,0 +1,31 @@
+device: 0.976
+peripherals: 0.850
+debug: 0.771
+performance: 0.741
+virtual: 0.561
+PID: 0.439
+semantic: 0.435
+graphic: 0.434
+VMM: 0.427
+mistranslation: 0.361
+risc-v: 0.327
+TCG: 0.324
+permissions: 0.308
+ppc: 0.277
+arm: 0.242
+register: 0.217
+network: 0.214
+vnc: 0.214
+boot: 0.200
+architecture: 0.147
+socket: 0.109
+user-level: 0.083
+assembly: 0.056
+files: 0.035
+hypervisor: 0.023
+KVM: 0.012
+i386: 0.010
+kernel: 0.005
+x86: 0.002
+
+-device usb-tablet not working on android guest.
diff --git a/results/classifier/118/device/1363 b/results/classifier/118/device/1363
new file mode 100644
index 00000000..35658451
--- /dev/null
+++ b/results/classifier/118/device/1363
@@ -0,0 +1,33 @@
+register: 0.981
+architecture: 0.958
+device: 0.946
+semantic: 0.941
+debug: 0.924
+TCG: 0.893
+performance: 0.859
+graphic: 0.828
+peripherals: 0.759
+arm: 0.716
+risc-v: 0.695
+i386: 0.681
+network: 0.586
+boot: 0.584
+x86: 0.575
+PID: 0.549
+vnc: 0.520
+permissions: 0.435
+mistranslation: 0.389
+ppc: 0.386
+assembly: 0.295
+virtual: 0.213
+kernel: 0.182
+socket: 0.114
+user-level: 0.052
+VMM: 0.048
+hypervisor: 0.021
+KVM: 0.005
+files: 0.002
+
+TriCore: writing to registers is not working (as it's supposed to)
+Description of problem:
+Reading the tricore register list from QEMU works just fine. However, writing this registers is not working as expected. It looks like the bug is on QEMU's side, since third party gdb client faces the same issues.
diff --git a/results/classifier/118/device/1367 b/results/classifier/118/device/1367
new file mode 100644
index 00000000..09fc6803
--- /dev/null
+++ b/results/classifier/118/device/1367
@@ -0,0 +1,35 @@
+device: 0.873
+peripherals: 0.849
+network: 0.806
+mistranslation: 0.799
+kernel: 0.791
+architecture: 0.734
+graphic: 0.725
+arm: 0.719
+VMM: 0.574
+socket: 0.547
+vnc: 0.516
+permissions: 0.501
+semantic: 0.496
+files: 0.429
+register: 0.419
+user-level: 0.351
+boot: 0.345
+virtual: 0.290
+risc-v: 0.261
+debug: 0.202
+PID: 0.201
+ppc: 0.170
+performance: 0.147
+TCG: 0.132
+x86: 0.066
+hypervisor: 0.062
+assembly: 0.048
+i386: 0.047
+KVM: 0.010
+
+Support MMIO devices in VFIO
+Additional information:
+- https://lore.kernel.org/qemu-devel/cover.1667542066.git.john.g.johnson@oracle.com/
+- https://github.com/nutanix/libvfio-user
+- It also *somewhat* related to supporting non-PCI devices in `ivshmem`: https://gitlab.com/qemu-project/qemu/-/issues/1134
diff --git a/results/classifier/118/device/1369 b/results/classifier/118/device/1369
new file mode 100644
index 00000000..476b3c70
--- /dev/null
+++ b/results/classifier/118/device/1369
@@ -0,0 +1,31 @@
+device: 0.886
+performance: 0.679
+arm: 0.635
+network: 0.620
+mistranslation: 0.579
+architecture: 0.577
+virtual: 0.504
+hypervisor: 0.459
+VMM: 0.447
+semantic: 0.418
+graphic: 0.374
+assembly: 0.318
+peripherals: 0.223
+register: 0.220
+i386: 0.211
+user-level: 0.199
+vnc: 0.181
+debug: 0.175
+boot: 0.172
+socket: 0.165
+ppc: 0.159
+x86: 0.157
+PID: 0.153
+permissions: 0.119
+files: 0.082
+TCG: 0.046
+KVM: 0.019
+risc-v: 0.010
+kernel: 0.005
+
+'make vm-build-openbsd' fails to notice when QEMU fails to start
diff --git a/results/classifier/118/device/137 b/results/classifier/118/device/137
new file mode 100644
index 00000000..f91f2499
--- /dev/null
+++ b/results/classifier/118/device/137
@@ -0,0 +1,31 @@
+device: 0.874
+performance: 0.627
+architecture: 0.591
+network: 0.479
+graphic: 0.453
+peripherals: 0.332
+risc-v: 0.283
+ppc: 0.239
+register: 0.233
+arm: 0.218
+vnc: 0.206
+semantic: 0.204
+virtual: 0.176
+TCG: 0.165
+mistranslation: 0.163
+debug: 0.161
+permissions: 0.152
+hypervisor: 0.132
+i386: 0.130
+boot: 0.121
+assembly: 0.110
+PID: 0.097
+kernel: 0.088
+x86: 0.075
+socket: 0.069
+user-level: 0.036
+files: 0.022
+VMM: 0.021
+KVM: 0.017
+
+Incompatibility with future VTE will breaks qemu monitor (::commit signal)
diff --git a/results/classifier/118/device/1377163 b/results/classifier/118/device/1377163
new file mode 100644
index 00000000..ed2969d1
--- /dev/null
+++ b/results/classifier/118/device/1377163
@@ -0,0 +1,52 @@
+device: 0.849
+graphic: 0.843
+performance: 0.793
+KVM: 0.760
+peripherals: 0.754
+kernel: 0.733
+mistranslation: 0.696
+semantic: 0.687
+hypervisor: 0.651
+user-level: 0.631
+ppc: 0.605
+architecture: 0.598
+x86: 0.498
+debug: 0.498
+assembly: 0.497
+network: 0.487
+vnc: 0.462
+socket: 0.438
+PID: 0.426
+i386: 0.411
+VMM: 0.401
+arm: 0.399
+permissions: 0.362
+virtual: 0.349
+register: 0.340
+boot: 0.269
+files: 0.252
+TCG: 0.226
+risc-v: 0.205
+
+Does not add usb-host devices as they are hotplugged
+
+A commandline such as
+
+qemu-kvm -device usb-ehci,id=USBCtrl -device host-usb,bus=USBCtrl.0,hostbus=3
+
+should automatically add all devices on the given bus (here: 3) not only initially, but also when new devices appear on that bus while Qemu runs. Currently, all devices on the bus are added initially, but new devices which are added to the (host) usb while Qemu runs have to be added manually.
+
+With some devices, I get a speed mismatch with ehci-usb:
+qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "USB Keyboard" (( speed) to bus "ehci.0", port "1" (high speed)
+
+nec-usb-xhci fixes the keyboard+usb-storage case, but it breaks a webcam:
+qemu-system-x86_64: Warning: speed mismatch trying to attach usb device "Chicony WebCam" (high speed) to bus "usb.0", port "4.3" (full speed)
+
+Anyway,  -device usb-host,... binds to only one device. If you disconnect that device, it will enumerate the next available one and use that. If you only have one port, then you might have more luck with the 'hostport' option. Example that adds all available ports (which might not be the best solution though):
+qemu-system-x86_64 -usb -device usb-ehci,id=usb $(for i in {1..6};do echo -device usb-host,bus=usb.0,hostbus=2,hostport=1.$i;done)
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1384 b/results/classifier/118/device/1384
new file mode 100644
index 00000000..493f5045
--- /dev/null
+++ b/results/classifier/118/device/1384
@@ -0,0 +1,31 @@
+device: 0.859
+user-level: 0.822
+architecture: 0.782
+network: 0.681
+performance: 0.635
+semantic: 0.476
+permissions: 0.471
+arm: 0.468
+peripherals: 0.462
+boot: 0.440
+graphic: 0.435
+x86: 0.432
+files: 0.397
+PID: 0.391
+register: 0.311
+i386: 0.304
+hypervisor: 0.282
+mistranslation: 0.276
+debug: 0.260
+virtual: 0.251
+vnc: 0.251
+VMM: 0.249
+TCG: 0.234
+assembly: 0.220
+socket: 0.190
+ppc: 0.171
+KVM: 0.037
+risc-v: 0.027
+kernel: 0.006
+
+Update libvfio-user to latest upstream
diff --git a/results/classifier/118/device/1386478 b/results/classifier/118/device/1386478
new file mode 100644
index 00000000..fc7c9b8c
--- /dev/null
+++ b/results/classifier/118/device/1386478
@@ -0,0 +1,40 @@
+device: 0.869
+ppc: 0.860
+graphic: 0.722
+performance: 0.704
+mistranslation: 0.624
+socket: 0.606
+vnc: 0.589
+semantic: 0.556
+debug: 0.518
+network: 0.501
+register: 0.473
+architecture: 0.470
+PID: 0.445
+risc-v: 0.422
+i386: 0.375
+boot: 0.354
+files: 0.354
+arm: 0.350
+user-level: 0.350
+x86: 0.314
+permissions: 0.304
+VMM: 0.253
+peripherals: 0.248
+kernel: 0.209
+hypervisor: 0.209
+TCG: 0.205
+virtual: 0.135
+assembly: 0.058
+KVM: 0.037
+
+PS/2 keyboard returns incorrect scan code for F7 to guest
+
+Using qemu 2.1 as supplied in Debian jessie, the F7 scan code (scan set 2) is being returned by qemu to the guest as 0x02, and not the correct value of 0x83.  (I assume 0x83 is correct, given that I cannot locate any scan set 2 charts that use any other value for F7.  Including those published by Microsoft.)
+
+I see the map in hw/input/ps2.c ps2_raw_keycode[] using the correct values, starting at F1:  5, 6, 4, 12 (0x0C). 3. 11 (0x0B), 2, 10 (0x0A), 1, 9, ... but nowhere in that map do I see 131 (0x83).
+
+I think this has been fixed by:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8c10e0baf0260b5
+... so closing this ticket now. If you still have trouble, please re-open it.
+
diff --git a/results/classifier/118/device/1391 b/results/classifier/118/device/1391
new file mode 100644
index 00000000..831e37f3
--- /dev/null
+++ b/results/classifier/118/device/1391
@@ -0,0 +1,58 @@
+device: 0.944
+register: 0.799
+graphic: 0.720
+performance: 0.719
+ppc: 0.566
+files: 0.508
+peripherals: 0.485
+PID: 0.442
+kernel: 0.423
+semantic: 0.414
+TCG: 0.382
+virtual: 0.381
+user-level: 0.376
+architecture: 0.371
+hypervisor: 0.368
+vnc: 0.344
+boot: 0.311
+VMM: 0.307
+debug: 0.303
+socket: 0.300
+risc-v: 0.273
+network: 0.256
+arm: 0.216
+i386: 0.151
+assembly: 0.103
+mistranslation: 0.092
+permissions: 0.059
+x86: 0.038
+KVM: 0.005
+
+virtio-blk: BDRV_REQ_REGISTERED_BUF optimization hint crashes on macOS
+Description of problem:
+When using QEMU 7.2.0 on macOS with the virtio-blk drive, the process will exit and QMP shows a `BLOCK_IO_ERROR` event. This appears to be caused by this line: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/block/virtio-blk.c#L405 introduced in https://gitlab.com/qemu-project/qemu/-/commit/baf422684d73c7bf38e2c18815e18d44fcf395b6
+
+Commenting that line out fixes the issue.
+Steps to reproduce:
+1. Run the QEMU command above with a Ubuntu 22.04 server ISO image.
+2. Follow the installer and try to get to the end.
+3. The process will crash before you can finish installing.
+Additional information:
+Following event appears on QMP:
+```
+{
+    data =     {
+        action = report;
+        device = "drive437EC806-41A4-4CCE-A747-713352E7C27C";
+        "node-name" = "#block785";
+        nospace = 0;
+        operation = write;
+        reason = "Invalid argument";
+    };
+    event = "BLOCK_IO_ERROR";
+    timestamp =     {
+        microseconds = 808474;
+        seconds = 1671867673;
+    };
+}
+```
diff --git a/results/classifier/118/device/1406 b/results/classifier/118/device/1406
new file mode 100644
index 00000000..76379ff1
--- /dev/null
+++ b/results/classifier/118/device/1406
@@ -0,0 +1,31 @@
+device: 0.960
+files: 0.939
+boot: 0.485
+performance: 0.477
+ppc: 0.419
+arm: 0.381
+peripherals: 0.344
+architecture: 0.277
+TCG: 0.230
+network: 0.215
+risc-v: 0.210
+graphic: 0.166
+register: 0.155
+vnc: 0.143
+hypervisor: 0.124
+mistranslation: 0.100
+VMM: 0.090
+PID: 0.086
+socket: 0.082
+kernel: 0.073
+debug: 0.052
+permissions: 0.044
+user-level: 0.040
+virtual: 0.034
+semantic: 0.012
+x86: 0.011
+KVM: 0.006
+assembly: 0.005
+i386: 0.001
+
+WANTED: Schematics, Service, Tech Notes, .pdf  IBM Power4 970MP/FX Apple PowerMac G5 Early/Late 2005
diff --git a/results/classifier/118/device/1413 b/results/classifier/118/device/1413
new file mode 100644
index 00000000..886238a7
--- /dev/null
+++ b/results/classifier/118/device/1413
@@ -0,0 +1,52 @@
+i386: 0.991
+device: 0.952
+graphic: 0.942
+x86: 0.907
+KVM: 0.877
+performance: 0.864
+virtual: 0.864
+VMM: 0.801
+vnc: 0.800
+PID: 0.764
+kernel: 0.751
+boot: 0.722
+socket: 0.719
+ppc: 0.701
+debug: 0.657
+architecture: 0.652
+arm: 0.646
+semantic: 0.639
+register: 0.622
+network: 0.594
+risc-v: 0.571
+files: 0.560
+mistranslation: 0.558
+TCG: 0.553
+hypervisor: 0.535
+permissions: 0.430
+peripherals: 0.414
+user-level: 0.340
+assembly: 0.285
+
+I tried to use qemu-nbd in the shell script, but it seems that qemu-nbd has some delay.
+Description of problem:
+
+Steps to reproduce:
+1.
+```
+cat ~/test.sh
+#!/bin/bash
+qemu-nbd -c /dev/nbd0 $1
+mount -t ntfs3 -o uid=1000,gid=1000 /dev/disk/by-label/OS /mnt/OS
+```
+2.
+```
+sudo ~/test.sh ~/VM/win7_i386.qcow2
+mount: /mnt/OS: special device /dev/disk/by-label/OS does not exist.
+       dmesg(1) may have more information after failed mount system call.
+
+```
+Additional information:
+But when I added a one-second delay between qemu-nbd and mount commands, the problem was solved.
+
+The qemu-img convert command also has a similar problem. It seems that these commands have a certain delay. Is this in line with expectations?
diff --git a/results/classifier/118/device/1416 b/results/classifier/118/device/1416
new file mode 100644
index 00000000..ced264ab
--- /dev/null
+++ b/results/classifier/118/device/1416
@@ -0,0 +1,35 @@
+device: 0.851
+network: 0.824
+graphic: 0.801
+ppc: 0.797
+mistranslation: 0.735
+socket: 0.649
+register: 0.602
+arm: 0.585
+vnc: 0.553
+risc-v: 0.521
+kernel: 0.501
+files: 0.472
+TCG: 0.444
+semantic: 0.439
+i386: 0.422
+x86: 0.412
+PID: 0.403
+performance: 0.380
+architecture: 0.375
+boot: 0.362
+debug: 0.355
+hypervisor: 0.326
+peripherals: 0.266
+VMM: 0.245
+assembly: 0.233
+user-level: 0.228
+permissions: 0.137
+virtual: 0.121
+KVM: 0.049
+
+MTE tags are applied at page granularity (4K) instead of tag granularity (16)
+Description of problem:
+After upgrading to QEMU v7.2.0 from v7.1.0, when executing stg/ldg instructions on any address, QEMU behaves as if the instruction was executed on the page base of said address.
+
+I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `ptr_paddr` is changed to be calculated based on `CPUTLBEntryFull::phys_addr`, which contains the page base address, while beforehand it was calculated based on `host` which does have the page offset applied.
diff --git a/results/classifier/118/device/1432 b/results/classifier/118/device/1432
new file mode 100644
index 00000000..460b46d1
--- /dev/null
+++ b/results/classifier/118/device/1432
@@ -0,0 +1,54 @@
+device: 0.911
+architecture: 0.883
+ppc: 0.876
+graphic: 0.872
+debug: 0.871
+PID: 0.845
+semantic: 0.841
+risc-v: 0.825
+vnc: 0.803
+hypervisor: 0.795
+i386: 0.787
+VMM: 0.782
+files: 0.782
+register: 0.768
+network: 0.751
+performance: 0.751
+socket: 0.728
+kernel: 0.705
+assembly: 0.686
+permissions: 0.677
+user-level: 0.667
+TCG: 0.633
+peripherals: 0.607
+KVM: 0.602
+arm: 0.580
+boot: 0.563
+x86: 0.509
+virtual: 0.449
+mistranslation: 0.355
+
+meson prints "Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12." for every test
+Description of problem:
+Run 'make check V=1' and observe that every test causes an warning message about an unknown TAP version
+
+```
+>>> G_TEST_SRCDIR=/home/berrange/src/virt/qemu/tests/unit MALLOC_PERTURB_=61 G_TEST_BUILDDIR=/home/berrange/src/virt/qemu/build/tests/unit /home/berrange/src/virt/qemu/build/tests/unit/test-shift128 --tap -k
+▶ 22/44 /host-utils/test_lshift                       OK            
+▶ 22/44 /host-utils/test_rshift                       OK            
+22/44 qemu:unit / test-shift128                       OK              0.01s   2 subtests passed
+
+Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12.
+
+```
+
+This message comes from inside meson
+
+```
+$ rpm -ql meson | xargs grep 'Unknown TAP version' 2>/dev/null
+/usr/lib/python3.11/site-packages/mesonbuild/mtest.py:            self.warnings.append('Unknown TAP version. The first line MUST be `TAP version <int>`. Assuming version 12.')
+```
+
+This is with meson-1.0.0-1.fc38.noarch
+Steps to reproduce:
+1. make check V=1
diff --git a/results/classifier/118/device/1445633 b/results/classifier/118/device/1445633
new file mode 100644
index 00000000..3070aece
--- /dev/null
+++ b/results/classifier/118/device/1445633
@@ -0,0 +1,49 @@
+device: 0.942
+performance: 0.937
+peripherals: 0.933
+graphic: 0.926
+hypervisor: 0.866
+x86: 0.778
+network: 0.766
+architecture: 0.764
+semantic: 0.740
+ppc: 0.727
+mistranslation: 0.705
+permissions: 0.686
+register: 0.679
+socket: 0.650
+user-level: 0.629
+arm: 0.627
+vnc: 0.619
+PID: 0.615
+VMM: 0.584
+kernel: 0.501
+risc-v: 0.499
+boot: 0.497
+debug: 0.487
+virtual: 0.476
+TCG: 0.471
+assembly: 0.375
+files: 0.340
+i386: 0.238
+KVM: 0.192
+
+Creating a passthrough USB device causes excessive CPU usage in the guest
+
+My host machine is a Lenovo X1 Carbon (3rd gen) laptop running 64-bit Ubuntu Linux 14.04.  My guest machine is running 64-bit Ubuntu Linux 12.04.  My QEMU was compiled moments ago from the git repository, and it says its version is:
+qemu-x86_64 version 2.2.93, Copyright (c) 2003-2008 Fabrice Bellard
+
+My issue is that when I create a passthrough for a USB host device to the guest, it causes qemu's CPU utilization on the host to increase significantly and stay there.  After the passthrough is created, qemu's CPU usage in top hovers between 20% and 30% (evenly spread across CPUs).  In virt-manager's CPU usage chart, it shows the guest's CPU usage growing from 0% to about 5%, although running "top" in the guest does not show an increase in CPU usage.  These usage levels drop back down to normal (0 to 1%) only after I physically unplug the device or remove the passthrough mapping.
+
+It doesn't seem to matter what the device is.  I have tested it using:
+A Realtek rtl8192cu-based 802.11n adapter
+An HP optical mouse
+A Samsung Galaxy S5 phone
+
+The behavior is the same regardless of device, and they otherwise seem to work properly in the guest machine.
+
+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/118/device/145 b/results/classifier/118/device/145
new file mode 100644
index 00000000..5799f8ae
--- /dev/null
+++ b/results/classifier/118/device/145
@@ -0,0 +1,31 @@
+device: 0.812
+network: 0.458
+arm: 0.368
+performance: 0.314
+debug: 0.300
+i386: 0.256
+graphic: 0.230
+x86: 0.185
+boot: 0.179
+peripherals: 0.164
+hypervisor: 0.151
+PID: 0.139
+semantic: 0.137
+ppc: 0.130
+VMM: 0.129
+architecture: 0.128
+virtual: 0.115
+vnc: 0.113
+register: 0.111
+TCG: 0.072
+risc-v: 0.062
+socket: 0.060
+KVM: 0.053
+mistranslation: 0.050
+user-level: 0.044
+kernel: 0.036
+assembly: 0.030
+permissions: 0.025
+files: 0.013
+
+Issues with qemu-img, libgfapi, and encryption at rest
diff --git a/results/classifier/118/device/1450 b/results/classifier/118/device/1450
new file mode 100644
index 00000000..e86dc735
--- /dev/null
+++ b/results/classifier/118/device/1450
@@ -0,0 +1,31 @@
+device: 0.800
+performance: 0.683
+architecture: 0.524
+arm: 0.461
+network: 0.417
+graphic: 0.406
+assembly: 0.375
+mistranslation: 0.361
+VMM: 0.300
+i386: 0.270
+semantic: 0.261
+debug: 0.220
+KVM: 0.206
+PID: 0.205
+permissions: 0.205
+risc-v: 0.194
+TCG: 0.193
+files: 0.192
+x86: 0.191
+ppc: 0.186
+register: 0.156
+vnc: 0.146
+user-level: 0.118
+boot: 0.108
+hypervisor: 0.084
+virtual: 0.083
+socket: 0.056
+kernel: 0.018
+peripherals: 0.015
+
+ERROR: meson setup failed
diff --git a/results/classifier/118/device/1450891 b/results/classifier/118/device/1450891
new file mode 100644
index 00000000..d6ccdf01
--- /dev/null
+++ b/results/classifier/118/device/1450891
@@ -0,0 +1,61 @@
+device: 0.856
+virtual: 0.826
+hypervisor: 0.788
+semantic: 0.772
+network: 0.756
+performance: 0.708
+graphic: 0.698
+files: 0.660
+register: 0.636
+user-level: 0.620
+mistranslation: 0.606
+risc-v: 0.593
+architecture: 0.590
+permissions: 0.581
+PID: 0.579
+ppc: 0.576
+vnc: 0.572
+socket: 0.526
+arm: 0.510
+debug: 0.506
+boot: 0.504
+peripherals: 0.500
+VMM: 0.469
+i386: 0.461
+x86: 0.448
+assembly: 0.435
+TCG: 0.428
+kernel: 0.415
+KVM: 0.328
+
+VM will not resume on GlusterFS
+
+oVirt uses libvirt to run QEMU.
+Images are passed to QEMU as files, not file descriptors.
+When running images from a GlusterFS, the file descriptors may get invalidated because of network problems or the glusterfs process being restarted.
+In this case, the VM goes into paused state.
+When trying to resume the VM ('cont' command), QEMU uses the same invalidated file descriptors throwing a:
+"block I/O error in device 'drive-virtio-disk0': Transport endpoint is not connected (107)".
+
+Please check file-descriptors and reopen image file on 'cont' event in QEMU.
+Thanks.
+
+References:
+
+[1] http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg01269.html
+[2] https://bugzilla.redhat.com/show_bug.cgi?id=1058300
+
+We can't just reopen files, we don't know what state they are in. Any data that has been written to the image between the last flush and the point where gluster made the fd invalid may be there or may be missing. If any data is missing, we can't continue the guest or you'll get data corruption.
+
+The correct fix for resuming after I/O errors is on gluster. As long as it invalidates the fd, without a way to resume, there is no way for qemu to correctly continue after an error.
+
+Hi Kevin,
+
+I understand. In this case (where the gluster process was killed or crashed) I guess the best option would be to poweroff and restart the VM, which can be done client-side (ovirt + libvirt)
+
+Please mark as "Won't fix".
+
+Thanks. 
+
+Marking as "Won't Fix" according to the last comment.
+
diff --git a/results/classifier/118/device/1453025 b/results/classifier/118/device/1453025
new file mode 100644
index 00000000..6e33c6ba
--- /dev/null
+++ b/results/classifier/118/device/1453025
@@ -0,0 +1,50 @@
+device: 0.901
+network: 0.732
+peripherals: 0.727
+graphic: 0.650
+hypervisor: 0.639
+architecture: 0.603
+virtual: 0.596
+socket: 0.554
+performance: 0.541
+mistranslation: 0.495
+register: 0.451
+permissions: 0.449
+semantic: 0.409
+user-level: 0.385
+ppc: 0.354
+boot: 0.352
+vnc: 0.310
+debug: 0.286
+files: 0.282
+PID: 0.280
+arm: 0.245
+risc-v: 0.241
+x86: 0.201
+VMM: 0.163
+kernel: 0.160
+TCG: 0.152
+i386: 0.126
+assembly: 0.077
+KVM: 0.040
+
+remote usb3.0 redir failed, when guest os has more than one vcpus
+
+I was testing usb3.0 redirection, it worked fine with one vcpu.
+But when I set vcpu to a number greater than one, the redirection failed.
+
+Host and guest are Fedora 20 and Windows 7.
+Client is remote-viwer.
+
+version: qemu 2.3.0  libvirt 1.2.15 spice 0.12.5
+
+libvirt xml: 
+
+<vcpu placement='static'>2</vcpu>
+<controller type='usb' index='0' model='nec-xhci'>
+</controller>
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU / libvirt / spice? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1456 b/results/classifier/118/device/1456
new file mode 100644
index 00000000..f98bd637
--- /dev/null
+++ b/results/classifier/118/device/1456
@@ -0,0 +1,41 @@
+device: 0.870
+graphic: 0.765
+network: 0.698
+performance: 0.673
+arm: 0.579
+semantic: 0.543
+PID: 0.487
+debug: 0.468
+socket: 0.381
+vnc: 0.329
+mistranslation: 0.287
+architecture: 0.251
+ppc: 0.251
+permissions: 0.220
+i386: 0.210
+files: 0.188
+risc-v: 0.186
+boot: 0.182
+TCG: 0.172
+x86: 0.145
+VMM: 0.141
+kernel: 0.136
+user-level: 0.125
+hypervisor: 0.115
+virtual: 0.111
+register: 0.072
+peripherals: 0.064
+KVM: 0.041
+assembly: 0.025
+
+qemu-system-alpha crashes during migration
+Description of problem:
+QEMU crashes (aborts) when trying to migrate with qemu-system-alpha.
+
+```
+qemu-system-alpha: migration/ram.c:874: pss_find_next_dirty: Assertion `pss->host_page_end' failed.
+```
+Steps to reproduce:
+1. Run `./qemu-system-alpha -incoming tcp:0:1234` in one terminal
+2. Run `./qemu-system-alpha -monitor stdio` in another terminal
+3. Type `migrate tcp:0:1234` in the HMP monitor
diff --git a/results/classifier/118/device/1457 b/results/classifier/118/device/1457
new file mode 100644
index 00000000..268ef795
--- /dev/null
+++ b/results/classifier/118/device/1457
@@ -0,0 +1,31 @@
+device: 0.889
+performance: 0.866
+architecture: 0.746
+debug: 0.729
+mistranslation: 0.518
+network: 0.481
+assembly: 0.466
+graphic: 0.437
+boot: 0.395
+semantic: 0.374
+peripherals: 0.348
+register: 0.290
+TCG: 0.265
+PID: 0.262
+vnc: 0.240
+x86: 0.240
+i386: 0.232
+VMM: 0.219
+hypervisor: 0.210
+ppc: 0.204
+arm: 0.168
+risc-v: 0.151
+virtual: 0.129
+KVM: 0.102
+user-level: 0.082
+socket: 0.059
+files: 0.047
+kernel: 0.045
+permissions: 0.019
+
+ide: assertion `bmdma->bus->retry_unit != (uint8_t)-1' failed.
diff --git a/results/classifier/118/device/1466 b/results/classifier/118/device/1466
new file mode 100644
index 00000000..dbe6bdcf
--- /dev/null
+++ b/results/classifier/118/device/1466
@@ -0,0 +1,37 @@
+device: 0.864
+graphic: 0.763
+performance: 0.650
+peripherals: 0.642
+mistranslation: 0.524
+debug: 0.487
+semantic: 0.396
+vnc: 0.334
+arm: 0.330
+architecture: 0.301
+risc-v: 0.290
+permissions: 0.281
+PID: 0.278
+TCG: 0.277
+register: 0.241
+ppc: 0.211
+boot: 0.200
+virtual: 0.188
+VMM: 0.188
+files: 0.169
+socket: 0.155
+kernel: 0.151
+user-level: 0.132
+assembly: 0.080
+network: 0.058
+i386: 0.056
+hypervisor: 0.025
+KVM: 0.024
+x86: 0.007
+
+GTK: mouse position incorrect in HiDPI environment
+Description of problem:
+With `usb-tablet` mode the guest cursor position should be consistent with the host cursor since QEMU can position the mouse absolutely.
+The guest position is off from the host cursor position, it seems the position is not being divided by the scaling factor before it is passed on to the guest.
+Steps to reproduce:
+1. Run any guest with a graphical interface (e.g. Fedora Workstation or Windows 10)
+2. Notice how the guest mouse is not consistent with the host mouse at all
diff --git a/results/classifier/118/device/1476 b/results/classifier/118/device/1476
new file mode 100644
index 00000000..27663762
--- /dev/null
+++ b/results/classifier/118/device/1476
@@ -0,0 +1,31 @@
+device: 0.890
+architecture: 0.745
+mistranslation: 0.535
+performance: 0.499
+boot: 0.475
+risc-v: 0.394
+semantic: 0.388
+VMM: 0.338
+i386: 0.327
+permissions: 0.308
+graphic: 0.305
+debug: 0.260
+ppc: 0.247
+TCG: 0.245
+PID: 0.225
+x86: 0.219
+KVM: 0.214
+vnc: 0.193
+assembly: 0.177
+virtual: 0.171
+arm: 0.154
+hypervisor: 0.144
+kernel: 0.141
+register: 0.127
+socket: 0.092
+peripherals: 0.085
+network: 0.082
+user-level: 0.068
+files: 0.026
+
+Support for additional CMOS memory banks
diff --git a/results/classifier/118/device/1476800 b/results/classifier/118/device/1476800
new file mode 100644
index 00000000..a6763bbc
--- /dev/null
+++ b/results/classifier/118/device/1476800
@@ -0,0 +1,39 @@
+device: 0.879
+virtual: 0.844
+graphic: 0.818
+mistranslation: 0.580
+network: 0.533
+performance: 0.503
+architecture: 0.456
+semantic: 0.440
+socket: 0.392
+files: 0.383
+arm: 0.368
+vnc: 0.363
+risc-v: 0.353
+user-level: 0.334
+boot: 0.312
+ppc: 0.309
+TCG: 0.285
+register: 0.279
+PID: 0.277
+kernel: 0.256
+debug: 0.221
+hypervisor: 0.200
+x86: 0.122
+permissions: 0.105
+VMM: 0.099
+peripherals: 0.081
+i386: 0.065
+assembly: 0.053
+KVM: 0.006
+
+Instant runtime error (Host: Windows 8.1 VM: WinXP ISO)
+
+I have Qemu Manager on my Windows 8.1 laptop and have a WXP iso and a blank disk image (from here http://www.mediafire.com/download/rtec86bwwmee00s/Blank_Disk.zip ) and as soon as I try to open it I get a Runtime Error ( http://i.gyazo.com/bfebf7e1e7a670f8e52cc95c5923a67e.png )
+
+Looking through old bug tickets... which version of QEMU did you use here? Can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/148 b/results/classifier/118/device/148
new file mode 100644
index 00000000..24df768f
--- /dev/null
+++ b/results/classifier/118/device/148
@@ -0,0 +1,31 @@
+device: 0.863
+performance: 0.615
+debug: 0.499
+network: 0.476
+graphic: 0.353
+arm: 0.319
+boot: 0.292
+i386: 0.231
+user-level: 0.231
+peripherals: 0.229
+hypervisor: 0.213
+architecture: 0.206
+socket: 0.195
+register: 0.188
+semantic: 0.181
+x86: 0.172
+risc-v: 0.141
+vnc: 0.122
+kernel: 0.099
+KVM: 0.097
+mistranslation: 0.089
+virtual: 0.089
+ppc: 0.081
+permissions: 0.051
+VMM: 0.046
+TCG: 0.033
+files: 0.024
+assembly: 0.020
+PID: 0.010
+
+Please solve graceful (ACPI) poweroff issue, using signals, most importantly SIGTERM
diff --git a/results/classifier/118/device/1481 b/results/classifier/118/device/1481
new file mode 100644
index 00000000..40ba9744
--- /dev/null
+++ b/results/classifier/118/device/1481
@@ -0,0 +1,31 @@
+device: 0.839
+architecture: 0.633
+graphic: 0.268
+performance: 0.214
+hypervisor: 0.212
+mistranslation: 0.184
+files: 0.162
+semantic: 0.116
+boot: 0.101
+virtual: 0.100
+network: 0.092
+permissions: 0.086
+assembly: 0.073
+socket: 0.046
+debug: 0.045
+PID: 0.044
+register: 0.034
+arm: 0.032
+VMM: 0.028
+TCG: 0.024
+ppc: 0.023
+user-level: 0.018
+vnc: 0.014
+peripherals: 0.012
+risc-v: 0.011
+x86: 0.007
+i386: 0.007
+kernel: 0.006
+KVM: 0.002
+
+How to create Rootfs for sifive_u machine
diff --git a/results/classifier/118/device/1483 b/results/classifier/118/device/1483
new file mode 100644
index 00000000..49186157
--- /dev/null
+++ b/results/classifier/118/device/1483
@@ -0,0 +1,31 @@
+device: 0.859
+architecture: 0.848
+performance: 0.817
+mistranslation: 0.689
+peripherals: 0.640
+debug: 0.635
+graphic: 0.520
+semantic: 0.505
+permissions: 0.491
+assembly: 0.420
+user-level: 0.228
+network: 0.196
+virtual: 0.181
+ppc: 0.175
+hypervisor: 0.169
+arm: 0.122
+register: 0.105
+socket: 0.105
+VMM: 0.098
+files: 0.093
+boot: 0.065
+vnc: 0.063
+PID: 0.060
+risc-v: 0.059
+i386: 0.049
+TCG: 0.049
+KVM: 0.025
+x86: 0.024
+kernel: 0.020
+
+Failed to mount pmem device in qemu
diff --git a/results/classifier/118/device/1485010 b/results/classifier/118/device/1485010
new file mode 100644
index 00000000..c4c103f5
--- /dev/null
+++ b/results/classifier/118/device/1485010
@@ -0,0 +1,41 @@
+device: 0.802
+virtual: 0.801
+mistranslation: 0.784
+network: 0.753
+semantic: 0.739
+architecture: 0.627
+graphic: 0.615
+performance: 0.614
+user-level: 0.588
+ppc: 0.578
+socket: 0.554
+files: 0.517
+register: 0.472
+vnc: 0.446
+PID: 0.442
+risc-v: 0.395
+boot: 0.392
+VMM: 0.392
+TCG: 0.378
+arm: 0.374
+permissions: 0.354
+KVM: 0.338
+peripherals: 0.329
+i386: 0.278
+debug: 0.259
+kernel: 0.241
+x86: 0.181
+hypervisor: 0.156
+assembly: 0.107
+
+qemu-guest-agent should support systemd in addition to pmutils
+
+Hello,
+
+Shouldn't the qemu-guest-agent also support systemd function in addition to the existing call to pm-suspend, shutdown, hwclock.
+
+It's not safe for VM.
+
+This should now be fixed:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=067927d62e097a8a3624a9
+
diff --git a/results/classifier/118/device/149 b/results/classifier/118/device/149
new file mode 100644
index 00000000..ef1e3aeb
--- /dev/null
+++ b/results/classifier/118/device/149
@@ -0,0 +1,31 @@
+device: 0.980
+architecture: 0.961
+network: 0.953
+virtual: 0.938
+socket: 0.916
+performance: 0.914
+register: 0.897
+arm: 0.791
+VMM: 0.743
+debug: 0.597
+mistranslation: 0.589
+kernel: 0.555
+peripherals: 0.500
+PID: 0.480
+boot: 0.428
+hypervisor: 0.420
+risc-v: 0.413
+ppc: 0.401
+user-level: 0.354
+graphic: 0.325
+permissions: 0.301
+semantic: 0.299
+TCG: 0.298
+files: 0.213
+vnc: 0.131
+i386: 0.056
+assembly: 0.053
+x86: 0.021
+KVM: 0.006
+
+vmxnet3 unable to send IPv6 ESP packets
diff --git a/results/classifier/118/device/1491 b/results/classifier/118/device/1491
new file mode 100644
index 00000000..505048d7
--- /dev/null
+++ b/results/classifier/118/device/1491
@@ -0,0 +1,31 @@
+device: 0.819
+performance: 0.750
+graphic: 0.544
+arm: 0.477
+architecture: 0.433
+permissions: 0.340
+files: 0.255
+peripherals: 0.252
+assembly: 0.243
+virtual: 0.214
+debug: 0.208
+mistranslation: 0.199
+semantic: 0.157
+network: 0.154
+user-level: 0.146
+register: 0.138
+hypervisor: 0.133
+ppc: 0.110
+boot: 0.090
+i386: 0.067
+vnc: 0.064
+risc-v: 0.058
+VMM: 0.056
+PID: 0.045
+kernel: 0.036
+x86: 0.030
+TCG: 0.023
+socket: 0.021
+KVM: 0.011
+
+imx_epit will stop unexpectedly when couter rollover
diff --git a/results/classifier/118/device/150 b/results/classifier/118/device/150
new file mode 100644
index 00000000..95583ca7
--- /dev/null
+++ b/results/classifier/118/device/150
@@ -0,0 +1,31 @@
+device: 0.877
+arm: 0.525
+graphic: 0.364
+semantic: 0.307
+mistranslation: 0.296
+i386: 0.265
+performance: 0.240
+risc-v: 0.234
+debug: 0.214
+x86: 0.213
+network: 0.197
+boot: 0.162
+architecture: 0.150
+ppc: 0.138
+kernel: 0.132
+permissions: 0.120
+virtual: 0.102
+KVM: 0.099
+vnc: 0.092
+files: 0.080
+socket: 0.067
+peripherals: 0.067
+register: 0.066
+user-level: 0.032
+assembly: 0.014
+TCG: 0.013
+VMM: 0.012
+PID: 0.011
+hypervisor: 0.004
+
+Illegal Instruction with HVF when encountering SSE instructions in the emulator
diff --git a/results/classifier/118/device/1502 b/results/classifier/118/device/1502
new file mode 100644
index 00000000..725422a4
--- /dev/null
+++ b/results/classifier/118/device/1502
@@ -0,0 +1,31 @@
+device: 0.909
+user-level: 0.872
+performance: 0.650
+graphic: 0.575
+debug: 0.345
+arm: 0.313
+network: 0.300
+assembly: 0.240
+architecture: 0.223
+boot: 0.193
+semantic: 0.180
+PID: 0.175
+mistranslation: 0.168
+register: 0.142
+permissions: 0.122
+peripherals: 0.081
+files: 0.062
+kernel: 0.057
+hypervisor: 0.055
+socket: 0.049
+VMM: 0.046
+ppc: 0.035
+TCG: 0.031
+virtual: 0.031
+vnc: 0.031
+x86: 0.018
+i386: 0.016
+KVM: 0.008
+risc-v: 0.007
+
+Usermode qemu-m68k futex crash while running "cmake -E cmake_autogen"
diff --git a/results/classifier/118/device/1507 b/results/classifier/118/device/1507
new file mode 100644
index 00000000..b988c323
--- /dev/null
+++ b/results/classifier/118/device/1507
@@ -0,0 +1,67 @@
+device: 0.942
+performance: 0.922
+files: 0.913
+graphic: 0.898
+PID: 0.896
+socket: 0.848
+network: 0.827
+ppc: 0.822
+architecture: 0.814
+semantic: 0.798
+mistranslation: 0.788
+kernel: 0.778
+vnc: 0.751
+register: 0.745
+peripherals: 0.706
+TCG: 0.692
+debug: 0.686
+x86: 0.677
+hypervisor: 0.656
+user-level: 0.652
+VMM: 0.652
+permissions: 0.648
+risc-v: 0.630
+arm: 0.629
+boot: 0.624
+i386: 0.616
+KVM: 0.584
+assembly: 0.467
+virtual: 0.462
+
+export/fuse/fuse.c:fuse_fallocate does not do anything but returns success
+Description of problem:
+block/export/fuse.c:fuse_fallocate with `FALLOC_FL_PUNCH_HOLE` does not do anything even though it returns 0 (success). A later read incorrectly returns old data instead of zeros. 
+Should probably return EOPNOTSUPP.
+
+FALLOC_FL_PUNCH_HOLE:
+>Within the specified range, partial filesystem blocks are zeroed,
+and whole filesystem blocks are removed from the file.  After a
+successful call, subsequent reads from this range will return
+zeros.
+https://man7.org/linux/man-pages/man2/fallocate.2.html
+Steps to reproduce:
+```sh
+touch /tmp/data /tmp/fuse_exp 
+dd if=/dev/random of=/tmp/data count=1000 bs=1M
+qemu-storage-daemon --blockdev node-name=node0,driver=raw,file.driver=file,file.filename=/tmp/data --export type=fuse,id=node0-export,node-name=node0,mountpoint=/tmp/fuse_exp,writable=on
+
+hexdump /tmp/fuse_exp -n 16
+# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86
+fallocate -l 1G --punch-hole /tmp/fuse_exp
+echo $?
+# 0
+hexdump /tmp/fuse_exp -n 16
+# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86
+
+
+hexdump /tmp/data -n 16
+# 0000000 4d5f db2d 57ab 02f6 f9c2 d2f1 0c1b 4b86
+fallocate -l 1G --punch-hole /tmp/data
+hexdump /tmp/data -n 16
+# 0000000 0000 0000 0000 0000 0000 0000 0000 0000
+
+# sudo bpftrace -e 'uretprobe:/usr/bin/qemu-storage-daemon:blk_co_pdiscard { printf("ret=%d\n",retval); }'
+# ret=0
+# sudo bpftrace -e 'kretfunc:fuse_file_fallocate { printf("len=%d \t mode=%d ret=%d\n", args->length , args->mode,retval); }'
+# len=1073741824   mode=3 ret=0
+```
diff --git a/results/classifier/118/device/1512 b/results/classifier/118/device/1512
new file mode 100644
index 00000000..d67503e6
--- /dev/null
+++ b/results/classifier/118/device/1512
@@ -0,0 +1,31 @@
+device: 0.902
+user-level: 0.730
+performance: 0.627
+architecture: 0.546
+network: 0.456
+arm: 0.442
+mistranslation: 0.422
+graphic: 0.339
+peripherals: 0.295
+x86: 0.235
+semantic: 0.233
+i386: 0.193
+ppc: 0.177
+boot: 0.172
+virtual: 0.147
+permissions: 0.134
+register: 0.124
+risc-v: 0.123
+debug: 0.121
+hypervisor: 0.112
+files: 0.078
+KVM: 0.071
+vnc: 0.043
+assembly: 0.029
+VMM: 0.029
+TCG: 0.026
+socket: 0.019
+kernel: 0.013
+PID: 0.011
+
+AVX/AVX2 not correcly detected in user mode
diff --git a/results/classifier/118/device/1513234 b/results/classifier/118/device/1513234
new file mode 100644
index 00000000..0bd332ca
--- /dev/null
+++ b/results/classifier/118/device/1513234
@@ -0,0 +1,46 @@
+device: 0.881
+virtual: 0.800
+graphic: 0.791
+performance: 0.765
+architecture: 0.740
+network: 0.695
+vnc: 0.632
+semantic: 0.627
+user-level: 0.586
+arm: 0.586
+hypervisor: 0.585
+register: 0.582
+socket: 0.582
+mistranslation: 0.581
+assembly: 0.551
+permissions: 0.546
+ppc: 0.488
+PID: 0.476
+boot: 0.412
+risc-v: 0.403
+debug: 0.329
+VMM: 0.296
+kernel: 0.295
+files: 0.243
+TCG: 0.219
+peripherals: 0.164
+x86: 0.157
+i386: 0.083
+KVM: 0.077
+
+Cannot ping guest from host after closing laptop lid, and re-opening
+
+I am running Ubuntu 15.10 (this issue also exists on 15.04) x64. Desktop environment to re-produce is either GNOME 3.16 or OpenBox-3. 
+
+I have a Windows 8.1 VM that I run with QEMU and I will work out of that for my job most of the day. When I am going to leave I like to just close my laptop lid, come home, and then get back at it. Unfortunately whenever I get home and open back up my laptop, I can no longer RDP into my VM and can no longer ping it from the host.
+
+If I open up Virt-Manager I can see the desktop via the Console page but cannot RDP into it with FreeRDP (I use FreeRDP all day on this machine so I know this works fine). 
+
+If I use the Console tab to login to the Windows VM again, I notice that I can ping the host from the guest and am connected to the internet. Just can't seem to communicate with the VM via its IP anymore.
+
+I have a NIC NAT virtual card and am using a Bridge
+
+Can you reproduce this issue with the latest upstream version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1515 b/results/classifier/118/device/1515
new file mode 100644
index 00000000..5db9a637
--- /dev/null
+++ b/results/classifier/118/device/1515
@@ -0,0 +1,48 @@
+device: 0.957
+virtual: 0.927
+graphic: 0.917
+PID: 0.853
+vnc: 0.834
+VMM: 0.823
+socket: 0.811
+semantic: 0.784
+ppc: 0.777
+performance: 0.772
+user-level: 0.771
+network: 0.769
+arm: 0.759
+architecture: 0.742
+mistranslation: 0.715
+risc-v: 0.706
+boot: 0.667
+register: 0.640
+hypervisor: 0.543
+debug: 0.536
+KVM: 0.531
+files: 0.500
+TCG: 0.498
+permissions: 0.472
+kernel: 0.460
+i386: 0.411
+x86: 0.384
+assembly: 0.355
+peripherals: 0.227
+
+qemu have  the way to change the windows sid?
+Description of problem:
+I want to change the guest of windows sid after clone guest, have  the way to change it before new guest start? "virt-sysprep" Seems impossible to do it. Although it can be done manually as follow:
+
+[change sid in windows system](https://www.heelpbook.net/2019/microsoft-changing-sid-of-cloned-vms/)
+
+query windows sid:
+cmd: whoami /user
+
+
+step:
+1.clone a new windows guest vm_new
+
+2.change the sid of vm_new  (step2 I don't know how to do that)
+
+3.start vm_new
+
+4.query the vm_new's sid is change
diff --git a/results/classifier/118/device/1519 b/results/classifier/118/device/1519
new file mode 100644
index 00000000..0def8447
--- /dev/null
+++ b/results/classifier/118/device/1519
@@ -0,0 +1,42 @@
+device: 0.940
+performance: 0.863
+vnc: 0.841
+files: 0.768
+graphic: 0.740
+network: 0.722
+debug: 0.662
+permissions: 0.660
+architecture: 0.624
+risc-v: 0.579
+peripherals: 0.537
+register: 0.536
+boot: 0.533
+PID: 0.522
+semantic: 0.471
+socket: 0.456
+arm: 0.438
+i386: 0.427
+ppc: 0.388
+kernel: 0.367
+hypervisor: 0.361
+user-level: 0.295
+x86: 0.266
+mistranslation: 0.259
+KVM: 0.247
+VMM: 0.240
+TCG: 0.218
+assembly: 0.181
+virtual: 0.155
+
+audio recording not working on qemu
+Description of problem:
+QEMU fails to record audio from the guest even when the device options hda-duplex and hda-micro options are used. Tried using the other available audio backends (alsa and sdl) but recording on the guest still fails
+Steps to reproduce:
+1. run the qemu command line above with any of the available audio backends
+2. record audio on the guest 
+3. arecord -vv -d 5 recordng.wav
+4. there's an attempt to record but it hangs
+5. play recorded audio, there's no output
+6. aplay recordng.wav
+Additional information:
+
diff --git a/results/classifier/118/device/1521 b/results/classifier/118/device/1521
new file mode 100644
index 00000000..e8467f57
--- /dev/null
+++ b/results/classifier/118/device/1521
@@ -0,0 +1,31 @@
+device: 0.902
+peripherals: 0.740
+socket: 0.551
+network: 0.543
+arm: 0.516
+virtual: 0.436
+architecture: 0.431
+semantic: 0.407
+permissions: 0.404
+performance: 0.392
+boot: 0.343
+ppc: 0.293
+debug: 0.263
+graphic: 0.258
+risc-v: 0.247
+register: 0.213
+user-level: 0.199
+mistranslation: 0.197
+PID: 0.147
+vnc: 0.125
+TCG: 0.104
+files: 0.090
+i386: 0.084
+VMM: 0.070
+hypervisor: 0.047
+x86: 0.037
+kernel: 0.027
+KVM: 0.026
+assembly: 0.020
+
+USB HID not using the keycodemapdb and thus lacking new entries
diff --git a/results/classifier/118/device/1524637 b/results/classifier/118/device/1524637
new file mode 100644
index 00000000..5c475be1
--- /dev/null
+++ b/results/classifier/118/device/1524637
@@ -0,0 +1,48 @@
+device: 0.805
+kernel: 0.786
+architecture: 0.737
+x86: 0.730
+graphic: 0.727
+semantic: 0.679
+mistranslation: 0.648
+permissions: 0.631
+socket: 0.449
+files: 0.430
+performance: 0.428
+ppc: 0.421
+network: 0.411
+virtual: 0.406
+peripherals: 0.400
+register: 0.396
+arm: 0.388
+risc-v: 0.383
+hypervisor: 0.369
+i386: 0.363
+debug: 0.362
+user-level: 0.355
+vnc: 0.352
+KVM: 0.302
+PID: 0.298
+TCG: 0.265
+VMM: 0.264
+boot: 0.179
+assembly: 0.178
+
+system_powerdown/system_reset not working when exec stop on hmp
+
+system_powerdown/system_reset stops working in qemu for centos kernels if KVM is enabled.
+
+qemu versioin: 2.4
+linux kernel versioin: 4.2.5
+
+How to reproduce:
+
+1. qemu-system-x86_64 -enable-kvm -drive if=none,id=drive0,file=/media/sda5/image/fc21/fc21.raw -device virtio-blk-pci,drive=drive0,iothread=iothread0 -machine smm=off -object iothread,id=iothread0 -monitor stdio
+2. Enter stop in the qemu console, we can see the vm is stopped.
+3. Enter system_powerdown in the qemu console
+4. Nothing happens.
+
+Can you please give a prompt or something else when the vm isn't allowed to powerdown or reset?
+
+Looking through old bug tickets ... I don't think this was really a bug. If you stop your guest, of course the guest operating system can not powerdown anymore. It should powerdown once you resume your guest with "cont".
+
diff --git a/results/classifier/118/device/1527 b/results/classifier/118/device/1527
new file mode 100644
index 00000000..be902de5
--- /dev/null
+++ b/results/classifier/118/device/1527
@@ -0,0 +1,33 @@
+device: 0.921
+architecture: 0.914
+semantic: 0.805
+mistranslation: 0.681
+graphic: 0.661
+ppc: 0.631
+arm: 0.626
+debug: 0.566
+boot: 0.521
+network: 0.503
+peripherals: 0.490
+kernel: 0.489
+i386: 0.469
+user-level: 0.448
+register: 0.415
+assembly: 0.402
+performance: 0.398
+TCG: 0.377
+x86: 0.377
+files: 0.297
+socket: 0.270
+risc-v: 0.265
+VMM: 0.254
+PID: 0.248
+vnc: 0.243
+KVM: 0.237
+virtual: 0.222
+permissions: 0.216
+hypervisor: 0.087
+
+-blockdev option missing host_device documenation and command line help support
+Additional information:
+We recommend -blockdev in the documentation as the preferred way to configure storage backends but the online help isn't useful. We also seem to be missing information for some of the blockdev drivers, for example host_device.
diff --git a/results/classifier/118/device/153 b/results/classifier/118/device/153
new file mode 100644
index 00000000..c48e37d0
--- /dev/null
+++ b/results/classifier/118/device/153
@@ -0,0 +1,31 @@
+device: 0.918
+performance: 0.714
+architecture: 0.509
+debug: 0.491
+semantic: 0.428
+arm: 0.320
+files: 0.281
+user-level: 0.270
+network: 0.239
+mistranslation: 0.209
+ppc: 0.152
+boot: 0.135
+register: 0.120
+vnc: 0.092
+virtual: 0.068
+permissions: 0.046
+peripherals: 0.041
+socket: 0.024
+risc-v: 0.022
+assembly: 0.018
+graphic: 0.017
+PID: 0.009
+VMM: 0.005
+TCG: 0.005
+hypervisor: 0.004
+i386: 0.004
+x86: 0.001
+kernel: 0.001
+KVM: 0.001
+
+SLIRP SMB silently fails with MacOS smbd
diff --git a/results/classifier/118/device/1533848 b/results/classifier/118/device/1533848
new file mode 100644
index 00000000..58798f75
--- /dev/null
+++ b/results/classifier/118/device/1533848
@@ -0,0 +1,36 @@
+device: 0.821
+ppc: 0.641
+semantic: 0.635
+arm: 0.607
+architecture: 0.605
+risc-v: 0.568
+socket: 0.559
+network: 0.511
+boot: 0.417
+vnc: 0.415
+register: 0.374
+permissions: 0.372
+graphic: 0.369
+debug: 0.327
+kernel: 0.321
+files: 0.311
+performance: 0.281
+mistranslation: 0.278
+i386: 0.262
+assembly: 0.229
+virtual: 0.221
+peripherals: 0.219
+user-level: 0.172
+hypervisor: 0.166
+x86: 0.163
+TCG: 0.123
+PID: 0.118
+VMM: 0.090
+KVM: 0.078
+
+A workaround for Windows 7 ACPI SLIC table behavior when used with OVMF
+
+When OVMF is used, Windows 7 refuses to read SLIC ACPI table, passed via -acpitable option, because it expects oem id and oem table id to match in SLIC, XSDT, RSDT, FADT. There's a detailed discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=1248758
+
+Fixed in 37ad223^..ae12374.
+
diff --git a/results/classifier/118/device/1538 b/results/classifier/118/device/1538
new file mode 100644
index 00000000..b5ccfdb3
--- /dev/null
+++ b/results/classifier/118/device/1538
@@ -0,0 +1,31 @@
+device: 0.852
+arm: 0.620
+network: 0.613
+architecture: 0.582
+files: 0.554
+kernel: 0.508
+performance: 0.480
+debug: 0.468
+PID: 0.465
+register: 0.425
+graphic: 0.425
+vnc: 0.361
+TCG: 0.357
+permissions: 0.356
+socket: 0.349
+semantic: 0.323
+i386: 0.296
+mistranslation: 0.296
+boot: 0.281
+ppc: 0.278
+risc-v: 0.266
+x86: 0.235
+peripherals: 0.230
+VMM: 0.225
+assembly: 0.203
+user-level: 0.182
+hypervisor: 0.182
+virtual: 0.172
+KVM: 0.126
+
+igd.c gives up IGD legacy mode if no option ROM found
diff --git a/results/classifier/118/device/1539 b/results/classifier/118/device/1539
new file mode 100644
index 00000000..19c160ba
--- /dev/null
+++ b/results/classifier/118/device/1539
@@ -0,0 +1,33 @@
+device: 0.887
+network: 0.606
+register: 0.596
+performance: 0.544
+arm: 0.482
+socket: 0.467
+permissions: 0.427
+boot: 0.411
+architecture: 0.408
+assembly: 0.384
+mistranslation: 0.352
+semantic: 0.350
+ppc: 0.350
+risc-v: 0.346
+graphic: 0.312
+files: 0.304
+hypervisor: 0.270
+vnc: 0.263
+kernel: 0.260
+peripherals: 0.253
+debug: 0.227
+user-level: 0.200
+virtual: 0.144
+x86: 0.084
+VMM: 0.073
+PID: 0.062
+i386: 0.052
+TCG: 0.043
+KVM: 0.022
+
+Support for SPC58NH92C5
+Additional information:
+
diff --git a/results/classifier/118/device/1542 b/results/classifier/118/device/1542
new file mode 100644
index 00000000..95494370
--- /dev/null
+++ b/results/classifier/118/device/1542
@@ -0,0 +1,43 @@
+device: 0.810
+performance: 0.795
+graphic: 0.737
+network: 0.702
+VMM: 0.672
+kernel: 0.670
+architecture: 0.646
+socket: 0.633
+mistranslation: 0.620
+ppc: 0.613
+semantic: 0.594
+permissions: 0.587
+peripherals: 0.580
+PID: 0.539
+register: 0.522
+vnc: 0.513
+arm: 0.500
+risc-v: 0.494
+hypervisor: 0.453
+i386: 0.449
+files: 0.432
+x86: 0.421
+debug: 0.409
+TCG: 0.353
+assembly: 0.342
+virtual: 0.333
+KVM: 0.330
+boot: 0.301
+user-level: 0.290
+
+Non-Executable PMP regions of size less than 4K trigger instruction access faults non-deterministically
+Description of problem:
+When a non-executable PMP region of size less than 4K (page size) with a start address that is not 4K-aligned is created, QEMU will non-deterministically dispatch instruction access faults when instructions are executed from the PMP-covered region (will in some cases, won't in others, based on the current TLB state)
+Steps to reproduce:
+1. Create a PMP region of size less than 4K, that is not aligned to the start of the page, make it non-executable
+2. Flush TLB with `sfence.vma x0, x0`
+3. Jump to the start of the pmp-protected page and start executing instructions
+4. Notice that no instruction access fault is reported once we reach the protected region inside the page
+Additional information:
+@rth7680 I believe this is at least partially an unintentional result of this commit that you authored: 7e0d9973ea665bf459b2dbd173d0e51bc6ca5216, which modified the behavior of `get_page_addr_code_hostp` probes to probe a single byte, instead of a full page size (signaled by passing 0).
+This means that we initially probe the first byte of the page, see that no PMP faults are raised, and then assume that no other bytes in the page can cause a PMP fault.
+
+Note that I believe that simply changing this back to 0 from 1 is not enough, as this will likely simply reintroduce the issue I originally reported in #1053.
diff --git a/results/classifier/118/device/1548471 b/results/classifier/118/device/1548471
new file mode 100644
index 00000000..7c6db353
--- /dev/null
+++ b/results/classifier/118/device/1548471
@@ -0,0 +1,42 @@
+device: 0.857
+mistranslation: 0.845
+network: 0.669
+graphic: 0.608
+files: 0.583
+PID: 0.568
+vnc: 0.535
+ppc: 0.510
+socket: 0.507
+performance: 0.394
+semantic: 0.393
+permissions: 0.386
+i386: 0.377
+VMM: 0.377
+risc-v: 0.358
+register: 0.343
+TCG: 0.343
+x86: 0.323
+arm: 0.295
+architecture: 0.286
+virtual: 0.258
+user-level: 0.253
+boot: 0.234
+debug: 0.176
+kernel: 0.151
+hypervisor: 0.133
+peripherals: 0.124
+assembly: 0.119
+KVM: 0.050
+
+Lost of log file during block migration
+
+    Hello, i've discovered that during live block migration
+log file is copied(or created on destination) but it actually empty.
+When regular(cold) migration is called log file migrates successfully.
+I'm working on nova project in openstack and i've tried to fix it by adding
+simple scp from source to destination, but log file is owned by libvirt-qemu user
+and i cannot do that from regular user created by openstack.
+Could explain how can i migrate logs safely?
+
+Please discuss this with the libvirt community.  The /var/log/libvirt/qemu/<domain>.log files are managed by libvirt and not QEMU.
+
diff --git a/results/classifier/118/device/1553760 b/results/classifier/118/device/1553760
new file mode 100644
index 00000000..5c407612
--- /dev/null
+++ b/results/classifier/118/device/1553760
@@ -0,0 +1,38 @@
+device: 0.802
+virtual: 0.798
+mistranslation: 0.764
+architecture: 0.744
+network: 0.716
+semantic: 0.584
+vnc: 0.579
+graphic: 0.576
+PID: 0.526
+risc-v: 0.499
+files: 0.487
+socket: 0.479
+permissions: 0.465
+register: 0.398
+VMM: 0.394
+boot: 0.394
+peripherals: 0.393
+performance: 0.341
+kernel: 0.309
+hypervisor: 0.307
+ppc: 0.300
+i386: 0.275
+debug: 0.270
+x86: 0.265
+arm: 0.265
+TCG: 0.248
+user-level: 0.228
+KVM: 0.182
+assembly: 0.147
+
+NUMA node binding are not supported by this QEMU
+
+I read https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1417937/, but I don't understand why it was only fixed on Ubunto.
+I'm running on Debian 8, openstack kilo, and trying to launch a VM with numa pinning.
+Is it not possible to build qemu with CONFIG_NUMA enabled for Debian where libnuma is present?
+
+it did turn out that my qemu had CONFIG_NUMA disabled. ended up upgrading it which solved it.
+
diff --git a/results/classifier/118/device/1563 b/results/classifier/118/device/1563
new file mode 100644
index 00000000..0daa112b
--- /dev/null
+++ b/results/classifier/118/device/1563
@@ -0,0 +1,33 @@
+device: 0.907
+network: 0.858
+socket: 0.795
+kernel: 0.765
+arm: 0.709
+graphic: 0.662
+boot: 0.651
+vnc: 0.574
+risc-v: 0.525
+i386: 0.488
+architecture: 0.453
+ppc: 0.449
+files: 0.446
+x86: 0.401
+assembly: 0.395
+VMM: 0.388
+TCG: 0.333
+KVM: 0.327
+PID: 0.293
+semantic: 0.278
+hypervisor: 0.259
+debug: 0.259
+user-level: 0.155
+register: 0.153
+peripherals: 0.136
+virtual: 0.114
+performance: 0.104
+mistranslation: 0.039
+permissions: 0.030
+
+lsi53c895a: DMA reentrancy issue leads to stack overflow (CVE-2023-0330)
+Description of problem:
+See https://bugzilla.redhat.com/show_bug.cgi?id=2160151.
diff --git a/results/classifier/118/device/1564 b/results/classifier/118/device/1564
new file mode 100644
index 00000000..936d3558
--- /dev/null
+++ b/results/classifier/118/device/1564
@@ -0,0 +1,100 @@
+device: 0.985
+graphic: 0.721
+performance: 0.648
+PID: 0.640
+architecture: 0.633
+ppc: 0.535
+hypervisor: 0.500
+socket: 0.469
+peripherals: 0.457
+debug: 0.453
+network: 0.436
+TCG: 0.435
+boot: 0.394
+x86: 0.391
+kernel: 0.352
+i386: 0.349
+VMM: 0.339
+arm: 0.331
+vnc: 0.297
+risc-v: 0.287
+register: 0.277
+KVM: 0.249
+mistranslation: 0.241
+semantic: 0.229
+user-level: 0.215
+files: 0.136
+permissions: 0.125
+assembly: 0.101
+virtual: 0.030
+
+stat64 on sparc64 failed to get correct major/minor dev
+Description of problem:
+The reported device major/minor is not correct, e.g: stat /dev/zero:
+Reported: Device type: 0,10500000
+Correct : Device type: 1,5
+Steps to reproduce:
+1. "stat /dev/zero" or "ls -l /dev/zero"
+Additional information:
+The problem is a missing padding into target_stat64 struct related to sparc64. Here patch to solve the issue (it also fixes some incorrect variables size):
+
+```
+--- qemu-20230327/linux-user/syscall_defs.h	2023-03-27 15:41:42.000000000 +0200
++++ qemu-20230327/linux-user/syscall_defs.h.new	2023-03-27 21:43:25.615115126 +0200
+@@ -1450,7 +1450,7 @@ struct target_stat {
+ 	unsigned int	st_dev;
+ 	abi_ulong	st_ino;
+ 	unsigned int	st_mode;
+-	unsigned int	st_nlink;
++	short int	st_nlink;
+ 	unsigned int	st_uid;
+ 	unsigned int	st_gid;
+ 	unsigned int	st_rdev;
+@@ -1465,8 +1465,7 @@ struct target_stat {
+ 
+ #define TARGET_HAS_STRUCT_STAT64
+ struct target_stat64 {
+-	unsigned char	__pad0[6];
+-	unsigned short	st_dev;
++	uint64_t	st_dev;
+ 
+ 	uint64_t	st_ino;
+ 	uint64_t	st_nlink;
+@@ -1476,14 +1475,13 @@ struct target_stat64 {
+ 	unsigned int	st_uid;
+ 	unsigned int	st_gid;
+ 
+-	unsigned char	__pad2[6];
+-	unsigned short	st_rdev;
++	unsigned int	__pad0;
++	uint64_t	st_rdev;
+ 
+         int64_t		st_size;
+ 	int64_t		st_blksize;
+ 
+-	unsigned char	__pad4[4];
+-	unsigned int	st_blocks;
++	int64_t		st_blocks;
+ 
+ 	abi_ulong	target_st_atime;
+ 	abi_ulong	target_st_atime_nsec;
+@@ -1522,8 +1520,7 @@ struct target_stat {
+ 
+ #define TARGET_HAS_STRUCT_STAT64
+ struct target_stat64 {
+-	unsigned char	__pad0[6];
+-	unsigned short	st_dev;
++	uint64_t st_dev;
+ 
+ 	uint64_t st_ino;
+ 
+@@ -1533,8 +1530,7 @@ struct target_stat64 {
+ 	unsigned int	st_uid;
+ 	unsigned int	st_gid;
+ 
+-	unsigned char	__pad2[6];
+-	unsigned short	st_rdev;
++	uint64_t        st_rdev;
+ 
+ 	unsigned char	__pad3[8];
+```
diff --git a/results/classifier/118/device/1572 b/results/classifier/118/device/1572
new file mode 100644
index 00000000..f9e68aac
--- /dev/null
+++ b/results/classifier/118/device/1572
@@ -0,0 +1,31 @@
+device: 0.862
+network: 0.803
+debug: 0.739
+performance: 0.722
+mistranslation: 0.645
+assembly: 0.566
+graphic: 0.510
+socket: 0.448
+kernel: 0.428
+architecture: 0.425
+arm: 0.420
+semantic: 0.379
+register: 0.277
+VMM: 0.268
+vnc: 0.246
+boot: 0.232
+TCG: 0.230
+ppc: 0.228
+risc-v: 0.223
+hypervisor: 0.208
+user-level: 0.185
+KVM: 0.169
+peripherals: 0.167
+x86: 0.123
+PID: 0.091
+virtual: 0.080
+i386: 0.060
+permissions: 0.054
+files: 0.053
+
+Assertion !rss_info->enabled failed in e1000e_write_lgcy_rx_descr
diff --git a/results/classifier/118/device/1577937 b/results/classifier/118/device/1577937
new file mode 100644
index 00000000..10bd323d
--- /dev/null
+++ b/results/classifier/118/device/1577937
@@ -0,0 +1,61 @@
+device: 0.807
+graphic: 0.784
+kernel: 0.677
+network: 0.669
+virtual: 0.651
+semantic: 0.626
+architecture: 0.610
+vnc: 0.559
+PID: 0.546
+x86: 0.531
+arm: 0.527
+register: 0.481
+performance: 0.477
+socket: 0.467
+KVM: 0.454
+ppc: 0.436
+permissions: 0.435
+boot: 0.383
+VMM: 0.380
+debug: 0.372
+risc-v: 0.367
+TCG: 0.363
+mistranslation: 0.355
+peripherals: 0.349
+user-level: 0.242
+i386: 0.229
+hypervisor: 0.201
+files: 0.105
+assembly: 0.035
+
+netbeans not working with std graphic driver
+
+Qemu Version:
+QEMU emulator version 2.5.1, Copyright (c) 2003-2008 Fabrice Bellard
+
+Launching VM with:
+sudo qemu-system-x86_64 -enable-kvm -m 1024M ~/guest.vm -usb -vga std
+
+Guest:
+Kali Linux 2016.1
+Kernel:
+4.4.0-kali1-amd64
+Affected Arch:
+64bit & 32bit
+
+Netbeans failing to start after netbeans splash comes up. No netbeans window is being drawn.
+Problem can be reproduced.
+It IS working with -vga qxl, so maybe there's a bug in std emulation.
+
+output from netbeans log (more in attachement):
+
+SEVERE [global]
+java.lang.RuntimeException: failed to load system cursor: DnD.Cursor.CopyDrop : cannot load system cursor: CopyDrop.32x32
+
+
+
+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/118/device/1578 b/results/classifier/118/device/1578
new file mode 100644
index 00000000..70bd5daa
--- /dev/null
+++ b/results/classifier/118/device/1578
@@ -0,0 +1,33 @@
+device: 0.825
+performance: 0.782
+architecture: 0.771
+network: 0.733
+kernel: 0.574
+register: 0.555
+socket: 0.545
+arm: 0.528
+risc-v: 0.504
+debug: 0.475
+boot: 0.466
+vnc: 0.372
+hypervisor: 0.334
+permissions: 0.325
+VMM: 0.319
+graphic: 0.312
+KVM: 0.310
+ppc: 0.295
+i386: 0.282
+PID: 0.282
+TCG: 0.270
+semantic: 0.215
+x86: 0.200
+mistranslation: 0.191
+virtual: 0.124
+peripherals: 0.092
+user-level: 0.059
+files: 0.053
+assembly: 0.044
+
+Send all the SVQ control commands in parallel instead of serialized
+Additional information:
+
diff --git a/results/classifier/118/device/158 b/results/classifier/118/device/158
new file mode 100644
index 00000000..4ae259f1
--- /dev/null
+++ b/results/classifier/118/device/158
@@ -0,0 +1,31 @@
+device: 0.884
+peripherals: 0.883
+performance: 0.737
+graphic: 0.500
+arm: 0.424
+architecture: 0.383
+network: 0.348
+debug: 0.331
+mistranslation: 0.258
+i386: 0.242
+permissions: 0.174
+semantic: 0.166
+virtual: 0.136
+user-level: 0.092
+ppc: 0.088
+PID: 0.086
+boot: 0.069
+x86: 0.063
+socket: 0.060
+VMM: 0.058
+register: 0.058
+files: 0.054
+TCG: 0.034
+risc-v: 0.031
+assembly: 0.025
+hypervisor: 0.022
+vnc: 0.017
+kernel: 0.013
+KVM: 0.002
+
+qemu system emulator crashed when using xhci usb controller
diff --git a/results/classifier/118/device/1581308 b/results/classifier/118/device/1581308
new file mode 100644
index 00000000..d5fc939d
--- /dev/null
+++ b/results/classifier/118/device/1581308
@@ -0,0 +1,55 @@
+x86: 0.992
+architecture: 0.976
+device: 0.966
+peripherals: 0.946
+ppc: 0.934
+vnc: 0.918
+graphic: 0.893
+PID: 0.861
+network: 0.823
+i386: 0.820
+kernel: 0.789
+KVM: 0.788
+files: 0.772
+socket: 0.753
+performance: 0.722
+register: 0.713
+boot: 0.711
+permissions: 0.706
+VMM: 0.688
+user-level: 0.680
+risc-v: 0.676
+TCG: 0.658
+mistranslation: 0.650
+semantic: 0.645
+hypervisor: 0.608
+arm: 0.594
+virtual: 0.551
+debug: 0.477
+assembly: 0.197
+
+ohci doesn't check the 'num-ports' property
+
+command:
+qemu-system-x86_64 -m 1024 -enable-kvm /root/centos6.img -enable-kvm -device pci-ohci,num-ports=100,masterbus=1
+
+The ohci doesn't check the 'num-ports' property and would case an out-of-bands write,crash the qemu process.
+
+    ohci->num_ports = num_ports;
+    if (masterbus) {
+        USBPort *ports[OHCI_MAX_PORTS];
+        for(i = 0; i < num_ports; i++) {
+            ports[i] = &ohci->rhport[i].port;
+        }
+
+The version of qemu is 2.6.0 release from 
+http://wiki.qemu-project.org/download/qemu-2.6.0.tar.bz2
+
+I was able to reproduce the crash, and proposed now a fix on the qemu-devel mailing list (see https://patchwork.ozlabs.org/patch/625092/ for details)
+
+The fix has been included in the repository:
+
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d400fc018b326104d26
+
+Thanks for reporting the issue!
+
diff --git a/results/classifier/118/device/1581976 b/results/classifier/118/device/1581976
new file mode 100644
index 00000000..e5417ba1
--- /dev/null
+++ b/results/classifier/118/device/1581976
@@ -0,0 +1,52 @@
+device: 0.964
+mistranslation: 0.928
+vnc: 0.848
+socket: 0.837
+arm: 0.810
+network: 0.693
+kernel: 0.685
+graphic: 0.664
+ppc: 0.631
+virtual: 0.609
+semantic: 0.496
+register: 0.429
+risc-v: 0.427
+VMM: 0.427
+i386: 0.401
+boot: 0.396
+files: 0.382
+architecture: 0.376
+user-level: 0.375
+performance: 0.366
+debug: 0.325
+TCG: 0.324
+KVM: 0.310
+peripherals: 0.293
+x86: 0.280
+PID: 0.260
+hypervisor: 0.244
+assembly: 0.244
+permissions: 0.065
+
+man qemu contains a bug in description of "-virtfs" command line argument
+
+The description of command line argument looks like this:
+
+ -virtfs
+       fsdriver[,path=path],mount_tag=mount_tag[,security_model=security_model][,writeout=writeout][,readonly][,socket=socket|sock_fd=sock_fd]
+
+
+note, that there is no "id" attribute in the list of parameters.
+
+later on the man there the "id" attribute is documented, as it were present:
+
+           id=id
+               Specifies identifier for this device
+
+i think that it was copied from above section (about "-fsdev") without reviewing.
+
+Fixed by the following commit:
+
+https://github.com/qemu/qemu/commit/b44a6b09705e9e8a3005229b58de36d176020548
+
+
diff --git a/results/classifier/118/device/1582 b/results/classifier/118/device/1582
new file mode 100644
index 00000000..75c89a49
--- /dev/null
+++ b/results/classifier/118/device/1582
@@ -0,0 +1,31 @@
+device: 0.818
+performance: 0.814
+graphic: 0.813
+architecture: 0.734
+network: 0.718
+assembly: 0.459
+ppc: 0.366
+mistranslation: 0.360
+debug: 0.327
+hypervisor: 0.209
+boot: 0.208
+semantic: 0.206
+arm: 0.204
+peripherals: 0.193
+permissions: 0.174
+virtual: 0.165
+TCG: 0.164
+register: 0.135
+socket: 0.118
+user-level: 0.094
+VMM: 0.088
+PID: 0.084
+kernel: 0.060
+files: 0.054
+vnc: 0.052
+x86: 0.048
+risc-v: 0.024
+KVM: 0.012
+i386: 0.005
+
+Floating-point-exception in rtl8139_cplus_transmit_one
diff --git a/results/classifier/118/device/1590796 b/results/classifier/118/device/1590796
new file mode 100644
index 00000000..6881a9ce
--- /dev/null
+++ b/results/classifier/118/device/1590796
@@ -0,0 +1,77 @@
+device: 0.809
+socket: 0.731
+user-level: 0.698
+performance: 0.674
+network: 0.612
+files: 0.612
+architecture: 0.553
+PID: 0.543
+VMM: 0.527
+permissions: 0.514
+KVM: 0.510
+kernel: 0.505
+graphic: 0.486
+boot: 0.467
+x86: 0.439
+vnc: 0.427
+arm: 0.411
+register: 0.369
+ppc: 0.345
+risc-v: 0.333
+mistranslation: 0.318
+assembly: 0.307
+semantic: 0.239
+peripherals: 0.237
+virtual: 0.214
+debug: 0.190
+hypervisor: 0.178
+i386: 0.168
+TCG: 0.139
+
+2.6.0 Windows 7 install hangs on splash screen, works ok with 2.5.1
+
+Hi maintainers,
+
+I have tried to install Windows 7 SP1 from the ISO. The install process hangs on the windows 4 color logo with qemu 2.6.0, it works and installs fine with 2.5.1.
+
+This is the script I used with 2.5.1 and it works perfectly fine:
+
+#!/bin/sh
+exec qemu-system-x86_64 \
+        -enable-kvm \
+        -uuid 0ec801a0-d215-464b-a658-8f43a24cb62e \
+        -machine q35 \
+        -cpu host \
+        -smp cores=2,threads=2 \
+        -drive file=disk/ovmfcode.flash,format=raw,readonly,if=pflash \
+        -drive file=disk/ovmfvars.flash,format=raw,if=pflash \
+        -drive file=disk/windows7.img,discard=unmap,detect-zeroes=unmap,cache=unsafe,if=virtio \
+        -drive file=ISO/windows7.iso,media=cdrom \
+        -drive file=ISO/virtiowin.iso,media=cdrom \
+        -netdev tap,id=nic-0,ifname=tap0,vhost=on,script=no,downscript=no \
+        -net nic,macaddr=52:54:00:01:00:01,netdev=nic-0,model=virtio \
+        -m 4G \
+        -vga qxl \
+        -soundhw ac97 \
+        -usbdevice tablet \
+        -rtc clock=host,base=utc \
+        -name "Windows 7" \
+        -monitor telnet:127.0.0.1:2001,server,nowait \
+        -daemonize
+
+The same hangs on the splash screen with 2.6.0
+
+Even the following simple script behaves the same and hangs at splash screen with 2.6.0:
+
+#!/bin/sh
+exec qemu-system-x86_64 \
+        -drive file=disk/windows7.img,if=ide \
+        -drive file=ISO/windows7.iso,media=cdrom \
+        -name "Windows 7" \
+        $@
+
+The ISO is Windows 7 Ultimate english version, Service Pack 1. 
+I reproduced the same behaviour on Gentoo and Arch, with the Qemu versions provided on both distributions.
+
+Cheers
+
diff --git a/results/classifier/118/device/1592590 b/results/classifier/118/device/1592590
new file mode 100644
index 00000000..52a661c6
--- /dev/null
+++ b/results/classifier/118/device/1592590
@@ -0,0 +1,52 @@
+device: 0.830
+graphic: 0.756
+user-level: 0.699
+architecture: 0.698
+PID: 0.666
+socket: 0.647
+performance: 0.640
+ppc: 0.632
+semantic: 0.626
+register: 0.619
+permissions: 0.590
+files: 0.561
+kernel: 0.540
+network: 0.519
+vnc: 0.504
+VMM: 0.504
+boot: 0.501
+risc-v: 0.485
+hypervisor: 0.476
+mistranslation: 0.436
+KVM: 0.427
+x86: 0.404
+arm: 0.389
+TCG: 0.384
+i386: 0.376
+virtual: 0.352
+peripherals: 0.343
+debug: 0.336
+assembly: 0.184
+
+Prevent qemu-img resize from causing "Active L1 table too large"
+
+This commit prevents qemu from overallocating if qcow2 image is too big (whatever that means): https://lists.gnu.org/archive/html/qemu-devel/2014-07/msg01481.html
+
+However, `qemu-img resize` isn't protected by the same code and allows to go beyond that.
+
+root@nwkr-laptop ~virtkick/hdd # qemu-img resize 33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2 +100000T
+Image resized.
+
+Which then causes "Active L1 table too large" error that cannot be reversed.
+
+root@nwkr-laptop ~virtkick/hdd # qemu-img info 33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2
+qemu-img: Could not open '33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2': Active L1 table too large
+
+root@nwkr-laptop ~virtkick/hdd # qemu-img resize 33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2 -100000T
+qemu-img: Could not open '33_test_609dffde-eb51-4b75-918d-b814f1bcb526.qcow2': Active L1 table too large
+
+
+I originally faces this bug when I passed wrong parameters to qemu-img in a programatic way which caused an image to go corrupt. It's good to protect user's images from being resized too much.
+
+Thanks for the report, sorry for the late reply: This has been fixed in commit 84c26520d3c1c9ff4a10455748139463278816d5 (included in the 2.7.0 release).
+
diff --git a/results/classifier/118/device/1602 b/results/classifier/118/device/1602
new file mode 100644
index 00000000..b4ef28e5
--- /dev/null
+++ b/results/classifier/118/device/1602
@@ -0,0 +1,37 @@
+device: 0.851
+graphic: 0.783
+network: 0.686
+files: 0.651
+arm: 0.617
+debug: 0.602
+socket: 0.582
+boot: 0.504
+PID: 0.493
+mistranslation: 0.452
+semantic: 0.430
+vnc: 0.428
+register: 0.417
+performance: 0.396
+kernel: 0.356
+ppc: 0.355
+TCG: 0.345
+risc-v: 0.342
+i386: 0.251
+VMM: 0.245
+architecture: 0.242
+permissions: 0.211
+x86: 0.198
+peripherals: 0.188
+hypervisor: 0.174
+user-level: 0.161
+KVM: 0.124
+virtual: 0.112
+assembly: 0.097
+
+github.com/qemu/qemu has been out of sync with GitLab since Mar 23, 2023
+Description of problem:
+https://github.com/qemu/qemu has been out of sync with https://gitlab.com/qemu-project/qemu since Mar 23, 2023.
+Steps to reproduce:
+See https://github.com/qemu/qemu
+Additional information:
+
diff --git a/results/classifier/118/device/1603785 b/results/classifier/118/device/1603785
new file mode 100644
index 00000000..8b3973c0
--- /dev/null
+++ b/results/classifier/118/device/1603785
@@ -0,0 +1,48 @@
+device: 0.823
+performance: 0.649
+semantic: 0.636
+files: 0.594
+ppc: 0.573
+network: 0.558
+graphic: 0.548
+mistranslation: 0.517
+architecture: 0.486
+user-level: 0.478
+peripherals: 0.461
+boot: 0.425
+debug: 0.380
+permissions: 0.359
+PID: 0.358
+x86: 0.314
+socket: 0.299
+i386: 0.285
+TCG: 0.271
+register: 0.250
+VMM: 0.243
+vnc: 0.207
+arm: 0.193
+risc-v: 0.188
+KVM: 0.145
+kernel: 0.125
+assembly: 0.101
+hypervisor: 0.097
+virtual: 0.033
+
+trace_usb_port_attach prints junk data
+
+Running qemu with tracing (-D ~/qemu_trace -d trace:\*) will result in a trace file with unprintable characters.
+
+example: usb_port_attach bus 0, port 1, devspeed <90>l<DB>.<D8>U, portspeed full+high
+
+The problem is in hw/usb/bus.c usb_mask_to_str. If speedmask doesn't match any of the defined speed nothing is written to *dest and uninitialized data is printed to the log.
+
+This happens with a real usb device that is forwarded into the machine.
+
+My qemu version is 2.6.0 but it looks like the problem exists in latest git also.
+
+This bug is still present in current head of git; I've just sent a patch: http://patchwork.ozlabs.org/patch/1068196/
+
+
+Patch has been included here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5189e30b146ab39f9d
+
diff --git a/results/classifier/118/device/1610 b/results/classifier/118/device/1610
new file mode 100644
index 00000000..a7055dd2
--- /dev/null
+++ b/results/classifier/118/device/1610
@@ -0,0 +1,31 @@
+device: 0.859
+performance: 0.740
+arm: 0.576
+semantic: 0.520
+graphic: 0.487
+vnc: 0.471
+mistranslation: 0.448
+permissions: 0.391
+architecture: 0.374
+risc-v: 0.362
+boot: 0.358
+VMM: 0.326
+user-level: 0.317
+network: 0.310
+ppc: 0.299
+PID: 0.265
+virtual: 0.217
+hypervisor: 0.183
+assembly: 0.172
+TCG: 0.165
+files: 0.163
+register: 0.134
+i386: 0.103
+KVM: 0.095
+debug: 0.094
+socket: 0.093
+x86: 0.074
+peripherals: 0.025
+kernel: 0.011
+
+support of directX in windows guest
diff --git a/results/classifier/118/device/1616 b/results/classifier/118/device/1616
new file mode 100644
index 00000000..05283081
--- /dev/null
+++ b/results/classifier/118/device/1616
@@ -0,0 +1,31 @@
+device: 0.888
+arm: 0.850
+performance: 0.756
+TCG: 0.657
+vnc: 0.614
+graphic: 0.565
+debug: 0.470
+network: 0.439
+peripherals: 0.423
+architecture: 0.421
+semantic: 0.420
+ppc: 0.414
+risc-v: 0.383
+permissions: 0.324
+boot: 0.314
+user-level: 0.268
+virtual: 0.265
+register: 0.222
+files: 0.197
+mistranslation: 0.192
+assembly: 0.122
+hypervisor: 0.110
+PID: 0.082
+VMM: 0.070
+socket: 0.052
+kernel: 0.051
+x86: 0.012
+i386: 0.010
+KVM: 0.009
+
+convd on arm tcg test fails on arm64 (Apple M1)
diff --git a/results/classifier/118/device/1622 b/results/classifier/118/device/1622
new file mode 100644
index 00000000..351435ce
--- /dev/null
+++ b/results/classifier/118/device/1622
@@ -0,0 +1,31 @@
+device: 0.816
+graphic: 0.739
+performance: 0.726
+mistranslation: 0.443
+risc-v: 0.422
+peripherals: 0.372
+permissions: 0.351
+arm: 0.313
+boot: 0.269
+semantic: 0.257
+network: 0.241
+user-level: 0.165
+ppc: 0.158
+virtual: 0.126
+architecture: 0.106
+vnc: 0.091
+socket: 0.086
+debug: 0.075
+PID: 0.058
+files: 0.057
+register: 0.050
+VMM: 0.040
+TCG: 0.035
+kernel: 0.017
+i386: 0.016
+hypervisor: 0.015
+assembly: 0.012
+x86: 0.009
+KVM: 0.005
+
+PNG screendump has R/B channels swapped
diff --git a/results/classifier/118/device/1635695 b/results/classifier/118/device/1635695
new file mode 100644
index 00000000..2a59b8bc
--- /dev/null
+++ b/results/classifier/118/device/1635695
@@ -0,0 +1,43 @@
+device: 0.908
+hypervisor: 0.897
+boot: 0.852
+VMM: 0.790
+mistranslation: 0.789
+graphic: 0.678
+semantic: 0.674
+architecture: 0.564
+PID: 0.550
+peripherals: 0.506
+register: 0.503
+network: 0.500
+user-level: 0.487
+virtual: 0.480
+ppc: 0.478
+debug: 0.468
+performance: 0.455
+permissions: 0.408
+vnc: 0.392
+files: 0.391
+socket: 0.373
+arm: 0.336
+kernel: 0.245
+x86: 0.229
+assembly: 0.193
+risc-v: 0.186
+TCG: 0.158
+i386: 0.109
+KVM: 0.083
+
+ovmf + smp + hyper-v + windows 7: doesn't work
+
+- using ovmf
+- enable smp (>1 processors/cores)
+- enable hyper-v features (eg. -cpu Haswell,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff)
+- try to boot or install windows 7 x64
+
+Result: black screen and hangs
+
+Sigh, the Windows bug that keeps on giving. And, users avoiding libvirt and sticking with the QEMU command line, despite the fact that using libvirt & its tools would save them from this bug.
+
+Anyway, this report is a duplicate of <https://bugs.launchpad.net/qemu/+bug/1593605>; please read that one for the background. Closing this one as invalid (just like the other one). Thanks.
+
diff --git a/results/classifier/118/device/1643 b/results/classifier/118/device/1643
new file mode 100644
index 00000000..a1a12a38
--- /dev/null
+++ b/results/classifier/118/device/1643
@@ -0,0 +1,31 @@
+device: 0.848
+network: 0.840
+hypervisor: 0.664
+performance: 0.648
+register: 0.569
+risc-v: 0.555
+vnc: 0.428
+architecture: 0.422
+i386: 0.361
+user-level: 0.353
+PID: 0.343
+assembly: 0.334
+virtual: 0.322
+semantic: 0.296
+kernel: 0.282
+mistranslation: 0.273
+boot: 0.249
+arm: 0.248
+permissions: 0.232
+files: 0.203
+peripherals: 0.179
+graphic: 0.173
+debug: 0.144
+ppc: 0.140
+VMM: 0.136
+socket: 0.123
+KVM: 0.075
+x86: 0.035
+TCG: 0.025
+
+Connect to MACVTAP by name
diff --git a/results/classifier/118/device/1651 b/results/classifier/118/device/1651
new file mode 100644
index 00000000..062d51ac
--- /dev/null
+++ b/results/classifier/118/device/1651
@@ -0,0 +1,31 @@
+device: 0.892
+performance: 0.858
+network: 0.780
+graphic: 0.589
+files: 0.565
+debug: 0.540
+architecture: 0.449
+mistranslation: 0.392
+register: 0.377
+boot: 0.341
+arm: 0.296
+VMM: 0.268
+semantic: 0.264
+peripherals: 0.249
+kernel: 0.244
+risc-v: 0.223
+hypervisor: 0.199
+TCG: 0.177
+PID: 0.173
+socket: 0.152
+user-level: 0.141
+virtual: 0.132
+permissions: 0.127
+x86: 0.115
+vnc: 0.105
+ppc: 0.087
+KVM: 0.068
+assembly: 0.055
+i386: 0.016
+
+bcm2835 timer jumps to max delay
diff --git a/results/classifier/118/device/1655 b/results/classifier/118/device/1655
new file mode 100644
index 00000000..1cd7edd7
--- /dev/null
+++ b/results/classifier/118/device/1655
@@ -0,0 +1,31 @@
+device: 0.851
+network: 0.727
+vnc: 0.678
+performance: 0.650
+VMM: 0.650
+socket: 0.581
+files: 0.556
+kernel: 0.555
+mistranslation: 0.552
+arm: 0.522
+graphic: 0.514
+register: 0.488
+ppc: 0.482
+peripherals: 0.480
+architecture: 0.452
+semantic: 0.440
+permissions: 0.435
+TCG: 0.434
+hypervisor: 0.392
+debug: 0.379
+PID: 0.371
+boot: 0.316
+risc-v: 0.274
+user-level: 0.273
+virtual: 0.257
+assembly: 0.219
+KVM: 0.124
+x86: 0.121
+i386: 0.064
+
+qemu-7.2.2 build failed
diff --git a/results/classifier/118/device/1656710 b/results/classifier/118/device/1656710
new file mode 100644
index 00000000..a16072d1
--- /dev/null
+++ b/results/classifier/118/device/1656710
@@ -0,0 +1,44 @@
+device: 0.875
+graphic: 0.870
+semantic: 0.868
+performance: 0.839
+architecture: 0.837
+network: 0.776
+mistranslation: 0.768
+user-level: 0.755
+ppc: 0.751
+permissions: 0.742
+files: 0.726
+register: 0.696
+peripherals: 0.693
+hypervisor: 0.685
+vnc: 0.658
+x86: 0.593
+boot: 0.550
+i386: 0.528
+TCG: 0.528
+socket: 0.510
+debug: 0.497
+PID: 0.476
+arm: 0.449
+VMM: 0.431
+kernel: 0.417
+virtual: 0.351
+risc-v: 0.336
+assembly: 0.299
+KVM: 0.202
+
+Please support Ctrl-Alt-= to zoom in
+
+With the GTK3 interface, qemu-system supports pressing Ctrl-Alt-plus
+to zoom in and Ctrl-Alt-minus to zoom out.  However, unlike many
+programs that support similar zoom hotkeys, qemu-system actually
+requires using '+', making the hotkey Ctrl-Alt-Shift-= .  Most programs
+with similar zoom hotkeys allow Ctrl-Alt-= as a synonym.
+
+Please consider accepting Ctrl-Alt-= as an additional zoom-in hotkey.
+
+(Observed in QEMU 2.8)
+
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=66f6b82bf26cc15e33
+
diff --git a/results/classifier/118/device/1660035 b/results/classifier/118/device/1660035
new file mode 100644
index 00000000..f5f6eb04
--- /dev/null
+++ b/results/classifier/118/device/1660035
@@ -0,0 +1,68 @@
+device: 0.950
+register: 0.831
+performance: 0.805
+ppc: 0.760
+socket: 0.748
+architecture: 0.748
+network: 0.742
+arm: 0.710
+assembly: 0.702
+semantic: 0.691
+kernel: 0.656
+vnc: 0.651
+PID: 0.634
+files: 0.587
+risc-v: 0.584
+mistranslation: 0.577
+graphic: 0.563
+hypervisor: 0.546
+permissions: 0.538
+TCG: 0.515
+peripherals: 0.506
+boot: 0.486
+user-level: 0.457
+debug: 0.443
+i386: 0.438
+virtual: 0.434
+x86: 0.429
+VMM: 0.405
+KVM: 0.350
+
+hw/timer/altera_timer.c:207: bad size in memset ?
+
+hw/timer/altera_timer.c:207:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
+
+Source code is
+
+     memset(t->regs, 0, ARRAY_SIZE(t->regs));
+
+Maybe better code
+
+     memset(t->regs, 0, R_MAX * sizeof( uint32_t));
+
+On 28 January 2017 at 13:16, dcb <email address hidden> wrote:
+> Public bug reported:
+>
+> hw/timer/altera_timer.c:207:5: warning: ‘memset’ used with length equal
+> to number of elements without multiplication by element size [-Wmemset-
+> elt-size]
+>
+> Source code is
+>
+>      memset(t->regs, 0, ARRAY_SIZE(t->regs));
+>
+> Maybe better code
+>
+>      memset(t->regs, 0, R_MAX * sizeof( uint32_t));
+
+Better still -- just memset(t->regs, 0, sizeof(t->regs));
+
+Chris, could you send a patch to fix this, please?
+
+thanks
+-- PMM
+
+
+This problem should have been fixed with QEMU v2.10.0:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cc16ee9d4ecec35ea04e
+
diff --git a/results/classifier/118/device/1661 b/results/classifier/118/device/1661
new file mode 100644
index 00000000..c0b3c5b2
--- /dev/null
+++ b/results/classifier/118/device/1661
@@ -0,0 +1,41 @@
+x86: 0.997
+device: 0.958
+architecture: 0.828
+graphic: 0.410
+semantic: 0.401
+user-level: 0.391
+mistranslation: 0.385
+boot: 0.381
+files: 0.291
+ppc: 0.273
+i386: 0.271
+register: 0.269
+permissions: 0.267
+vnc: 0.248
+debug: 0.246
+socket: 0.240
+performance: 0.225
+PID: 0.208
+risc-v: 0.206
+virtual: 0.196
+kernel: 0.184
+network: 0.161
+VMM: 0.135
+assembly: 0.134
+TCG: 0.074
+arm: 0.053
+peripherals: 0.040
+KVM: 0.037
+hypervisor: 0.026
+
+x86 cpu support request: LX Geode
+Description of problem:
+The Geode LX family of CPUs were used in early generations of the One Laptop Per Child (OLPC) systems (XO 1.0).
+
+They are _basically_ i686-compatible but they lack the 'long-nop' (0x0f 0x1f) instruction available on many other i686-class devices.
+
+Since i686 is a reasonably common baseline for toolchains and the software that is distributed using those toolchains, it would be convenient to be able to use QEMU to test boundary compatibility cases for this CPU.
+Steps to reproduce:
+N/A - feature does not currently exist
+Additional information:
+I'm not adding additional context here at the moment, but please let me know what else would be helpful to know (and/or if I'm off-track with this feature request for any reason).  Thank you!
diff --git a/results/classifier/118/device/1663 b/results/classifier/118/device/1663
new file mode 100644
index 00000000..3cffc5df
--- /dev/null
+++ b/results/classifier/118/device/1663
@@ -0,0 +1,64 @@
+device: 0.957
+graphic: 0.936
+i386: 0.933
+x86: 0.904
+user-level: 0.884
+files: 0.877
+semantic: 0.876
+ppc: 0.863
+TCG: 0.849
+PID: 0.849
+performance: 0.849
+architecture: 0.845
+virtual: 0.827
+peripherals: 0.779
+vnc: 0.776
+network: 0.748
+socket: 0.741
+hypervisor: 0.736
+permissions: 0.723
+register: 0.709
+kernel: 0.694
+VMM: 0.690
+arm: 0.672
+debug: 0.663
+KVM: 0.660
+risc-v: 0.659
+mistranslation: 0.657
+boot: 0.632
+assembly: 0.625
+
+make check-venv fails with errors about incompatible avocado
+Description of problem:
+```
+$ rm -rf build/
+$ ./configure --target-list=x86_64-softmmu,i386-softmmu
+$ make -j 16
+$ ./scripts/device-crash-test -q --tcg-only ./qemu-system-i386
+Module 'qemu' not found.
+  Try 'make check-venv' from your build directory,
+  and then one way to run this script is like so:
+  > $builddir/pyvenv/bin/python3 "/home/berrange/src/virt/qemu/scripts/device-crash-test"
+$ make check-venv
+make[1]: Entering directory '/home/berrange/src/virt/qemu/build'
+  GIT     ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc
+  VENVPIP install -e /home/berrange/src/virt/qemu/python/
+  VENVPIP install -r /home/berrange/src/virt/qemu/tests/requirements.txt
+ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
+avocado-framework-plugin-varianter-yaml-to-mux 98.0 requires avocado-framework==98.0, but you have avocado-framework 101.0 which is incompatible.
+avocado-framework-plugin-result-html 98.0 requires avocado-framework==98.0, but you have avocado-framework 101.0 which is incompatible.
+make[1]: Leaving directory '/home/berrange/src/virt/qemu/build'
+```
+
+Despite this, it seems to have at least partially populated the venv, since I can now run device-crash-test.
+
+My host does have some avocado related python bits present:
+
+```
+python-avocado-common-98.0-1.module_f38+15908+ffe8d4e2.noarch
+python3-avocado-98.0-1.module_f38+15908+ffe8d4e2.noarch
+python3-avocado-plugins-output-html-98.0-1.module_f38+15908+ffe8d4e2.noarch
+python3-avocado-plugins-varianter-yaml-to-mux-98.0-1.module_f38+15908+ffe8d4e2.noarch
+```
+
+I would expect the venv to not use these host packages however, since they're outdated compare to what QEMU askes for in tests/requirements.txt
diff --git a/results/classifier/118/device/1665 b/results/classifier/118/device/1665
new file mode 100644
index 00000000..65dd747a
--- /dev/null
+++ b/results/classifier/118/device/1665
@@ -0,0 +1,31 @@
+device: 0.807
+KVM: 0.714
+hypervisor: 0.712
+performance: 0.479
+network: 0.407
+architecture: 0.389
+files: 0.350
+permissions: 0.321
+PID: 0.318
+kernel: 0.317
+graphic: 0.316
+semantic: 0.282
+register: 0.267
+peripherals: 0.210
+virtual: 0.193
+boot: 0.185
+user-level: 0.184
+debug: 0.135
+mistranslation: 0.130
+i386: 0.119
+arm: 0.113
+ppc: 0.108
+VMM: 0.102
+TCG: 0.087
+vnc: 0.063
+assembly: 0.054
+socket: 0.044
+x86: 0.028
+risc-v: 0.003
+
+When using the"yum install qemu-kvm" command in in rhel 9 , it is not possible to proceed past the "Windows Installer Select Disk" page by iso install
diff --git a/results/classifier/118/device/1672 b/results/classifier/118/device/1672
new file mode 100644
index 00000000..1045f522
--- /dev/null
+++ b/results/classifier/118/device/1672
@@ -0,0 +1,38 @@
+device: 0.956
+graphic: 0.899
+performance: 0.896
+architecture: 0.885
+network: 0.881
+PID: 0.800
+VMM: 0.793
+debug: 0.780
+vnc: 0.760
+permissions: 0.721
+hypervisor: 0.704
+risc-v: 0.693
+boot: 0.683
+socket: 0.667
+semantic: 0.638
+ppc: 0.617
+arm: 0.607
+register: 0.600
+mistranslation: 0.587
+files: 0.576
+TCG: 0.551
+peripherals: 0.547
+kernel: 0.487
+user-level: 0.433
+x86: 0.407
+virtual: 0.369
+assembly: 0.311
+i386: 0.286
+KVM: 0.004
+
+failed to migrate using multifd with multifd-channels larger than 2
+Description of problem:
+try to using multifd live migration on QEMU v8.0.0 using multifd channels larger than 2, but failed.
+Steps to reproduce:
+1. start source / dest qemu vm
+2. migrate_set_capability multifd on && migrate_set_parameter multifd-channels 8
+
+then live migration will failed
diff --git a/results/classifier/118/device/1675549 b/results/classifier/118/device/1675549
new file mode 100644
index 00000000..492e7a49
--- /dev/null
+++ b/results/classifier/118/device/1675549
@@ -0,0 +1,49 @@
+i386: 0.998
+device: 0.954
+architecture: 0.947
+graphic: 0.933
+TCG: 0.927
+network: 0.823
+kernel: 0.800
+register: 0.774
+ppc: 0.761
+socket: 0.747
+mistranslation: 0.738
+peripherals: 0.720
+vnc: 0.719
+arm: 0.680
+performance: 0.652
+PID: 0.650
+risc-v: 0.613
+semantic: 0.600
+files: 0.583
+debug: 0.574
+permissions: 0.497
+boot: 0.466
+user-level: 0.463
+VMM: 0.458
+virtual: 0.240
+x86: 0.219
+hypervisor: 0.210
+assembly: 0.103
+KVM: 0.025
+
+tcg  softmmu i386 crashes on BE hardware 
+
+Hi,
+today i try to test qemu 2.9rc 1 with qemu-system-i386 if i set display as sdl and i push a key on keyboard qemu exit with an error 
+
+translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())
+
+This issue was not present on qemu 2.8.0 
+
+Test Machine PowerMac G5 Quad Fedora 25 Server PPC64
+Qemu build with target-list=i386-softmuu --with-sdlabi=2.0 
+
+Ciao 
+Luigi
+
+This is likely the same or at least a similar problem as reported in this bug here:
+https://bugs.launchpad.net/qemu/+bug/1675108
+
+
diff --git a/results/classifier/118/device/1690 b/results/classifier/118/device/1690
new file mode 100644
index 00000000..5e4348ea
--- /dev/null
+++ b/results/classifier/118/device/1690
@@ -0,0 +1,33 @@
+device: 0.865
+arm: 0.798
+VMM: 0.680
+kernel: 0.641
+files: 0.598
+ppc: 0.564
+boot: 0.529
+vnc: 0.512
+TCG: 0.482
+architecture: 0.459
+risc-v: 0.458
+network: 0.388
+register: 0.383
+socket: 0.378
+debug: 0.353
+PID: 0.351
+KVM: 0.310
+assembly: 0.218
+i386: 0.206
+semantic: 0.171
+x86: 0.164
+performance: 0.153
+graphic: 0.143
+peripherals: 0.121
+mistranslation: 0.080
+virtual: 0.063
+hypervisor: 0.051
+permissions: 0.031
+user-level: 0.014
+
+arguments to specify mapping offsets or map like a elf loader for memory backend file
+Additional information:
+
diff --git a/results/classifier/118/device/1699628 b/results/classifier/118/device/1699628
new file mode 100644
index 00000000..8ff03f43
--- /dev/null
+++ b/results/classifier/118/device/1699628
@@ -0,0 +1,52 @@
+x86: 0.961
+device: 0.932
+ppc: 0.894
+peripherals: 0.875
+semantic: 0.834
+network: 0.803
+architecture: 0.791
+socket: 0.784
+PID: 0.767
+files: 0.764
+vnc: 0.763
+register: 0.750
+boot: 0.743
+kernel: 0.724
+mistranslation: 0.707
+permissions: 0.706
+debug: 0.680
+graphic: 0.675
+i386: 0.674
+arm: 0.628
+performance: 0.587
+risc-v: 0.585
+VMM: 0.555
+TCG: 0.481
+hypervisor: 0.479
+user-level: 0.475
+virtual: 0.444
+assembly: 0.151
+KVM: 0.141
+
+Direct Sound Audio does not stop
+
+The Bug:
+DirectSound Audio does not stop because dsound_ctl_out does not end up calling IDirectSoundBuffer_Stop. This is due to a bug in dsound_get_status_out where the status flags returned from IDirectSoundBuffer_GetStatus are compared with DSERR_BUFFERLOST (an error code) rather than DSBSTATUS_BUFFERLOST (a status flag). The status is actually (DSBSTATUS_LOOPING | DSBSTATUS_PLAYING) and one of those flags happens to be set in the DSERR_BUFFERLOST value. As a result, dsound_get_status_out returns -1 and dsound_ctl_out exits before calling IDirectSoundBuffer_Stop.
+
+The Fix:
+A simple replacement of DSERR_BUFFERLOST with DSBSTATUS_BUFFERLOST in dsound_get_status_out. 
+Should be: "if (*statusp & DSBSTATUS_BUFFERLOST) {"
+
+Version Information:
+I was able to produce this bug in Qemu 2.9.0 and with the latest source pulled from git://git.qemu-project.org/qemu.git (commit 8dfaf23ae1). I was able to verify my suggested fix with the latest source.
+
+Guest OS:
+Discovered running Minoca OS v0.4 (www.github.com/minoca/os). Images at https://www.minocacorp.com/download/nightlies/latest-x86. The Qemu test images I tried (http://wiki.qemu.org/Testing/System_Images) didn't have an easy sound setup (was looking for 'aplay' or similar).
+
+Qemu Command Line:
+./qemu-system-x86_64.exe -m 512 -hda pc.img -smp 4 -usbdevice keyboard -device intel-hda -device hda-duplex
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4ba664cb0aab
+
+
diff --git a/results/classifier/118/device/171 b/results/classifier/118/device/171
new file mode 100644
index 00000000..53579209
--- /dev/null
+++ b/results/classifier/118/device/171
@@ -0,0 +1,31 @@
+device: 0.869
+network: 0.651
+performance: 0.613
+architecture: 0.599
+arm: 0.568
+kernel: 0.507
+risc-v: 0.412
+semantic: 0.400
+boot: 0.388
+hypervisor: 0.345
+KVM: 0.337
+PID: 0.333
+VMM: 0.320
+i386: 0.315
+vnc: 0.310
+TCG: 0.305
+virtual: 0.298
+files: 0.295
+ppc: 0.275
+x86: 0.274
+peripherals: 0.271
+graphic: 0.262
+register: 0.251
+socket: 0.199
+permissions: 0.182
+debug: 0.181
+mistranslation: 0.173
+user-level: 0.122
+assembly: 0.084
+
+[RFE] option to suppress gemu_log() output
diff --git a/results/classifier/118/device/1712 b/results/classifier/118/device/1712
new file mode 100644
index 00000000..0d0e68af
--- /dev/null
+++ b/results/classifier/118/device/1712
@@ -0,0 +1,39 @@
+device: 0.875
+graphic: 0.690
+mistranslation: 0.675
+arm: 0.668
+PID: 0.538
+semantic: 0.458
+boot: 0.453
+kernel: 0.438
+files: 0.367
+ppc: 0.357
+permissions: 0.357
+TCG: 0.338
+debug: 0.333
+risc-v: 0.308
+register: 0.292
+VMM: 0.282
+KVM: 0.281
+architecture: 0.261
+socket: 0.256
+network: 0.230
+x86: 0.222
+vnc: 0.200
+i386: 0.186
+user-level: 0.185
+performance: 0.178
+peripherals: 0.117
+virtual: 0.103
+hypervisor: 0.094
+assembly: 0.081
+
+Arabic keyboard layout wrong.
+Description of problem:
+After a while the compilation process starts, xkb gives an error about symbols/ar not found. According to my research, linux distros using "ara" for arabic layout. But qemu pc-bios/keymaps/ folder contains "ar" for arabic layout.
+Steps to reproduce:
+1.Configure
+2.Build
+3.Wait until error appears.
+Additional information:
+
diff --git a/results/classifier/118/device/1712818 b/results/classifier/118/device/1712818
new file mode 100644
index 00000000..80c8e073
--- /dev/null
+++ b/results/classifier/118/device/1712818
@@ -0,0 +1,101 @@
+device: 0.859
+kernel: 0.834
+peripherals: 0.806
+PID: 0.803
+register: 0.802
+socket: 0.792
+graphic: 0.782
+architecture: 0.764
+KVM: 0.756
+boot: 0.738
+assembly: 0.735
+risc-v: 0.730
+ppc: 0.719
+hypervisor: 0.714
+virtual: 0.713
+user-level: 0.684
+arm: 0.677
+semantic: 0.662
+permissions: 0.623
+VMM: 0.622
+network: 0.616
+x86: 0.615
+TCG: 0.612
+files: 0.595
+vnc: 0.588
+performance: 0.576
+debug: 0.567
+mistranslation: 0.486
+i386: 0.428
+
+live migration with storage encounter assert(!(bs->open_flags & BDRV_O_INACTIVE)) crashes
+
+The vm guest runs a iotest program, and i migrate it with virsh --copy-storage-all,then the qemu process on the source host happens to crash with the following message:
+
+kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed.
+2017-08-24 11:43:45.919+0000: shutting down, reason=crashed
+
+
+here is the release:
+qemu 2.7 & 2.10.rc3 were tested.
+libvirt 3.0.0 & 3.2.0 were tested.
+
+command line:
+src_host:virsh migrate --verbose --live --persistent --copy-storage-all vm-core qemu+ssh://dst_host/system
+
+Resaon: After bdrv_inactivate_all() was called, mirror_run coroutine stills write the left dirty disk data to remote nbd server, which triggers the assertion. But I don't known how to avoid the problem, help is needed!  Thanks.
+
+On 08/24/2017 07:59 AM, meeho yuen wrote:
+> Public bug reported:
+> 
+> The vm guest runs a iotest program, and i migrate it with virsh --copy-
+> storage-all,then the qemu process on the source host happens to crash
+> with the following message:
+> 
+> kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed.
+> 2017-08-24 11:43:45.919+0000: shutting down, reason=crashed
+
+>   here is the release:
+>   qemu 2.7 & 2.10.rc3 were tested.
+
+The just-tagged 2.10-rc4 includes a fix that should be addressing that
+issue during live migration; can you please re-test with that?  (see
+also https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg04513.html)
+
+-- 
+Eric Blake, Principal Software Engineer
+Red Hat, Inc.           +1-919-301-3266
+Virtualization:  qemu.org | libvirt.org
+
+
+
+Thank you,I will try it.
+
+hi,eblake,the problem still exists on qemu 2.10_rc4,although the possibility is less than before.
+
+
+kvm: block/io.c:1543: bdrv_co_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed.
+2017-08-25 11:08:18.963+0000: shutting down, reason=crashed
+
+
+I see the same thing:
+
+2017-12-28 21:36:26.837+0000: initiating migration
+qemu-system-x86_64: block/io.c:1537: bdrv_co_pwritev: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed.
+2017-12-28 21:36:40.516+0000: shutting down, reason=crashed
+~
+
+Running:
+QEMU emulator version 2.10.1
+libvirtd (libvirt) 3.10.0
+
+
+
+It seems that the following commit for libvirt fixed the problem.
+https://github.com/libvirt/libvirt/blob/960326237764f8970250a3608e7b2b880e030715/src/qemu/qemu_migration.c
+
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1726733 b/results/classifier/118/device/1726733
new file mode 100644
index 00000000..dc195abd
--- /dev/null
+++ b/results/classifier/118/device/1726733
@@ -0,0 +1,44 @@
+device: 0.807
+socket: 0.797
+graphic: 0.796
+network: 0.698
+mistranslation: 0.658
+ppc: 0.599
+PID: 0.506
+vnc: 0.504
+register: 0.494
+permissions: 0.476
+kernel: 0.474
+user-level: 0.473
+files: 0.459
+architecture: 0.393
+boot: 0.370
+arm: 0.364
+TCG: 0.361
+performance: 0.355
+debug: 0.334
+semantic: 0.324
+risc-v: 0.315
+VMM: 0.277
+i386: 0.236
+hypervisor: 0.234
+x86: 0.200
+virtual: 0.195
+KVM: 0.135
+peripherals: 0.066
+assembly: 0.046
+
+‘qemu-img info replication:’ causes segfault
+
+Typing the literal command ‘qemu-img info replication:’ causes a segfault.  Note that ‘replication:’ is not a filename.
+
+$ ./qemu-img info replication:
+qemu-img: block.c:2609: bdrv_open_inherit: Assertion `!!(flags & BDRV_O_PROTOCOL) == !!drv->bdrv_file_open' failed.
+Aborted (core dumped)
+
+This was originally found by Han Han and reported in Fedora:
+https://bugzilla.redhat.com/show_bug.cgi?id=1505652
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cb83d2efe1f591cdc7
+
diff --git a/results/classifier/118/device/173 b/results/classifier/118/device/173
new file mode 100644
index 00000000..af34ad20
--- /dev/null
+++ b/results/classifier/118/device/173
@@ -0,0 +1,31 @@
+device: 0.903
+debug: 0.826
+performance: 0.804
+architecture: 0.760
+network: 0.732
+arm: 0.723
+boot: 0.626
+register: 0.543
+risc-v: 0.409
+PID: 0.384
+graphic: 0.376
+VMM: 0.360
+TCG: 0.353
+kernel: 0.331
+semantic: 0.287
+vnc: 0.271
+socket: 0.239
+files: 0.235
+permissions: 0.179
+mistranslation: 0.150
+ppc: 0.103
+virtual: 0.063
+user-level: 0.060
+assembly: 0.052
+peripherals: 0.034
+KVM: 0.008
+x86: 0.008
+i386: 0.007
+hypervisor: 0.003
+
+unable to read symlinks when mounting 9p filesystem with security_model=mapped
diff --git a/results/classifier/118/device/1731347 b/results/classifier/118/device/1731347
new file mode 100644
index 00000000..0e01aaeb
--- /dev/null
+++ b/results/classifier/118/device/1731347
@@ -0,0 +1,73 @@
+device: 0.928
+peripherals: 0.907
+vnc: 0.902
+graphic: 0.893
+x86: 0.854
+network: 0.795
+performance: 0.789
+architecture: 0.772
+semantic: 0.762
+user-level: 0.755
+ppc: 0.751
+KVM: 0.749
+mistranslation: 0.710
+register: 0.630
+debug: 0.624
+socket: 0.617
+PID: 0.602
+virtual: 0.599
+files: 0.590
+permissions: 0.576
+kernel: 0.540
+risc-v: 0.494
+boot: 0.452
+hypervisor: 0.402
+arm: 0.393
+VMM: 0.383
+i386: 0.357
+TCG: 0.343
+assembly: 0.278
+
+VFIO Passthrough of SAS2008-based HBA card fails on E3-1225v3 due to failed DMA mapping (-14)
+
+There is a bug preventing multiple people with my combination of hardware from using PCI passthrough. I am not actually sure whether the bug is in kernel/kvm, vfio or qemu, however, as qemu is the highest-level of these, I am reporting the bug here as you will likely know better where the origin of the bug may be found. 
+
+When attempting to pass through this device to a KVM using VFIO, this results in error -14 (Bad Address):
+
+# qemu-system-x86_64 -enable-kvm -m 10G -net none -monitor stdio -serial
+# none -parallel none -vnc :1 -device vfio-pci,host=1:00.0 -S
+QEMU 2.9.1 monitor - type 'help' for more information
+(qemu) c
+(qemu) qemu-system-x86_64: VFIO_MAP_DMA: -14
+qemu-system-x86_64: vfio_dma_map(0x7f548f0a1fc0, 0xfebd0000, 0x2000, 0x7f54a909d000) = -14 (Bad address)
+qemu: hardware error: vfio: DMA mapping failed, unable to continue
+
+See also:
+https://bugzilla.proxmox.com/show_bug.cgi?id=1556
+https://www.redhat.com/archives/vfio-users/2016-May/msg00088.html
+
+This has occurred on Proxmox (Proxmox and Debian packages, Ubuntu kernel), Ubuntu,
+and pure Debian packages and kernel on Proxmox. However, this error
+reportedly does NOT occur for:
+
+- different distributions(!) (Fedora 24, 25)
+- different HBA cards (SAS2308, SAS3008)
+- different CPU (E3-1220v5)
+
+I would be thankful for any input and I'll be happy to provide any further info necessary. This is my first time delving this deep into anything close to the kernel.
+
+Thanks and best regards,
+Johannes Falke
+
+
+
+Hello！
+   Has your problem been solved? I also encountered a similar problem. My ioctl() also returned an error -14(Bad address).
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1732981 b/results/classifier/118/device/1732981
new file mode 100644
index 00000000..f78af2ff
--- /dev/null
+++ b/results/classifier/118/device/1732981
@@ -0,0 +1,50 @@
+architecture: 0.941
+device: 0.931
+network: 0.793
+socket: 0.755
+peripherals: 0.751
+graphic: 0.746
+semantic: 0.673
+arm: 0.661
+mistranslation: 0.644
+performance: 0.603
+user-level: 0.585
+vnc: 0.559
+register: 0.538
+ppc: 0.531
+PID: 0.529
+debug: 0.500
+permissions: 0.462
+boot: 0.449
+x86: 0.442
+kernel: 0.432
+files: 0.424
+assembly: 0.401
+VMM: 0.379
+hypervisor: 0.359
+TCG: 0.339
+risc-v: 0.335
+virtual: 0.290
+KVM: 0.256
+i386: 0.243
+
+usb-net on aarch64 has wrong class IDs, isn't recognized by Windows
+
+If I run qemu-system-aarch64 with "-device usb-net,...", the resulting USB device will be seen in the guest as class 0x2, subclass 0x2, protocol 0xFF, instead of the expected class 0xe0, subclass 0x1, protocol 0x3. This prevents Windows' in-box class driver from binding to the device. On x86 and x64 Windows, this is not an issue, as another driver will bind to the device, but in Windows for ARM64, that driver is unavailable, so the USB device is incorrectly recognized as a serial port.
+
+Installing a modified version of the inbox driver in "Disable Driver Signature Enforcement" mode solves the issue, but it's not a very clean solution.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1733 b/results/classifier/118/device/1733
new file mode 100644
index 00000000..05bdbcb4
--- /dev/null
+++ b/results/classifier/118/device/1733
@@ -0,0 +1,33 @@
+device: 0.866
+performance: 0.725
+network: 0.556
+arm: 0.462
+graphic: 0.439
+risc-v: 0.338
+debug: 0.323
+ppc: 0.306
+vnc: 0.293
+boot: 0.263
+semantic: 0.258
+architecture: 0.258
+register: 0.235
+peripherals: 0.231
+TCG: 0.195
+kernel: 0.193
+i386: 0.191
+KVM: 0.177
+hypervisor: 0.176
+VMM: 0.165
+x86: 0.122
+mistranslation: 0.105
+virtual: 0.102
+PID: 0.096
+socket: 0.091
+permissions: 0.077
+files: 0.068
+assembly: 0.047
+user-level: 0.045
+
+[riscv-pmp]: PMP_is_locked function has redundant top pmp check
+Additional information:
+
diff --git a/results/classifier/118/device/1735653 b/results/classifier/118/device/1735653
new file mode 100644
index 00000000..03cec0be
--- /dev/null
+++ b/results/classifier/118/device/1735653
@@ -0,0 +1,79 @@
+device: 0.901
+register: 0.894
+architecture: 0.885
+kernel: 0.862
+graphic: 0.844
+boot: 0.811
+arm: 0.769
+debug: 0.753
+user-level: 0.745
+virtual: 0.741
+assembly: 0.661
+performance: 0.641
+socket: 0.636
+semantic: 0.627
+network: 0.625
+ppc: 0.624
+permissions: 0.612
+mistranslation: 0.603
+VMM: 0.558
+PID: 0.547
+files: 0.470
+peripherals: 0.455
+risc-v: 0.400
+TCG: 0.398
+hypervisor: 0.397
+vnc: 0.385
+x86: 0.222
+KVM: 0.211
+i386: 0.105
+
+qemu aarch64 cannot boot linux kernel v4.6+
+
+Hi,
+I tested the latest qemu-system-aarch64 cannot boot linux mainline kernel since v4.6 from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git.
+
+Environment info:
+# host
+ ubuntu 16.04
+# qemu
+ Master branch from git://git.qemu.org/qemu.git, and now the HEAD is c11d61271b9e6e7a1f0479ef1ca8fb55fa457a62.
+# build command
+ ./configure --target-list=aarch64-softmmu
+ make
+# qemu commmand
+ qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -smp 4 -m 1024 -nographic -s -kernel ~/workspace/linux/arch/arm64/boot/Image -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::2222-:22
+
+Error info:
+ No error prompted, actually no any log which means I couldn't see the usually kernel boot message.
+
+Debug info:
+ I did a git bisect on linux, and found with this kernel commit, qemu failed to boot. Parent of 406e308770a92bd33995b2e5b681e86358328bb0 can boot.
+ commit 406e308770a92bd33995b2e5b681e86358328bb0
+    Author: James Morse <email address hidden>
+    Date:   Fri Feb 5 14:58:47 2016 +0000
+
+    arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
+
+    ARMv8.2 adds a new feature register id_aa64mmfr2. This patch adds the
+    cpu feature boiler plate used by the actual features in later patches.
+
+    Signed-off-by: James Morse <email address hidden>
+    Reviewed-by: Suzuki K Poulose <email address hidden>
+    Signed-off-by: Catalin Marinas <email address hidden>
+ The main change in the patch is to add reg_id_aa64mmfr2 in to arch/arm64/include/asm/cpu.h, so might it be any struct change not included in qemu?
+
+Can you please help check how to fix it?
+
+Thanks
+
+- Joey
+
+This bug was fixed in QEMU commit e20d84c1407d43d, back in 2016. Are you sure you're running the version of QEMU which you've just built, and not the installed system one (which is likely to be older)? Your command line suggests you're running the system one. The newly built binary will be ./aarch64-softmmu/qemu-system-aarch64 in the build directory (and you can check using the --version option what binary you're running).
+
+
+Thanks Peter,
+I repeat the step again and it indeed succeed for v4.9 kernel, So I think the ./aarch64-softmmu/qemu-system-aarch64 should be the issue. The case can be closed now.
+
+Thanks again.
+
diff --git a/results/classifier/118/device/1737882 b/results/classifier/118/device/1737882
new file mode 100644
index 00000000..d14c0578
--- /dev/null
+++ b/results/classifier/118/device/1737882
@@ -0,0 +1,38 @@
+device: 0.814
+boot: 0.779
+mistranslation: 0.761
+architecture: 0.714
+graphic: 0.651
+network: 0.595
+permissions: 0.574
+performance: 0.573
+semantic: 0.548
+kernel: 0.543
+socket: 0.496
+register: 0.426
+x86: 0.423
+files: 0.394
+peripherals: 0.374
+risc-v: 0.366
+user-level: 0.364
+i386: 0.363
+debug: 0.358
+PID: 0.317
+vnc: 0.308
+hypervisor: 0.293
+virtual: 0.253
+VMM: 0.210
+TCG: 0.184
+ppc: 0.170
+arm: 0.135
+assembly: 0.126
+KVM: 0.030
+
+QEMU Zaurus cannot boot 2.4.x kernels
+
+I tried akita and spitz machines.
+4.x, 3.x and 2.6.x kernels boot OK, but when I try to pass any 2.4.x, qemu crashes with "Trying to execute code outside RAM or ROM at 0x00800000".
+
+Thanks for the bug report. Unfortunately the akita and spitz models are pretty much unmaintained these days, so if this is important to you you'll need to investigate the cause of the problem yourself, especially given that more recent kernels work.
+
+
diff --git a/results/classifier/118/device/1738771 b/results/classifier/118/device/1738771
new file mode 100644
index 00000000..ac6eac25
--- /dev/null
+++ b/results/classifier/118/device/1738771
@@ -0,0 +1,53 @@
+device: 0.847
+x86: 0.828
+kernel: 0.747
+i386: 0.734
+files: 0.723
+architecture: 0.701
+user-level: 0.675
+performance: 0.646
+mistranslation: 0.640
+permissions: 0.616
+socket: 0.606
+semantic: 0.604
+graphic: 0.574
+network: 0.559
+register: 0.551
+PID: 0.514
+vnc: 0.495
+boot: 0.472
+ppc: 0.443
+risc-v: 0.425
+TCG: 0.362
+arm: 0.329
+peripherals: 0.319
+VMM: 0.318
+debug: 0.277
+virtual: 0.180
+KVM: 0.134
+hypervisor: 0.133
+assembly: 0.075
+
+qemu user does not provide AT_SECURE auxiliary vector entry
+
+When executing an android native binary using qemu in user mode, the program fail with the message
+
+FATAL: kernel did not supply AT_SECURE
+
+Android uses bionic libc.The linker requires that AT_SECURE is provided in the auxiliary vector, but qemu does not provide the entry.
+
+The issue can be reproduced using the commands:
+
+mkdir -p /tmp/android/system
+cd /tmp/android
+curl -O https://dl.google.com/android/repository/sys-img/google_apis/sysimg_x86-21_r15.zip
+unzip sysimg_x86-21_r15.zip
+mount -o loop x86/system.img system
+qemu-i386 -L /tmp/android/ system/bin/ls
+
+
+I've provided a patch (https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03667.html) to fix the issue, but it was not reviewed yet.
+
+A patch to add AT_SECURE went in and was released in QEMU 2.12.
+
+
diff --git a/results/classifier/118/device/174 b/results/classifier/118/device/174
new file mode 100644
index 00000000..fa115485
--- /dev/null
+++ b/results/classifier/118/device/174
@@ -0,0 +1,31 @@
+device: 0.983
+ppc: 0.935
+performance: 0.770
+peripherals: 0.669
+user-level: 0.499
+mistranslation: 0.437
+semantic: 0.359
+graphic: 0.330
+boot: 0.272
+assembly: 0.237
+permissions: 0.210
+architecture: 0.184
+PID: 0.158
+vnc: 0.077
+risc-v: 0.071
+VMM: 0.066
+virtual: 0.065
+TCG: 0.050
+debug: 0.039
+register: 0.037
+files: 0.033
+arm: 0.032
+socket: 0.021
+network: 0.018
+x86: 0.017
+KVM: 0.017
+i386: 0.013
+kernel: 0.008
+hypervisor: 0.002
+
+European keyboard PC-105 deadkey
diff --git a/results/classifier/118/device/1744654 b/results/classifier/118/device/1744654
new file mode 100644
index 00000000..3b7994ee
--- /dev/null
+++ b/results/classifier/118/device/1744654
@@ -0,0 +1,37 @@
+device: 0.948
+graphic: 0.936
+architecture: 0.919
+virtual: 0.906
+socket: 0.895
+ppc: 0.892
+semantic: 0.865
+assembly: 0.862
+mistranslation: 0.814
+network: 0.813
+register: 0.795
+kernel: 0.758
+arm: 0.745
+risc-v: 0.699
+permissions: 0.676
+vnc: 0.669
+KVM: 0.655
+files: 0.652
+PID: 0.651
+peripherals: 0.647
+VMM: 0.605
+performance: 0.549
+i386: 0.532
+x86: 0.531
+hypervisor: 0.493
+debug: 0.485
+boot: 0.474
+TCG: 0.399
+user-level: 0.397
+
+commit: 4fe6d78 "virtio: postpone the execution of event_notifier_cleanup function" will cause vhost-user device crash
+
+The new commit: 4fe6d78 break the existing vhost-user devices, such as vhost-user-scsi/blk and vhost-vsocks when exit the host driver,  kvm_io_ioeventfd_del will hit the abort().
+
+Thanks for the bug report. Patch has now been reverted:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1ef8185a0613dd2ed2
+
diff --git a/results/classifier/118/device/1748 b/results/classifier/118/device/1748
new file mode 100644
index 00000000..4a9c9823
--- /dev/null
+++ b/results/classifier/118/device/1748
@@ -0,0 +1,86 @@
+device: 0.969
+graphic: 0.949
+virtual: 0.918
+performance: 0.879
+files: 0.869
+architecture: 0.829
+hypervisor: 0.819
+debug: 0.816
+PID: 0.792
+KVM: 0.756
+ppc: 0.736
+x86: 0.732
+kernel: 0.725
+i386: 0.725
+boot: 0.690
+semantic: 0.669
+risc-v: 0.659
+network: 0.658
+arm: 0.657
+peripherals: 0.656
+vnc: 0.651
+permissions: 0.648
+VMM: 0.645
+mistranslation: 0.645
+register: 0.636
+socket: 0.617
+TCG: 0.611
+user-level: 0.589
+assembly: 0.505
+
+qcow2: disk size exceeds virtual size
+Description of problem:
+Disk size of qcow2 image file exceeds its virtual size after repeatedly writing, and deleting data in qemu vm.
+Steps to reproduce:
+1. qemu-img create -f qcow2 tmp.qcow2 32M
+2. attach tmp.qcow2 as a device to qemu vm
+3. mount the device in qemu vm, and repeatedly writing, and deleting data
+Additional information:
+xml for attaching tmp.qcow2
+```xml
+   <disk device="disk" type="file">
+      <target bus="virtio" dev="vdb"/>
+      <source file="/path/to/tmp.qcow2"/>
+      <driver type="qcow2" name="qemu" cache="none" discard="unmap"/>
+   </disk>
+```
+in fact, set discard="unmap" or not seems has `little impact` on the final result.
+reproducible shell script.
+```sh
+#! /bin/sh
+
+for i in {1..1000}; do
+    for j in {1..27}; do
+        dd if=/dev/zero of=/mnt/test-$j bs=1M count=1 &
+    done
+    sync
+    sleep 10
+    rm -f /mnt/test-*   
+    fstrim /mnt
+done
+```
+MOUNT the device and run this script, problem happens about 30 minutes.
+
+final result looks like:
+```sh
+# qemu-img info tmp.qcow2 --force
+image: tmp.qcow2
+file format: qcow2
+virtual size: 32 MiB (33554432 bytes)
+disk size: 33 MiB
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+Child node '/file':
+    filename: tmp.qcow2
+    protocol type: file
+    file length: 32.3 MiB (33882112 bytes)
+    disk size: 33 MiB
+    Format specific information:
+        extent size hint: 1048576
+```
diff --git a/results/classifier/118/device/1749 b/results/classifier/118/device/1749
new file mode 100644
index 00000000..c4b98815
--- /dev/null
+++ b/results/classifier/118/device/1749
@@ -0,0 +1,50 @@
+device: 0.818
+architecture: 0.763
+graphic: 0.638
+ppc: 0.630
+permissions: 0.628
+performance: 0.615
+semantic: 0.570
+peripherals: 0.562
+network: 0.550
+mistranslation: 0.492
+PID: 0.473
+risc-v: 0.471
+debug: 0.450
+TCG: 0.447
+register: 0.443
+vnc: 0.420
+hypervisor: 0.412
+arm: 0.392
+socket: 0.387
+VMM: 0.358
+user-level: 0.321
+files: 0.287
+virtual: 0.264
+x86: 0.255
+kernel: 0.254
+boot: 0.245
+assembly: 0.204
+i386: 0.151
+KVM: 0.090
+
+[Riscv-fu540] UEFI cannot be started with gdb on sifive fu540 platform？
+Description of problem:
+Using qemu start UEFI on sifive fu540 platform with option： -S -s.
+```
+qemu-system-riscv64                                            \
+                -cpu sifive-u54 -machine sifive_u               \
+                -bios U540.fd                                   \
+                -m 2048 -nographic -smp cpus=2,maxcpus=2        \
+                -S -s
+```
+UEFI url is： https://github.com/tianocore/edk2.git
+Steps to reproduce:
+1. start qemu with -S -s param in one terminal
+2. riscv64-unknown-linux-gnu-gdb in other terminal
+3. in gdb terminal:
+```
+       target remove :1234
+       c
+```
+4. in qemu terminal, there has no any output ?
diff --git a/results/classifier/118/device/175 b/results/classifier/118/device/175
new file mode 100644
index 00000000..94f2a980
--- /dev/null
+++ b/results/classifier/118/device/175
@@ -0,0 +1,31 @@
+device: 0.823
+network: 0.635
+arm: 0.528
+performance: 0.513
+graphic: 0.409
+debug: 0.379
+VMM: 0.361
+register: 0.353
+risc-v: 0.342
+boot: 0.336
+ppc: 0.325
+socket: 0.291
+files: 0.250
+TCG: 0.239
+architecture: 0.188
+kernel: 0.177
+KVM: 0.150
+PID: 0.147
+hypervisor: 0.110
+semantic: 0.098
+i386: 0.090
+peripherals: 0.090
+vnc: 0.085
+virtual: 0.077
+x86: 0.056
+assembly: 0.055
+user-level: 0.051
+mistranslation: 0.046
+permissions: 0.033
+
+qmp monitor deadlock (with spice events for ex)
diff --git a/results/classifier/118/device/1754 b/results/classifier/118/device/1754
new file mode 100644
index 00000000..e239f659
--- /dev/null
+++ b/results/classifier/118/device/1754
@@ -0,0 +1,46 @@
+device: 0.852
+performance: 0.808
+architecture: 0.782
+graphic: 0.781
+files: 0.712
+mistranslation: 0.667
+register: 0.490
+PID: 0.489
+boot: 0.483
+hypervisor: 0.482
+kernel: 0.481
+semantic: 0.470
+x86: 0.464
+i386: 0.460
+permissions: 0.452
+vnc: 0.424
+peripherals: 0.395
+assembly: 0.372
+debug: 0.371
+ppc: 0.367
+socket: 0.339
+user-level: 0.304
+network: 0.289
+arm: 0.277
+VMM: 0.274
+risc-v: 0.261
+KVM: 0.260
+TCG: 0.207
+virtual: 0.105
+
+QEMU wrongly requires SD card sizes to be a power of two
+Description of problem:
+QEMU arbitrarily requires SD card sizes to be a power of 2. However, this behavior does not match the real world, and I am unable to pass a *physical* SD card into the guest operating system.
+```
+$ sudo qemu-system-aarch64 -M raspi2b -drive file=/dev/mmcblk0,if=sd,format=raw
+qemu-system-aarch64: Invalid SD card size: 29.7 GiB
+SD card size has to be a power of 2, e.g. 32 GiB.
+You can resize disk images with 'qemu-img resize <imagefile> <new-size>'
+(note that this will lose data if you make the image smaller than it currently is).
+```
+Steps to reproduce:
+1. Insert a physical SD card into your host system and make a note of its device name. It will be something like `/dev/mmcblk0`
+2. Attempt to start a guest OS with the SD card attached. See the command above.
+3. You will get an error saying that the card size is not a power of two.
+Additional information:
+
diff --git a/results/classifier/118/device/1754597 b/results/classifier/118/device/1754597
new file mode 100644
index 00000000..db10d9bb
--- /dev/null
+++ b/results/classifier/118/device/1754597
@@ -0,0 +1,65 @@
+device: 0.810
+x86: 0.778
+boot: 0.762
+virtual: 0.747
+socket: 0.701
+graphic: 0.659
+architecture: 0.630
+PID: 0.617
+permissions: 0.595
+user-level: 0.588
+network: 0.577
+hypervisor: 0.559
+KVM: 0.549
+kernel: 0.532
+performance: 0.527
+risc-v: 0.516
+peripherals: 0.498
+semantic: 0.476
+files: 0.455
+mistranslation: 0.451
+ppc: 0.450
+register: 0.443
+arm: 0.430
+VMM: 0.411
+TCG: 0.402
+vnc: 0.390
+debug: 0.372
+i386: 0.337
+assembly: 0.315
+
+qemu-system-x86_64 broken on ubuntu 17.10
+
+I have run a virtual machine over the past three years without problems, but the update to Ubuntu 17.10 broke it: the machine falls into an infinite boot loop.
+
+$ qemu-system-x86_64 --version
+QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.5)
+
+$ sudo qemu-system-x86_64 -enable-kvm -usb \
+    -chardev stdio,id=char0 \
+    -device usb-host,vendorid=0x056a,productid=0x00c6 \
+    -device usb-host,vendorid=0x04a9,productid=0x2220 \
+    -soundhw all \
+    -m 2048 -cpu core2duo -machine q35  \
+    -smp 2 \
+    -device usb-mouse  \
+    -vga std  \
+    -device isa-applesmc,osk="CONFIDENTIAL" \
+    -smbios type=2 \
+    -device ide-drive,bus=ide.0,drive=HDD \
+    -drive id=HDD,if=none,cache=none,file=hdd.img \
+    -device ide-drive,bus=ide.3,drive=ScrapHDD \
+    -drive id=ScrapHDD,if=none,cache=none,file=scrap.img \
+    -netdev tap,id=net0,ifname=tap0,script=no \
+    -device e1000,netdev=net0,id=nic0,mac=00:aa:00:60:00:01
+
+$ uname -a
+Linux behemoth 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
+
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 17.10
+Release:	17.10
+Codename:	artful
+
diff --git a/results/classifier/118/device/1759 b/results/classifier/118/device/1759
new file mode 100644
index 00000000..1300321e
--- /dev/null
+++ b/results/classifier/118/device/1759
@@ -0,0 +1,40 @@
+device: 0.948
+i386: 0.935
+graphic: 0.929
+files: 0.893
+boot: 0.865
+architecture: 0.846
+PID: 0.768
+debug: 0.740
+x86: 0.728
+arm: 0.654
+vnc: 0.603
+performance: 0.543
+socket: 0.512
+register: 0.501
+TCG: 0.455
+mistranslation: 0.424
+semantic: 0.379
+ppc: 0.355
+user-level: 0.320
+network: 0.293
+VMM: 0.265
+assembly: 0.247
+permissions: 0.244
+kernel: 0.209
+risc-v: 0.196
+virtual: 0.148
+hypervisor: 0.134
+peripherals: 0.036
+KVM: 0.030
+
+qemu-system-i386 error during install windows 95/98
+Description of problem:
+Installation of the Windows starts but when Windows 95 is supposed to copy files it failes like: ![qemu803_win95](/uploads/40e94adda4cdf5c57fa751d5db04ef7b/qemu803_win95.png)
+Installation of Windows 98 failes like: ![qemu803_win98](/uploads/110ece638cd71f8ec41dd029379af807/qemu803_win98.png)
+Steps to reproduce:
+1. get boot floppy & install cd for windows 95
+2. create hard drive C image
+3. try to install Windows 95
+Additional information:
+
diff --git a/results/classifier/118/device/1759492 b/results/classifier/118/device/1759492
new file mode 100644
index 00000000..59c22f20
--- /dev/null
+++ b/results/classifier/118/device/1759492
@@ -0,0 +1,51 @@
+device: 0.852
+graphic: 0.837
+virtual: 0.819
+mistranslation: 0.697
+semantic: 0.653
+user-level: 0.648
+performance: 0.638
+network: 0.566
+hypervisor: 0.561
+i386: 0.543
+peripherals: 0.515
+register: 0.509
+files: 0.508
+permissions: 0.505
+architecture: 0.492
+debug: 0.490
+vnc: 0.472
+risc-v: 0.470
+x86: 0.459
+ppc: 0.456
+PID: 0.443
+VMM: 0.439
+socket: 0.414
+boot: 0.385
+TCG: 0.362
+assembly: 0.328
+KVM: 0.312
+kernel: 0.303
+arm: 0.240
+
+suspend/resume is not supported for vm with tpm device
+
+I have used libvirt with qemu to create a vm with tpm device, when I suspend the vm and resume it, libvirt will
+raise error:
+libvirtError: internal error: process exited while connecting to monitor: Enter char_pty_open
+I find some materials:
+https://wiki.qemu.org/Features/TPM
+https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg05355.html
+They present qemu haven't supported tpm suspend/resume, Does someone have any advice on how to resolve the problem?
+
+qemu version: 2.10.2
+vm image version: centos 7.2
+
+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/118/device/1761 b/results/classifier/118/device/1761
new file mode 100644
index 00000000..6d62d6a4
--- /dev/null
+++ b/results/classifier/118/device/1761
@@ -0,0 +1,31 @@
+device: 0.922
+architecture: 0.755
+performance: 0.709
+graphic: 0.594
+boot: 0.501
+debug: 0.485
+register: 0.468
+virtual: 0.445
+semantic: 0.335
+vnc: 0.280
+arm: 0.270
+mistranslation: 0.266
+PID: 0.197
+peripherals: 0.176
+VMM: 0.175
+permissions: 0.160
+i386: 0.159
+TCG: 0.138
+hypervisor: 0.120
+ppc: 0.098
+network: 0.076
+socket: 0.071
+user-level: 0.068
+KVM: 0.058
+x86: 0.049
+kernel: 0.045
+assembly: 0.040
+risc-v: 0.039
+files: 0.018
+
+vexpress-a9 board maps both RAM and flash at address 0
diff --git a/results/classifier/118/device/1767 b/results/classifier/118/device/1767
new file mode 100644
index 00000000..43465250
--- /dev/null
+++ b/results/classifier/118/device/1767
@@ -0,0 +1,33 @@
+device: 0.926
+performance: 0.731
+assembly: 0.514
+graphic: 0.495
+mistranslation: 0.419
+semantic: 0.375
+boot: 0.337
+debug: 0.267
+virtual: 0.240
+permissions: 0.223
+VMM: 0.205
+network: 0.191
+user-level: 0.177
+peripherals: 0.173
+ppc: 0.172
+architecture: 0.135
+PID: 0.118
+files: 0.101
+arm: 0.100
+risc-v: 0.089
+TCG: 0.087
+KVM: 0.087
+register: 0.085
+vnc: 0.030
+hypervisor: 0.028
+i386: 0.015
+kernel: 0.010
+socket: 0.008
+x86: 0.002
+
+Add iphone emulated device
+Additional information:
+
diff --git a/results/classifier/118/device/1769 b/results/classifier/118/device/1769
new file mode 100644
index 00000000..ea5d2d46
--- /dev/null
+++ b/results/classifier/118/device/1769
@@ -0,0 +1,31 @@
+device: 0.960
+ppc: 0.959
+architecture: 0.945
+hypervisor: 0.896
+virtual: 0.877
+performance: 0.859
+network: 0.674
+user-level: 0.661
+graphic: 0.627
+peripherals: 0.595
+arm: 0.561
+permissions: 0.293
+debug: 0.291
+semantic: 0.266
+register: 0.247
+mistranslation: 0.224
+boot: 0.212
+risc-v: 0.123
+files: 0.071
+PID: 0.064
+socket: 0.058
+assembly: 0.041
+VMM: 0.035
+vnc: 0.024
+TCG: 0.021
+x86: 0.016
+kernel: 0.015
+i386: 0.013
+KVM: 0.003
+
+RHEL9 ppc64le Power9 pseries guest userspace segfaults
diff --git a/results/classifier/118/device/1769067 b/results/classifier/118/device/1769067
new file mode 100644
index 00000000..6bc10b8f
--- /dev/null
+++ b/results/classifier/118/device/1769067
@@ -0,0 +1,42 @@
+device: 0.849
+network: 0.748
+virtual: 0.582
+socket: 0.561
+graphic: 0.514
+vnc: 0.466
+PID: 0.425
+hypervisor: 0.420
+performance: 0.411
+architecture: 0.411
+i386: 0.394
+boot: 0.384
+TCG: 0.370
+register: 0.364
+risc-v: 0.346
+files: 0.328
+x86: 0.319
+arm: 0.309
+VMM: 0.309
+mistranslation: 0.307
+ppc: 0.298
+kernel: 0.280
+semantic: 0.258
+peripherals: 0.248
+permissions: 0.241
+KVM: 0.193
+debug: 0.091
+user-level: 0.073
+assembly: 0.028
+
+virtio-net ignores the absence of the VIRTIO_NET_F_CTRL_VQ feature bit
+
+When negotiating virtio-net feature bits, the device ignores the absence of the VIRTIO_NET_F_CTRL_VQ bit in driver feature bits and provides three virtqueues, including the control virtqueue, even though the driver is expecting only the receive and transmit virtqueues. Looking into the source code, it appears it always assumes the presence of the control virtqueue, violating thus the VIRTIO version 1.0 specification.
+
+
+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/151
+
+
diff --git a/results/classifier/118/device/1773 b/results/classifier/118/device/1773
new file mode 100644
index 00000000..9bce94e3
--- /dev/null
+++ b/results/classifier/118/device/1773
@@ -0,0 +1,39 @@
+device: 0.961
+boot: 0.803
+graphic: 0.790
+mistranslation: 0.785
+virtual: 0.728
+VMM: 0.622
+hypervisor: 0.537
+performance: 0.521
+vnc: 0.504
+debug: 0.444
+register: 0.369
+network: 0.305
+peripherals: 0.291
+semantic: 0.283
+i386: 0.265
+architecture: 0.239
+PID: 0.227
+socket: 0.222
+risc-v: 0.221
+permissions: 0.196
+x86: 0.169
+TCG: 0.154
+arm: 0.153
+kernel: 0.138
+user-level: 0.112
+assembly: 0.088
+files: 0.086
+ppc: 0.080
+KVM: 0.039
+
+qemu does not use the mic of the webcam dedicated to the VM
+Description of problem:
+
+Steps to reproduce:
+1. plug two webcams to the desktop, one for the host and one for the VM
+2. launch QEMU VM
+3. QEMU VM take the desktop webcam mic instead of the webcam mic dedicated to the VM.
+Additional information:
+
diff --git a/results/classifier/118/device/1776 b/results/classifier/118/device/1776
new file mode 100644
index 00000000..77f2dd72
--- /dev/null
+++ b/results/classifier/118/device/1776
@@ -0,0 +1,31 @@
+device: 0.856
+arm: 0.853
+network: 0.834
+mistranslation: 0.694
+performance: 0.668
+debug: 0.558
+graphic: 0.503
+permissions: 0.495
+register: 0.482
+semantic: 0.420
+boot: 0.360
+socket: 0.293
+files: 0.281
+vnc: 0.261
+VMM: 0.244
+kernel: 0.235
+architecture: 0.211
+ppc: 0.181
+hypervisor: 0.119
+PID: 0.112
+user-level: 0.094
+peripherals: 0.090
+assembly: 0.086
+virtual: 0.067
+TCG: 0.061
+i386: 0.059
+risc-v: 0.024
+x86: 0.017
+KVM: 0.006
+
+qemu-armel SEGFAULTs when trying to map a commpage on armel
diff --git a/results/classifier/118/device/1777232 b/results/classifier/118/device/1777232
new file mode 100644
index 00000000..fb6906df
--- /dev/null
+++ b/results/classifier/118/device/1777232
@@ -0,0 +1,46 @@
+device: 0.864
+performance: 0.842
+files: 0.829
+graphic: 0.796
+ppc: 0.690
+network: 0.682
+architecture: 0.625
+semantic: 0.612
+user-level: 0.601
+mistranslation: 0.596
+permissions: 0.590
+vnc: 0.574
+VMM: 0.551
+peripherals: 0.530
+hypervisor: 0.524
+register: 0.513
+x86: 0.505
+socket: 0.497
+kernel: 0.497
+i386: 0.479
+PID: 0.456
+risc-v: 0.452
+virtual: 0.433
+debug: 0.416
+assembly: 0.401
+boot: 0.399
+TCG: 0.379
+arm: 0.337
+KVM: 0.315
+
+NVME fails on big writes
+
+NVME Compliance test 8:3.3.0 tries to write and read back big chunks of pages. Currently, on the latest QEMU operation of size 1024 blocks will fail when device is backed by a file.
+
+NVME specification has several types of data transfers from guests, one of the is the PRP list (Physical Region Page List). PRP is a list of entries pointing to pages to be written. The list it self resides in a single or multiple pages.
+
+NVME device maps the PRP list into QEMUSGList which will be me mapped into linux IO vectors. Finally, when the file driver will write the changes, it uses the posix pwritev, which fails if the number of vectors exceeds the maximum.
+
+
+NVME Compliance - https://github.com/nvmecompliance/tnvme/wiki
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1777235 b/results/classifier/118/device/1777235
new file mode 100644
index 00000000..44477145
--- /dev/null
+++ b/results/classifier/118/device/1777235
@@ -0,0 +1,46 @@
+device: 0.833
+graphic: 0.793
+network: 0.752
+mistranslation: 0.714
+socket: 0.628
+vnc: 0.627
+semantic: 0.608
+register: 0.562
+boot: 0.516
+ppc: 0.475
+architecture: 0.434
+permissions: 0.432
+risc-v: 0.429
+performance: 0.418
+VMM: 0.387
+hypervisor: 0.363
+user-level: 0.355
+files: 0.352
+assembly: 0.343
+PID: 0.326
+virtual: 0.310
+kernel: 0.301
+arm: 0.289
+debug: 0.265
+TCG: 0.246
+i386: 0.172
+x86: 0.166
+KVM: 0.127
+peripherals: 0.120
+
+NVME is missing support for Get Log Page command
+
+"Get Log Page" is a mandatory admin command by the specification (NVMe 1.2, Section 5, Figure 40) currently not implemented by device.
+
+I have a patch for that, it was designed to run NVMe for MacOS guests and implements at least the bare minimum of the spec. I'll try to polish it up and upstream it as soon as I have time.
+
+Hi Lorenz,
+Can you send your patch to the mailing list adding your Signed-off-by tag?
+See:
+https://wiki.qemu.org/Contribute/SubmitAPatch#Submitting_your_Patches
+
+
+Has this ever been sent?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1780815 b/results/classifier/118/device/1780815
new file mode 100644
index 00000000..9c406a0f
--- /dev/null
+++ b/results/classifier/118/device/1780815
@@ -0,0 +1,43 @@
+device: 0.803
+x86: 0.789
+graphic: 0.751
+architecture: 0.704
+mistranslation: 0.661
+performance: 0.659
+register: 0.638
+PID: 0.636
+semantic: 0.609
+network: 0.600
+hypervisor: 0.598
+vnc: 0.578
+files: 0.567
+socket: 0.555
+ppc: 0.551
+i386: 0.544
+risc-v: 0.542
+kernel: 0.532
+permissions: 0.507
+assembly: 0.479
+VMM: 0.460
+debug: 0.440
+boot: 0.428
+arm: 0.427
+TCG: 0.403
+peripherals: 0.392
+user-level: 0.365
+virtual: 0.320
+KVM: 0.285
+
+SDL Doesn't Rescale Image on Resolution Change
+
+Whilst in fullscreen mode, if the guest changes resolution for whatever reason, the screen doesn't update the scaling so you end up looking at only part of the screen, e.g. if the guest changes from 640x480 to 1024x768, the image will still be fullscreen, but what you're actually looking at will be the top-left most 640x480 segment of the screen stretched out.
+
+Manually going out of fullscreen mode and then back in fixes the scaling, but you have to do that every time the guest changes resolution.
+
+QEmu 2.12.0 using qemu-system-x86_64 with Arch Linux host.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1793 b/results/classifier/118/device/1793
new file mode 100644
index 00000000..6457f966
--- /dev/null
+++ b/results/classifier/118/device/1793
@@ -0,0 +1,65 @@
+device: 0.886
+performance: 0.885
+risc-v: 0.884
+kernel: 0.847
+graphic: 0.846
+architecture: 0.765
+hypervisor: 0.761
+peripherals: 0.750
+vnc: 0.719
+boot: 0.705
+ppc: 0.700
+semantic: 0.671
+network: 0.668
+files: 0.657
+assembly: 0.614
+permissions: 0.606
+register: 0.600
+mistranslation: 0.599
+socket: 0.565
+VMM: 0.536
+PID: 0.520
+debug: 0.510
+arm: 0.497
+TCG: 0.447
+virtual: 0.402
+user-level: 0.392
+x86: 0.376
+i386: 0.330
+KVM: 0.255
+
+getauxval(AT_HWCAP) returns different value under qemu-system-riscv64 and qemu-riscv64
+Description of problem:
+I have a test program that checks for the presence of the RISC-V Vector extension (RVV) via getauxval().
+
+```c
+#include <sys/auxv.h>
+#include <stdio.h>
+
+#define ISA_V_HWCAP (1 << ('v' - 'a'))
+
+void main() {
+  unsigned long hw_cap = getauxval(AT_HWCAP);
+  printf("RVV %s\n", hw_cap & ISA_V_HWCAP ? "detected" : "not found");
+}
+```
+
+When run inside `qemu-system-riscv64` with a 6.5-rc3 kernel where `CONFIG_RISCV_ISA_V=y` and `CONFIG_RISCV_ISA_V_DEFAULT_ENABLE=y` it correctly shows:
+
+```
+$ ./hwcap
+RVV detected
+```
+
+However when executed with `qemu-riscv64` it does not return the V bit set:
+
+```
+$ qemu-riscv64 hwcap
+RVV not found
+```
+Steps to reproduce:
+1. Boot 6.5-rc3 kernel with `CONFIG_RISCV_ISA_V=y` and `CONFIG_RISCV_ISA_V_DEFAULT_ENABLE=y`
+2. In guest run test program hwcap (source above)
+3. On host run `qemu-riscv64 hwcap`
+Additional information:
+
diff --git a/results/classifier/118/device/1794 b/results/classifier/118/device/1794
new file mode 100644
index 00000000..cc32370e
--- /dev/null
+++ b/results/classifier/118/device/1794
@@ -0,0 +1,57 @@
+device: 0.952
+kernel: 0.945
+graphic: 0.903
+performance: 0.899
+debug: 0.882
+architecture: 0.876
+files: 0.858
+hypervisor: 0.850
+PID: 0.841
+assembly: 0.832
+register: 0.814
+mistranslation: 0.813
+semantic: 0.808
+ppc: 0.807
+socket: 0.772
+user-level: 0.761
+virtual: 0.760
+x86: 0.757
+permissions: 0.755
+arm: 0.738
+risc-v: 0.737
+vnc: 0.728
+TCG: 0.720
+network: 0.699
+i386: 0.681
+boot: 0.663
+VMM: 0.644
+peripherals: 0.619
+KVM: 0.599
+
+Virtio-GPU doesn't fill Response data for cursor queue
+Description of problem:
+Implementation of virtio-gpu in Qemu is likely not fill Response header in cursor commands.
+
+Inside the virtio 1.2 specification, document said:
+```
+VIRTIO_GPU_CMD_UPDATE_CURSOR
+    Update cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA.
+    Full cursor update. Cursor will be loaded from the specified resource_id and will be moved to pos. The driver must 
+    transfer the cursor into the resource beforehand (using control queue commands) and make sure the commands to fill 
+    the resource are actually processed (using fencing).
+
+VIRTIO_GPU_CMD_MOVE_CURSOR
+    Move cursor. Request data is struct virtio_gpu_update_cursor. Response type is VIRTIO_GPU_RESP_OK_NODATA.
+    Move cursor to the place specified in pos. The other fields are not used and will be ignored by the device.
+```
+The cursor commands do have a response like control commands.
+
+But in [hw/display/virtio-gpu.c#L1136](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu.c#L1136), QEMU doesn't care anything about response, just fetching command and execute.
+
+It this a Implementation compromise or I missing something in the specification?
+Steps to reproduce:
+1. Write any kernel that using virtio-gpu.
+2. Run on qemu.
+3. No response on cursor command.
+Additional information:
+Specification: [virtio-v1.2-cs01.html](https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-3650007)
diff --git a/results/classifier/118/device/1794187 b/results/classifier/118/device/1794187
new file mode 100644
index 00000000..eb8d933e
--- /dev/null
+++ b/results/classifier/118/device/1794187
@@ -0,0 +1,60 @@
+device: 0.902
+architecture: 0.852
+performance: 0.830
+files: 0.819
+socket: 0.788
+vnc: 0.777
+ppc: 0.774
+network: 0.741
+permissions: 0.734
+graphic: 0.728
+PID: 0.724
+register: 0.723
+kernel: 0.672
+VMM: 0.648
+boot: 0.641
+risc-v: 0.639
+semantic: 0.638
+mistranslation: 0.631
+hypervisor: 0.594
+arm: 0.543
+peripherals: 0.531
+TCG: 0.531
+virtual: 0.513
+i386: 0.503
+x86: 0.466
+debug: 0.458
+user-level: 0.411
+KVM: 0.335
+assembly: 0.279
+
+improve error message, when using raspi3 and RAM>4G
+
+Running `qemu-system-aarch64 image-aarch64.iso --machine raspi3 -m 8G` prints this error message:
+
+```
+Unexpected error in visit_type_uintN() at /builddir/build/BUILD/qemu-3.0.0/qapi/qapi-visit-core.c:164:
+qemu-system-aarch64: Parameter 'vcram-base' expects uint32_t
+```
+
+The problem is, that you musn't use more than 4 GB RAM for machine raspi3. As it took me some time to figure that out, I'd be glad, if you can print better error message, like you do, when using more than 4 CPU cores with machine raspi3:
+
+```
+Invalid SMP CPUs 8. The max CPUs supported by machine 'raspi3' is 4 
+```
+
+I've submitted a patch to the list: http://patchwork.ozlabs.org/patch/1067963/
+
+With it, QEMU will give this error instead:
+
+qemu-system-aarch64: Requested ram size is too large for this machine: maximum is 1GB
+
+(Note that the maximum is 1GB, not 4GB -- it's just that values between 1 and 4GB happened not to make QEMU crash, though it wouldn't handle them very usefully before.)
+
+
+Improved diagnostic message is now in master and will be in QEMU 4.1.
+
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ff3dcf28c0b7a3ac261
+
diff --git a/results/classifier/118/device/1794939 b/results/classifier/118/device/1794939
new file mode 100644
index 00000000..c2a7bf56
--- /dev/null
+++ b/results/classifier/118/device/1794939
@@ -0,0 +1,68 @@
+device: 0.875
+files: 0.851
+network: 0.841
+socket: 0.803
+semantic: 0.788
+ppc: 0.779
+register: 0.769
+virtual: 0.760
+architecture: 0.758
+PID: 0.748
+mistranslation: 0.740
+performance: 0.725
+kernel: 0.721
+vnc: 0.705
+permissions: 0.687
+hypervisor: 0.671
+user-level: 0.660
+TCG: 0.647
+boot: 0.646
+arm: 0.642
+risc-v: 0.638
+peripherals: 0.636
+debug: 0.631
+i386: 0.617
+graphic: 0.582
+VMM: 0.580
+x86: 0.555
+KVM: 0.446
+assembly: 0.438
+
+QEMU does not build with vte v2.91
+
+when I build qemu with vte support and vte-2.91 installed I get the following deprecation warning:
+
+error: ‘vte_terminal_set_encoding’ is deprecated [-Werror=deprecated-declarations]
+     vte_terminal_set_encoding(VTE_TERMINAL(vc->vte.terminal), "UTF-8", NULL);
+     ^~~~~~~~~~~~~~~~~~~~~~~~~
+In file included from /usr/include/vte-2.91/vte/vte.h:35
+
+I looked for the commit in vte that deprecated the offending function (a17e714d), which led me to the thread:
+
+https://gitlab.gnome.org/GNOME/vte/issues/3
+
+It looks like from this version forward vte forces us to use utf-8, such that this function call becomes unnecessary in QEMU.
+
+Cheers,
+Bastian
+
+Hi Bastian,
+
+I got past this error by installing libvte-dev instead of libvte-2.91-dev.
+
+I'm not sure if it actually works however.
+
+Cheers,
+Berg
+
+
+
+Hi Berg,
+
+thanks for the tip, a fix has also been commited already :)
+
+Cheers,
+Bastian
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6415994ffcc6d22b3f5a
+
diff --git a/results/classifier/118/device/1797 b/results/classifier/118/device/1797
new file mode 100644
index 00000000..155378d7
--- /dev/null
+++ b/results/classifier/118/device/1797
@@ -0,0 +1,33 @@
+device: 0.888
+graphic: 0.583
+mistranslation: 0.497
+arm: 0.484
+semantic: 0.410
+performance: 0.386
+boot: 0.311
+register: 0.219
+architecture: 0.201
+network: 0.183
+debug: 0.143
+risc-v: 0.106
+ppc: 0.095
+files: 0.085
+permissions: 0.083
+vnc: 0.075
+hypervisor: 0.069
+peripherals: 0.040
+PID: 0.035
+user-level: 0.035
+kernel: 0.024
+virtual: 0.014
+i386: 0.013
+x86: 0.012
+assembly: 0.005
+TCG: 0.004
+socket: 0.002
+VMM: 0.001
+KVM: 0.000
+
+RAM-backed snapshotting
+Additional information:
+And thank you for QEMU! 🙂
diff --git a/results/classifier/118/device/1798 b/results/classifier/118/device/1798
new file mode 100644
index 00000000..c9cbb287
--- /dev/null
+++ b/results/classifier/118/device/1798
@@ -0,0 +1,31 @@
+device: 0.817
+network: 0.736
+boot: 0.605
+performance: 0.589
+kernel: 0.476
+arm: 0.390
+semantic: 0.370
+assembly: 0.328
+graphic: 0.323
+architecture: 0.305
+peripherals: 0.222
+debug: 0.220
+VMM: 0.205
+i386: 0.185
+ppc: 0.178
+x86: 0.156
+TCG: 0.144
+hypervisor: 0.130
+vnc: 0.123
+virtual: 0.116
+mistranslation: 0.114
+KVM: 0.113
+PID: 0.076
+files: 0.043
+user-level: 0.042
+risc-v: 0.042
+socket: 0.026
+permissions: 0.025
+register: 0.019
+
+conversions of malloc/calloc/free to g_malloc/g_new/g_free etc
diff --git a/results/classifier/118/device/1800088 b/results/classifier/118/device/1800088
new file mode 100644
index 00000000..e247be47
--- /dev/null
+++ b/results/classifier/118/device/1800088
@@ -0,0 +1,43 @@
+device: 0.833
+graphic: 0.759
+network: 0.754
+PID: 0.749
+performance: 0.694
+KVM: 0.691
+socket: 0.642
+semantic: 0.635
+ppc: 0.634
+vnc: 0.599
+debug: 0.592
+architecture: 0.566
+kernel: 0.528
+register: 0.522
+risc-v: 0.514
+user-level: 0.506
+permissions: 0.504
+peripherals: 0.504
+arm: 0.497
+files: 0.484
+x86: 0.479
+i386: 0.459
+boot: 0.452
+VMM: 0.436
+TCG: 0.412
+mistranslation: 0.388
+virtual: 0.329
+hypervisor: 0.322
+assembly: 0.256
+
+Assertion fail while usb camera redirect
+
+This may happen during usb camera redirect. But if i move the camera lens from left to right or up to down, this always happen. My qemu-version is 2.10.0 and following is the error information:
+
+2018-10-26T03:37:54.925231Z qemu-kvm: usbredirparser: error unexpected extra data ep 00
+qemu-kvm: hw/usb/redirect.c:1313: usbredir_chardev_read: Assertion `dev->read_buf == ((void *)0)' failed.
+2018-10-26 03:37:57.120+0000: shutting down, reason=crashed
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1805697 b/results/classifier/118/device/1805697
new file mode 100644
index 00000000..40b1ede0
--- /dev/null
+++ b/results/classifier/118/device/1805697
@@ -0,0 +1,89 @@
+device: 0.910
+boot: 0.893
+user-level: 0.891
+performance: 0.882
+network: 0.873
+debug: 0.855
+graphic: 0.846
+architecture: 0.836
+KVM: 0.835
+hypervisor: 0.833
+peripherals: 0.832
+x86: 0.820
+semantic: 0.811
+virtual: 0.808
+mistranslation: 0.788
+kernel: 0.778
+vnc: 0.769
+permissions: 0.769
+socket: 0.766
+ppc: 0.733
+PID: 0.724
+assembly: 0.713
+files: 0.706
+register: 0.674
+risc-v: 0.623
+VMM: 0.619
+arm: 0.591
+i386: 0.579
+TCG: 0.451
+
+egl-headless crashes
+
+egl-headless crashes when it is trying change the resolution. After XFCE login, for example.
+
+I tryed it on 2.12, 3.0 and 3.1.0-rc2 versions.
+
+# qemu-system-x86_64 -enable-kvm -enable-kvm -M q35 -smp 8 -vga virtio -spice port=59011,addr=0.0.0.0,disable-ticketing -hda image.qcow2 -m 4G -display egl-headless -chardev spicevmc,name=vdagent,id=vdagent
+
+main_channel_link: add main channel client
+main_channel_client_handle_pong: net test: latency 6.942000 ms, bitrate 8497925311 bps (8104.253112 Mbps)
+inputs_connect: inputs channel client create
+red_qxl_set_cursor_peer:
+gl_version 31 - compat profile
+qemu-system-x86_64: ui/egl-headless.c:128: egl_scanout_flush: Assertion `surface_width(edpy->ds) == edpy->guest_fb.width' failed.
+Aborted (core dumped)
+
+Is it possible to set init resolution when VM is starting?
+
+https://patchwork.ozlabs.org/patch/1005355/
+
+-device virtio-vga,xres=<width>,yres=<height>
+
+Hi, Gerd.
+
+   Thank you very match! It's work for me.
+
+   Now,  I need to contact with libvirt developers. Libvirt isn't work
+   with egl-headless. I'm trying last version (4.9.0)
+
+
+
+
+
+
+
+
+
+
+
+
+I mean this works: -device virtio-vga,xres=1920,yres=1080
+
+Not the patch. I try to patch 3.0 version. No result
+
+I have the same issue.  The patch (which is already included in my git source) did not help.  I can use the command line solution but it's not ideal as I connect to the VM from multiple computers with different resolutions.
+
+Also if I use "Auto resize VM to window" the VM immediately crashes with the error:
+
+qemu-system-x86_64: /root/qemu/ui/egl-headless.c:136: egl_scanout_flush: Assertion `surface_width(edpy->ds) == edpy->guest_fb.width' failed.
+
+
+Otherwise it is working better than I had hoped, just this small resolution issue.
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/181 b/results/classifier/118/device/181
new file mode 100644
index 00000000..3856cbf3
--- /dev/null
+++ b/results/classifier/118/device/181
@@ -0,0 +1,31 @@
+device: 0.900
+performance: 0.834
+graphic: 0.594
+arm: 0.585
+network: 0.413
+files: 0.338
+architecture: 0.245
+semantic: 0.222
+permissions: 0.197
+mistranslation: 0.172
+boot: 0.154
+VMM: 0.110
+virtual: 0.109
+register: 0.083
+vnc: 0.075
+user-level: 0.071
+ppc: 0.051
+PID: 0.048
+TCG: 0.037
+debug: 0.033
+hypervisor: 0.019
+risc-v: 0.017
+peripherals: 0.015
+socket: 0.012
+kernel: 0.010
+assembly: 0.007
+x86: 0.006
+i386: 0.004
+KVM: 0.002
+
+qemu crashes when doing iotest on  virtio-9p filesystem
diff --git a/results/classifier/118/device/1811758 b/results/classifier/118/device/1811758
new file mode 100644
index 00000000..128ded27
--- /dev/null
+++ b/results/classifier/118/device/1811758
@@ -0,0 +1,54 @@
+device: 0.828
+performance: 0.811
+semantic: 0.731
+network: 0.726
+architecture: 0.714
+ppc: 0.669
+files: 0.661
+mistranslation: 0.656
+PID: 0.650
+hypervisor: 0.645
+vnc: 0.644
+kernel: 0.641
+socket: 0.639
+user-level: 0.634
+register: 0.596
+peripherals: 0.581
+permissions: 0.537
+graphic: 0.513
+risc-v: 0.470
+virtual: 0.445
+x86: 0.429
+boot: 0.395
+VMM: 0.383
+arm: 0.379
+i386: 0.375
+TCG: 0.310
+KVM: 0.295
+assembly: 0.237
+debug: 0.201
+
+virtio-rng backend should use getentropy() syscall when available
+
+According to https://wiki.qemu.org/Features/VirtIORNG the default backend for `virtio-rng-pci` is `/dev/random`.  Alternately, the user can point it to a different backend file, like `/dev/urandom`.
+
+However, both of these files have suboptimal behavior in one way or another, as documented in `random(7)`.  Instead, the default behavior should be to pull the requested octets from the `getrandom()` system call, if available, called with no flags set.
+
+To be clear, the problem with using /dev/urandom as a backend is that it's possible to feed data from an uninitialized pool into the guest.
+
+and the problem with using /dev/random as a backend is that it's possible for a guest to starve the other host (and other guests) of entropy, since it pulls from the blocking pool.
+
+getrandom() only blocks when the CSPRNG is not initialized, otherwise it never blocks.  this is the right behavior by default.
+
+any word on this?  If this is not considered for adoption, i would like to know the reason, so that we can have better predictions about what to do for entropy in a QEMU system.
+
+Feel free to send some patches to implement this! Alternatively, you could also try to write a mail to the virtio-rng maintainer (see the MAINTAINER file in the top directory of the sources), maybe he can help.
+
+Yes, using getrandom() in qemu by default on systems that support it will be an improvement, and is the right approach.
+
+rng-builtin is the new RNG default backend for virtio-rng and is based on getrandom().
+
+0198c2621a1e virtio-rng: change default backend to rng-builtin
+5f7655f6ef15 virtio-rng: Keep the default backend out of VirtIORNGConf
+6c4e9d487fea rng-builtin: add an RNG backend that uses qemu_guest_getrandom()
+
diff --git a/results/classifier/118/device/1813307 b/results/classifier/118/device/1813307
new file mode 100644
index 00000000..87bafd8a
--- /dev/null
+++ b/results/classifier/118/device/1813307
@@ -0,0 +1,60 @@
+device: 0.893
+performance: 0.777
+graphic: 0.635
+network: 0.627
+architecture: 0.581
+ppc: 0.576
+semantic: 0.539
+files: 0.468
+i386: 0.455
+x86: 0.404
+kernel: 0.390
+register: 0.374
+vnc: 0.361
+socket: 0.349
+PID: 0.349
+arm: 0.330
+hypervisor: 0.327
+mistranslation: 0.315
+risc-v: 0.297
+permissions: 0.294
+boot: 0.282
+debug: 0.271
+peripherals: 0.249
+VMM: 0.203
+virtual: 0.201
+KVM: 0.200
+TCG: 0.199
+user-level: 0.145
+assembly: 0.102
+
+util/path.c/follow_path() does not handle "/" well
+
+Hello,
+
+I noticed that qemu does not handle "/" very well in follow_path().
+
+Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd.
+
+Indeed it does something like
+  if (__lstat ("/", &st) < 0)
+.....
+and then loops from current dir toward the top using lstat("..")
+
+On qemu side, lstat forwards the request to follow_path() in util/path.c, and when passed "/", it returns the path in QEMU_LD_PREFIX (which was the top of my sysroot).
+OTHT, the series of lstat("..") finally reaches the real device root because it's not recognized as "/" in follow_path(), so this is inconsistent and __getcwd fails.
+
+I suppose there's a good reason for returning QEMU_LD_PREFIX when asking for "/", but why is it so?
+
+If there's no good reason, maybe the behaviour could be changed to map "/" to "/" ?
+
+Thanks
+
+
+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/162
+
+
diff --git a/results/classifier/118/device/1815445 b/results/classifier/118/device/1815445
new file mode 100644
index 00000000..4f4c35bb
--- /dev/null
+++ b/results/classifier/118/device/1815445
@@ -0,0 +1,50 @@
+device: 0.921
+graphic: 0.873
+performance: 0.735
+mistranslation: 0.694
+semantic: 0.511
+architecture: 0.452
+debug: 0.440
+ppc: 0.439
+vnc: 0.429
+files: 0.416
+user-level: 0.393
+socket: 0.362
+register: 0.293
+boot: 0.275
+PID: 0.256
+network: 0.249
+risc-v: 0.242
+permissions: 0.236
+virtual: 0.229
+TCG: 0.215
+peripherals: 0.214
+i386: 0.213
+kernel: 0.210
+x86: 0.210
+arm: 0.198
+VMM: 0.188
+assembly: 0.168
+KVM: 0.098
+hypervisor: 0.086
+
+change and eject commands are not working on an overlay
+
+From qemu monitor, 'change' and 'eject' commands are not working on a CD overlay.
+'info block' returns:
+  cd0-overlay0: /home/guillaume/test/cd0-overlay0 (qcow2)
+    Attached to:      cd0-device
+    Removable device: not locked, tray closed
+    Cache mode:       writeback, ignore flushes
+    Backing file:     /home/guillaume/test.iso (chain depth: 1)
+
+But 'eject cd0-overlay0' returns:
+  Device 'cd0-overlay0' not found
+I also tried 'cd0-device' and 'cd0'.
+
+Same problem with 'change' command.
+
+Can you please provide your QEMU version, command line, and any QMP/HMP commands you issued, and the expected/desired effect?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/182 b/results/classifier/118/device/182
new file mode 100644
index 00000000..3ef8b2a0
--- /dev/null
+++ b/results/classifier/118/device/182
@@ -0,0 +1,31 @@
+device: 0.946
+network: 0.831
+architecture: 0.768
+socket: 0.711
+arm: 0.633
+performance: 0.612
+PID: 0.507
+peripherals: 0.491
+debug: 0.462
+boot: 0.440
+VMM: 0.435
+vnc: 0.417
+register: 0.364
+permissions: 0.360
+graphic: 0.356
+i386: 0.343
+x86: 0.319
+semantic: 0.273
+TCG: 0.246
+ppc: 0.240
+virtual: 0.233
+hypervisor: 0.131
+mistranslation: 0.128
+kernel: 0.109
+KVM: 0.097
+assembly: 0.061
+risc-v: 0.049
+files: 0.036
+user-level: 0.034
+
+qemu-xhci device should detect if libusb host supports streams
diff --git a/results/classifier/118/device/1821131 b/results/classifier/118/device/1821131
new file mode 100644
index 00000000..18588297
--- /dev/null
+++ b/results/classifier/118/device/1821131
@@ -0,0 +1,64 @@
+device: 0.841
+graphic: 0.819
+vnc: 0.809
+ppc: 0.800
+debug: 0.728
+VMM: 0.724
+semantic: 0.714
+hypervisor: 0.651
+risc-v: 0.617
+socket: 0.616
+user-level: 0.594
+virtual: 0.549
+performance: 0.548
+x86: 0.525
+network: 0.518
+PID: 0.515
+architecture: 0.506
+i386: 0.489
+KVM: 0.482
+register: 0.475
+arm: 0.461
+peripherals: 0.449
+assembly: 0.439
+mistranslation: 0.429
+kernel: 0.404
+permissions: 0.395
+boot: 0.389
+TCG: 0.369
+files: 0.368
+
+VM running under latest Qemu receives 2, 3, 8, and = when sent the keysyms for @, #, *, and + respectively
+
+Git commit hash where bug was reproduced: 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2
+
+A user of my application bVNC reported that when he connects to his VMs running under Qemu, he cannot send @, #, and *. Instead, 2, 3, and 8 appear in the VM respectively. I built the latest Qemu from source, and reproduced the issue.
+
+bVNC converts keycodes or unicode characters that the Android keyboard sends it to corresponding keysyms. For example, it sends keysym 64 for @ rather than sending SHIFT+2.
+
+A debug log of the application sending the keysyms shows metaState == 0, indicating lack of modifier keys. 
+
+When 2 appears in place of @:
+
+03-21 00:11:21.761  8864  8864 I RemoteKeyboard: Sending key. Down: true, key: 64. keysym:64, metaState: 0
+03-21 00:11:21.763  8864  8864 I RemoteKeyboard: Sending key. Down: false, key: 64. keysym:64, metaState: 0
+
+When 3 appears in place of #:
+
+03-21 00:11:08.947  8864  8864 I RemoteKeyboard: Sending key. Down: true, key: 35. keysym:35, metaState: 0
+03-21 00:11:08.950  8864  8864 I RemoteKeyboard: Sending key. Down: false, key: 35. keysym:35, metaState: 0
+
+When 0 appears instead of *:
+
+03-21 00:11:28.586  8864  8864 I RemoteKeyboard: Sending key. Down: true, key: 42. keysym:42, metaState: 0
+03-21 00:11:28.588  8864  8864 I RemoteKeyboard: Sending key. Down: false, key: 42. keysym:42, metaState: 0
+
+When = appears instead of +:
+03-21 01:05:40.021 10061 10061 I RemoteKeyboard: Sending key. Down: true, key: 43. keysym:43, metaState: 0
+03-21 01:05:40.022 10061 10061 I RemoteKeyboard: Sending key. Down: false, key: 43. keysym:43, metaState: 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 mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1821884 b/results/classifier/118/device/1821884
new file mode 100644
index 00000000..0a5d05fe
--- /dev/null
+++ b/results/classifier/118/device/1821884
@@ -0,0 +1,59 @@
+device: 0.847
+architecture: 0.812
+files: 0.787
+user-level: 0.776
+register: 0.772
+socket: 0.771
+ppc: 0.755
+performance: 0.749
+semantic: 0.735
+PID: 0.713
+permissions: 0.712
+risc-v: 0.712
+kernel: 0.683
+network: 0.679
+graphic: 0.674
+arm: 0.668
+peripherals: 0.630
+boot: 0.615
+vnc: 0.609
+mistranslation: 0.602
+VMM: 0.593
+TCG: 0.534
+virtual: 0.523
+i386: 0.474
+hypervisor: 0.470
+KVM: 0.464
+x86: 0.445
+assembly: 0.385
+debug: 0.356
+
+Extend uefi-test-tools to report SMBIOS location
+
+UEFI helper app exposes the pointer to RSDP ACPI table that firmware allocates in guest's RAM
+but it doesn't do so for SMBIOS tables. Hence bios table test would skip testing SMBIOS tables
+to workaround shortcoming. This bug is a request to expose two new entry point fields (one for SMBIOS 2 and another for SMBIOS 3) so test could check SMBIOS tables when guest is started a with  UEFI firmware.
+
+Discussion on qemu-devel:
+[Qemu-devel] [PATCH for 4.1 v2 09/13] tests: acpi: ignore SMBIOS tests when UEFI firmware is used
+http://mid<email address hidden>
+https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07037.html
+
+I'll work on this once Igor's above series is merged (which in turn depends on my series
+[Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU
+http://<email address hidden>
+https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06148.html
+)
+
+Posted
+[PATCH 0/2] tests/uefi-test-tools: report the SMBIOS entry point structures
+http://<email address hidden>
+
+
+Posted
+[PULL 0/2] tests/uefi-test-tools: report the SMBIOS entry point structures
+http://<email address hidden>
+
+
+Fixed in commit range 8482ff2eb3bb..24496b8d27d9.
+
diff --git a/results/classifier/118/device/1824853 b/results/classifier/118/device/1824853
new file mode 100644
index 00000000..4197b4ce
--- /dev/null
+++ b/results/classifier/118/device/1824853
@@ -0,0 +1,110 @@
+device: 0.923
+debug: 0.914
+boot: 0.897
+architecture: 0.891
+register: 0.891
+arm: 0.885
+mistranslation: 0.880
+performance: 0.879
+PID: 0.866
+permissions: 0.861
+socket: 0.851
+virtual: 0.842
+kernel: 0.842
+TCG: 0.841
+ppc: 0.840
+graphic: 0.834
+network: 0.828
+risc-v: 0.827
+assembly: 0.818
+semantic: 0.818
+peripherals: 0.786
+user-level: 0.783
+hypervisor: 0.776
+KVM: 0.760
+vnc: 0.751
+files: 0.712
+VMM: 0.687
+x86: 0.637
+i386: 0.547
+
+4.0.0-rc3 crashes with tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed
+
+I tried to bootstrap and regtested gcc trunk (gcc svn rev 270278, datestamp 20190411) inside my arm64-gentoo installation under qemu-system-aarch64.
+
+Qemu version was 4.0.0-rc3 and -cpu cortex-a57. Qemu configured with only --target-list=aarch64-softmmu,aarch64-linux-user and compiled using gcc "version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1~16.04)".
+
+Executable created from gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX.c compiled with -O2 crashed the whole qemu-system.
+
+To investigate a bit I also manually run
+~/gcc/inst/trunk/bin/gcc ~/gcc/src/trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX.c
+with different options like:
+-O0 -lm -o d0.exe
+-O1 -lm -o d1.exe
+-O2 -lm -o d2.exe
+-O0 -static -lm -o s0.exe
+-O1 -static -lm -o s1.exe
+-O2 -static -lm -o s2.exe
+
+So, now I have 6 different arm64 executables created with different optimization levels. O0 and O1 versions run ok.
+Three sN.exe static executables I've also tried in qemu user mode (with same -cpu), no issue in user mode.
+
+And inside qemu-system I can see that
+running "d2.exe" (attached) gives:
+tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed.
+
+And running "s2.exe" gives:
+tcg/tcg.c:320: set_jmp_reset_offset: Assertion `s->tb_jmp_reset_offset[which] == off' failed.
+
+It seems like this test is an counter-example for logic that "tcg_ctx->nb_ops < 4000" implies tcg will fit into 16-bit signed size (see tcg_op_buf_full comments).
+
+Richard's changes in abebf92597186 and 9f754620651d were not enough, translation block must be smaller, or we have to find some proper way to bail out when buffer overflows.
+I don't know why this situation is not caught by code_gen_highwater logic in tcg.c
+
+I've also tried this "bail out" patch
+
+diff --git a/tcg/tcg.c b/tcg/tcg.c
+--- a/tcg/tcg.c
++++ b/tcg/tcg.c
+@@ -3949,7 +3949,8 @@ int tcg_gen_code(TCGContext *s, TranslationBlock *tb)
+                 size_t off = tcg_current_code_size(s);
+                 s->gen_insn_end_off[num_insns] = off;
+                 /* Assert that we do not overflow our stored offset.  */
+-                assert(s->gen_insn_end_off[num_insns] == off);
++                if (s->gen_insn_end_off[num_insns] != off)
++                  return -1;
+             }
+             num_insns++;
+             for (i = 0; i < TARGET_INSN_START_WORDS; ++i) {
+
+But then running "d2.exe" just hangs the whole qemu-system. It seems that when tcg_gen_code return -1 (like in highwater logic mentioned before), we just re-call it again and again.
+
+
+
+Also attaching static-compiled executable "s2.exe".
+
+Returning -1 does not help because all that signals that the buffer is full.
+We then flush the buffer and try again, assuming the at the buffer will not fill.
+Given that the buffer is usually many megabytes, this is reasonable.
+
+We need something different to signal that the buffer is not full, but that
+another offset has overflowed.
+
+Patch set posted:
+https://patchwork.ozlabs.org/project/qemu-devel/list/?series=102978
+
+
+
+Richard, thank you for solving this so fast!
+I certainly can confirm attached executables work fine for me on patched version.
+
+I'll also re-run full gcc regtest a bit later, but it runs for a rather long time, not sure this result will be important next week.
+
+Hopefully, patchset will be included into 4 release.
+
+Unfortunately the fix is too big for this point in the 4.0 release cycle; it'll go into 4.1.
+
+
+The fix should now be in git master (commits 8b86d6d25807e13a6 and 6e6c4efed995d9ec), so it will be in the 4.1 release.
+
+
diff --git a/results/classifier/118/device/1831477 b/results/classifier/118/device/1831477
new file mode 100644
index 00000000..855211e8
--- /dev/null
+++ b/results/classifier/118/device/1831477
@@ -0,0 +1,51 @@
+device: 0.883
+graphic: 0.844
+network: 0.841
+socket: 0.799
+vnc: 0.798
+kernel: 0.763
+PID: 0.755
+files: 0.747
+ppc: 0.739
+TCG: 0.678
+risc-v: 0.669
+register: 0.662
+semantic: 0.656
+VMM: 0.634
+mistranslation: 0.634
+architecture: 0.621
+boot: 0.613
+permissions: 0.603
+user-level: 0.580
+arm: 0.570
+i386: 0.548
+hypervisor: 0.508
+x86: 0.503
+KVM: 0.474
+assembly: 0.457
+performance: 0.455
+virtual: 0.422
+debug: 0.422
+peripherals: 0.373
+
+update edk2 submodule & binaries to edk2-stable201905
+
+The edk2 project will soon release edk2-stable201905. Update the edk2 submodule in QEMU, and the bundled edk2 binaries, accordingly.
+
+https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable201905-tag-planning
+https://github.com/tianocore/edk2/releases/tag/edk2-stable201905 [upcoming link]
+
+Some rebase notes can be seen at <https://bugzilla.redhat.com/show_bug.cgi?id=1701710#c12>.
+
+Posted
+[PATCH 0/6] update edk2 submodule & binaries to edk2-stable201905
+http://<email address hidden>
+
+
+[PULL 0/6] update edk2 submodule & binaries to edk2-stable201905
+http://<email address hidden>
+
+
+Merged in commit 53defa05701b ("Merge remote-tracking branch 'remotes/lersek/tags/edk2-pull-2019-06-14' into staging", 2019-06-17).
+
+
diff --git a/results/classifier/118/device/1839 b/results/classifier/118/device/1839
new file mode 100644
index 00000000..f15201ff
--- /dev/null
+++ b/results/classifier/118/device/1839
@@ -0,0 +1,71 @@
+device: 0.874
+boot: 0.751
+VMM: 0.751
+risc-v: 0.726
+kernel: 0.719
+KVM: 0.669
+x86: 0.669
+arm: 0.631
+ppc: 0.610
+graphic: 0.606
+network: 0.588
+hypervisor: 0.569
+semantic: 0.540
+architecture: 0.538
+user-level: 0.511
+i386: 0.486
+vnc: 0.483
+debug: 0.476
+register: 0.473
+PID: 0.459
+TCG: 0.454
+peripherals: 0.451
+performance: 0.450
+socket: 0.411
+virtual: 0.411
+assembly: 0.291
+permissions: 0.164
+mistranslation: 0.115
+files: 0.016
+
+command line option (fw_cfg) not being treated as opaque and generates error "short-form boolean option 'x' deprecated"
+Description of problem:
+I'm trying to run qemu with `fw_cfg` arguments. With a full example I am trying to provide an ignition configuration a flatcar VM using a 'string' parameter which is JSON (rather than a file parameter).
+
+Running qemu with command line options where the fields have arbitrary data that should be opaque to qemu are being interpreted and cause the command line argument parsing the fail. I have tried putting quotes and double quotes around various parts of the command without success.
+
+
+Sorry, but I haven't tested this with latest (v8.1.0.rc4 / v8.0.4)
+
+Examples:
+
+```# qemu-system-x86_64 -fw_cfg name=z,string=a,b
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated
+Please use b=on instead
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b'
+```
+
+Single quotes around the `string` value:
+```
+# qemu-system-x86_64 -fw_cfg name=z,string='a,b'
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated
+Please use b=on instead
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b'
+```
+
+Double quotes around the `string` value
+```
+# qemu-system-x86_64 -fw_cfg name=z,string="a,b"
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated
+Please use b=on instead
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b'
+
+```
+
+Double quotes around the whole `fw_cfg` option value:
+```
+# qemu-system-x86_64 -fw_cfg "name=z,string=a,b"
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: warning: short-form boolean option 'b' deprecated
+Please use b=on instead
+qemu-system-x86_64: -fw_cfg name=z,string=a,b: Invalid parameter 'b'
+```
diff --git a/results/classifier/118/device/184 b/results/classifier/118/device/184
new file mode 100644
index 00000000..601e46fe
--- /dev/null
+++ b/results/classifier/118/device/184
@@ -0,0 +1,31 @@
+architecture: 0.991
+device: 0.964
+performance: 0.894
+graphic: 0.742
+arm: 0.629
+network: 0.610
+assembly: 0.536
+boot: 0.502
+risc-v: 0.463
+kernel: 0.365
+x86: 0.298
+i386: 0.291
+debug: 0.289
+semantic: 0.263
+ppc: 0.226
+hypervisor: 0.185
+peripherals: 0.160
+socket: 0.135
+KVM: 0.135
+VMM: 0.124
+PID: 0.119
+register: 0.114
+permissions: 0.106
+vnc: 0.103
+mistranslation: 0.099
+virtual: 0.069
+user-level: 0.060
+TCG: 0.041
+files: 0.040
+
+SSE CMP ops with 8bit immediate throw sigill with oversized byte
diff --git a/results/classifier/118/device/1843 b/results/classifier/118/device/1843
new file mode 100644
index 00000000..54fc78af
--- /dev/null
+++ b/results/classifier/118/device/1843
@@ -0,0 +1,45 @@
+device: 0.883
+graphic: 0.667
+performance: 0.433
+debug: 0.428
+PID: 0.372
+semantic: 0.332
+mistranslation: 0.247
+peripherals: 0.189
+arm: 0.184
+boot: 0.146
+socket: 0.144
+network: 0.092
+virtual: 0.091
+user-level: 0.085
+kernel: 0.084
+risc-v: 0.083
+assembly: 0.080
+permissions: 0.075
+hypervisor: 0.062
+register: 0.060
+vnc: 0.060
+TCG: 0.050
+i386: 0.048
+ppc: 0.042
+files: 0.040
+VMM: 0.037
+architecture: 0.037
+x86: 0.022
+KVM: 0.007
+
+Multitouch - GTK:  Tapping 3 points or more at too close in interval causes all points to be lost
+Description of problem:
+When using the new multitouch input device, if you use three or more fingers within two rapid interval, the all finger inputs get dropped.
+Steps to reproduce:
+ANDROID
+1. Download and install BlissOS
+2. Swipe with two fingers
+3. try multitouch debug app
+
+FEDORA
+1. Load fedora
+2. install wev
+3. try touch 3 or more points
+Additional information:
+Not sure what logs are relevant
diff --git a/results/classifier/118/device/1844644 b/results/classifier/118/device/1844644
new file mode 100644
index 00000000..66970a4b
--- /dev/null
+++ b/results/classifier/118/device/1844644
@@ -0,0 +1,40 @@
+device: 0.888
+network: 0.724
+socket: 0.664
+architecture: 0.638
+graphic: 0.554
+peripherals: 0.475
+files: 0.440
+arm: 0.376
+kernel: 0.374
+semantic: 0.311
+performance: 0.297
+boot: 0.283
+permissions: 0.262
+risc-v: 0.234
+hypervisor: 0.213
+vnc: 0.213
+user-level: 0.185
+register: 0.147
+virtual: 0.141
+debug: 0.139
+ppc: 0.136
+PID: 0.115
+x86: 0.105
+i386: 0.098
+VMM: 0.082
+mistranslation: 0.079
+assembly: 0.066
+TCG: 0.030
+KVM: 0.015
+
+Compiler warnings using MSVC
+
+The following line of code results in an implicit truncation of an uint16_t value to an uint8_t variable, which triggers a compiler warning in MSVC : https://github.com/qemu/qemu/blob/f8c3db33a5e863291182f8862ddf81618a7c6194/hw/usb/dev-hub.c#L387
+(Two lines down, the same thing happens.)
+
+This warning can be silenced by doing an explicit truncation, for example by a casting the value explicitly to uint8_t type, or by anding the value with 0xFF.
+
+Hi; MSVC is not a supported compiler for QEMU. We expect it to be built with either gcc or llvm.
+
+
diff --git a/results/classifier/118/device/1847 b/results/classifier/118/device/1847
new file mode 100644
index 00000000..0b87d6b2
--- /dev/null
+++ b/results/classifier/118/device/1847
@@ -0,0 +1,31 @@
+device: 0.924
+architecture: 0.858
+network: 0.675
+mistranslation: 0.555
+performance: 0.496
+arm: 0.491
+graphic: 0.358
+debug: 0.344
+boot: 0.304
+semantic: 0.297
+peripherals: 0.179
+assembly: 0.175
+hypervisor: 0.160
+ppc: 0.143
+virtual: 0.136
+kernel: 0.075
+user-level: 0.058
+i386: 0.058
+PID: 0.058
+risc-v: 0.058
+files: 0.050
+register: 0.046
+permissions: 0.042
+socket: 0.030
+VMM: 0.020
+TCG: 0.017
+vnc: 0.017
+x86: 0.013
+KVM: 0.003
+
+TriCore missing ftoq31, ftoq31z, and q31tof instructions
diff --git a/results/classifier/118/device/1853 b/results/classifier/118/device/1853
new file mode 100644
index 00000000..c128ba41
--- /dev/null
+++ b/results/classifier/118/device/1853
@@ -0,0 +1,31 @@
+device: 0.846
+hypervisor: 0.541
+network: 0.537
+architecture: 0.535
+arm: 0.526
+debug: 0.483
+graphic: 0.407
+boot: 0.379
+performance: 0.294
+semantic: 0.206
+socket: 0.194
+i386: 0.187
+mistranslation: 0.168
+x86: 0.163
+ppc: 0.158
+register: 0.150
+permissions: 0.138
+files: 0.138
+vnc: 0.115
+peripherals: 0.071
+assembly: 0.062
+virtual: 0.060
+risc-v: 0.055
+PID: 0.046
+kernel: 0.033
+TCG: 0.010
+user-level: 0.009
+VMM: 0.004
+KVM: 0.001
+
+Errors when install QEMU from source code
diff --git a/results/classifier/118/device/1853898 b/results/classifier/118/device/1853898
new file mode 100644
index 00000000..afbdf1e8
--- /dev/null
+++ b/results/classifier/118/device/1853898
@@ -0,0 +1,70 @@
+device: 0.846
+network: 0.754
+x86: 0.747
+socket: 0.656
+graphic: 0.652
+KVM: 0.627
+kernel: 0.605
+files: 0.597
+user-level: 0.588
+architecture: 0.581
+performance: 0.567
+permissions: 0.552
+PID: 0.546
+mistranslation: 0.544
+peripherals: 0.534
+debug: 0.523
+semantic: 0.506
+hypervisor: 0.485
+boot: 0.456
+vnc: 0.455
+ppc: 0.433
+arm: 0.393
+i386: 0.383
+register: 0.379
+virtual: 0.337
+risc-v: 0.330
+VMM: 0.265
+TCG: 0.247
+assembly: 0.245
+
+qemu/hw/scsi/lsi53c895a.c:417: lsi_soft_reset: Assertion `QTAILQ_EMPTY(&s->queue)' failed.
+
+While experimenting with blkdebug I can consistently hit this assertion in lsi53c895a.c.
+
+Using locally built from master, commit: 2061735ff09f9d5e67c501a96227b470e7de69b1
+
+Steps to reproduce
+
+$ qemu-img create -f raw empty.raw 8G
+$ sudo losetup -f --show empty.raw
+$ sudo mkfs.ext3 /dev/loop0
+$ sudo losetup -D
+
+$ cat blkdebug.conf 
+[inject-error]
+event = "read_aio"
+errno = "5"
+
+$ qemu-system-x86_64 -enable-kvm -m 2048 -cpu host -smp 4 -nic user,ipv6=off,model=e1000,hostfwd=tcp::2222-:22,net=172.16.0.0/255.255.255.0 -device lsi53c895a,id=scsi -device scsi-hd,drive=hd,wwn=12345678 -drive if=scsi,id=hd,file=blkdebug:blkdebug.conf:empty.raw,cache=none,format=raw -cdrom Fedora-Server-dvd-x86_64-31-1.9.iso -display gtk
+
+Initiate install from cdrom ISO image results in:
+
+qemu-system-x86_64: /builddir/build/BUILD/qemu-3.1.1/hw/scsi/lsi53c895a.c:381: lsi_soft_reset: Assertion `QTAILQ_EMPTY(&s->queue)' failed.
+Aborted (core dumped)
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1854878 b/results/classifier/118/device/1854878
new file mode 100644
index 00000000..022a6407
--- /dev/null
+++ b/results/classifier/118/device/1854878
@@ -0,0 +1,78 @@
+device: 0.964
+graphic: 0.923
+mistranslation: 0.836
+ppc: 0.816
+user-level: 0.783
+semantic: 0.751
+performance: 0.734
+x86: 0.694
+PID: 0.608
+peripherals: 0.598
+permissions: 0.568
+architecture: 0.523
+files: 0.468
+kernel: 0.450
+socket: 0.438
+hypervisor: 0.417
+debug: 0.394
+boot: 0.389
+i386: 0.377
+network: 0.370
+risc-v: 0.337
+vnc: 0.334
+register: 0.318
+arm: 0.314
+TCG: 0.284
+KVM: 0.281
+VMM: 0.277
+assembly: 0.251
+virtual: 0.093
+
+Physical USB thumbdrive treated as read-only
+
+So I have installed FreeDOS on my USB thumbdrive, by using Rufus. Everything goes as expected so far. That's good.
+
+When I run QEMU with this command line:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1
+
+it of course is read-only, just like the resulting console message says:
+WARNING: Image format was not specified for '\\.\PhysicalDrive1' 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.
+
+
+So what I then did, was I ran QEMU with this command line:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw
+
+As expected, the above mentioned console message no longer appears.
+However, beyond that, QEMU doesn't behave as it should regarding read-only status. When I try any operation that involves writing to the drive, it becomes quite clear that the drive is still read-only. Any writing operations to the drive result in FreeDOS giving me the error message:
+Error writing to drive C: DOS area: sector not found.
+
+The above situation is clearly a bug. QEMU should not be treating it as read-only once I specify format=raw.
+
+Note that drive C is how the guest OS refers to the USB thumbdrive (it's drive E in my host OS, and drive C in my host OS is the actual system drive).
+
+And yes, it is a QEMU bug. It's not a FreeDOS bug I tested it with this command line, so that all changes would be written to a temporary snapshot file:
+qemu-system-x86_64.exe -drive file=\\.\PhysicalDrive1,format=raw,snapshot
+That last drive option "snapshot" tells QEMU to create a temporary snapshot file, and to write all changes to that. When I do that, all write operations are successful. So it seems that there is a bug in QEMU where it keeps read-only mode in place for a physical drive, even when format=raw is specified. Please fix this bug. Thanks in advance.
+
+Here's my current setup.
+Host OS: Windows 10 (64bit)
+Guest OS: FreeDOS
+QEMU version: 4.1.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/118/device/1859 b/results/classifier/118/device/1859
new file mode 100644
index 00000000..3dbbb555
--- /dev/null
+++ b/results/classifier/118/device/1859
@@ -0,0 +1,38 @@
+device: 0.944
+boot: 0.937
+graphic: 0.934
+debug: 0.826
+performance: 0.783
+socket: 0.736
+register: 0.690
+semantic: 0.674
+files: 0.674
+TCG: 0.657
+kernel: 0.651
+vnc: 0.646
+arm: 0.598
+risc-v: 0.581
+ppc: 0.538
+VMM: 0.528
+architecture: 0.459
+mistranslation: 0.423
+permissions: 0.341
+PID: 0.331
+user-level: 0.311
+network: 0.218
+virtual: 0.063
+peripherals: 0.035
+assembly: 0.029
+i386: 0.018
+x86: 0.012
+hypervisor: 0.012
+KVM: 0.002
+
+Trying to boot Windows Server 2008 Windows Host
+Description of problem:
+On Windows 10 trying to boot Windows Server 2008 R2 I am just stuck on starting Windows if I do get past Starting Windows it just goes to 0x0000007F BSOD
+Steps to reproduce:
+1. Run Windows Server with my command line input
+2. Stuck on Starting Windows
+Additional information:
+![Capture](/uploads/d46fb1980c1b57fed6e0b7d1af98fbaa/Capture.PNG)
diff --git a/results/classifier/118/device/1861458 b/results/classifier/118/device/1861458
new file mode 100644
index 00000000..fe54362d
--- /dev/null
+++ b/results/classifier/118/device/1861458
@@ -0,0 +1,60 @@
+device: 0.888
+performance: 0.727
+graphic: 0.679
+semantic: 0.622
+mistranslation: 0.589
+architecture: 0.564
+ppc: 0.530
+kernel: 0.458
+hypervisor: 0.453
+permissions: 0.447
+virtual: 0.445
+KVM: 0.440
+peripherals: 0.397
+register: 0.372
+user-level: 0.341
+boot: 0.337
+debug: 0.325
+arm: 0.320
+PID: 0.311
+x86: 0.306
+i386: 0.294
+network: 0.290
+socket: 0.279
+vnc: 0.248
+files: 0.230
+risc-v: 0.183
+TCG: 0.152
+VMM: 0.135
+assembly: 0.131
+
+Clock drift issue with -soundhw hda
+
+Here's the scenario: I'm working on code for loopback audio recording (i.e. recording what you're hearing) using WASAPI on Windows. As I usually develop on Linux, I'm using qemu to test this on a Windows 10 VM. The heart of WASAPI audio recording is the IAudioCaptureClient::GetBuffer function (https://docs.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudiocaptureclient-getbuffer). Among other things, this function produces a timestamp for when the audio buffer it returned is supposed to be played.
+
+When the audio device in question is the qemu hda device, this timestamp is wrong.
+
+There is a clock drift error (I measured it to be about 0.1%, i.e. 1ms drift every second = a full second after 16 minutes) that causes the audio clock to advance faster than the system clock. Paradoxically, this does not affect audio playback through qemu at all, no delay there. Only the timestamps returned to recording applications are completely bogus.
+
+Unfortunately I'm not intimately familiar with the inner workings of Intel HD Audio. All I can tell you is that this timestamp is supposedly obtained directly from the hardware (which would be qemu in this case), which is also why e.g. chromium implements a workaround for buggy hardware that returns incorrect timestamps.
+
+Here are the relevant parts of my command line (version 4.2.0):
+-enable-kvm -machine pc-q35-3.1,kernel-irqchip=on -cpu host,kvm=off,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=NvidiaFuckU -rtc base=localtime -nodefaults -soundhw hda
+
+Just wanted to let you know about this because it took me three days of utter confusion and frustration to figure this out.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1864 b/results/classifier/118/device/1864
new file mode 100644
index 00000000..6e767799
--- /dev/null
+++ b/results/classifier/118/device/1864
@@ -0,0 +1,51 @@
+x86: 0.985
+device: 0.955
+architecture: 0.922
+graphic: 0.920
+hypervisor: 0.874
+performance: 0.871
+TCG: 0.862
+vnc: 0.841
+debug: 0.721
+files: 0.710
+PID: 0.673
+ppc: 0.673
+semantic: 0.643
+risc-v: 0.599
+i386: 0.598
+permissions: 0.546
+kernel: 0.526
+socket: 0.485
+boot: 0.485
+register: 0.453
+network: 0.410
+peripherals: 0.393
+arm: 0.378
+mistranslation: 0.368
+user-level: 0.363
+virtual: 0.304
+VMM: 0.222
+KVM: 0.216
+assembly: 0.144
+
+x86 VM with TCG and SMP fails to start on 8.1.0
+Description of problem:
+I'm running Colima on MacOS to run Docker. After upgrading qemu to 8.1.0 my x86_64 VM fails to start. If I downgrade qemu to 8.0.4 everything runs normally. Relevant logs:
+
+```
+[   60.976187] rcu: 	0-...!: (0 ticks this GP) idle=0d58/0/0x0 softirq=44/44 fqs=0 (false positive?)
+[   60.979262] 	(detected by 1, t=6005 jiffies, g=-1171, q=1981 ncpus=2)
+[   60.982317] Sending NMI from CPU 1 to CPUs 0:
+[   11.583693] NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0xb/0x10
+[   11.583693] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to run: 2.006 msecs
+[   60.982317] rcu: rcu_preempt kthread timer wakeup didn't happen for 6004 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
+[   60.982317] rcu: 	Possible timer handling issue on cpu=0 timer-softirq=15
+[   60.982317] rcu: rcu_preempt kthread starved for 6005 jiffies! g-1171 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
+[   60.982317] rcu: 	Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
+[   60.982317] rcu: RCU grace-period kthread stack dump:
+[   60.982317] task:rcu_preempt     state:I stack:0     pid:15    ppid:2      flags:0x00004000
+```
+
+[serial.log](/uploads/1039eceff37133504eb93401df1db137/serial.log)
+Steps to reproduce:
+1. `colima start --arch x86_64`
diff --git a/results/classifier/118/device/1866792 b/results/classifier/118/device/1866792
new file mode 100644
index 00000000..a51e2c3c
--- /dev/null
+++ b/results/classifier/118/device/1866792
@@ -0,0 +1,108 @@
+device: 0.951
+kernel: 0.931
+performance: 0.908
+peripherals: 0.900
+vnc: 0.878
+assembly: 0.867
+ppc: 0.843
+graphic: 0.839
+architecture: 0.838
+user-level: 0.824
+PID: 0.819
+files: 0.810
+permissions: 0.800
+risc-v: 0.784
+debug: 0.783
+socket: 0.771
+VMM: 0.750
+x86: 0.735
+mistranslation: 0.726
+semantic: 0.712
+register: 0.682
+network: 0.640
+boot: 0.632
+hypervisor: 0.589
+TCG: 0.581
+arm: 0.533
+i386: 0.497
+virtual: 0.468
+KVM: 0.449
+
+formating vdi-disk over nbd fails
+
+Hi,
+after creating a vdi-image with qemu-vdi and attaching it with qemu-nbd partitioning works fine, but the system hangs up during formating with mkfs.ext4.
+
+Same procedure with qcow2-image works fine 
+Tested on Fedora 31 kernel  5.5.7-200.fc31.x86_64
+
+
+-----------------
+#! /bin/sh
+
+qemu-img create -f qcow2 ~/test.qcow2 32G
+#qemu-img version 4.1.1 (qemu-4.1.1-1.fc31)
+
+modprobe nbd max_part=8
+qemu-nbd --connect=/dev/nbd2 ~/test.qcow2
+#qemu-nbd 4.1.1 (qemu-4.1.1-1.fc31)
+
+parted -s /dev/nbd2 "mklabel gpt"
+parted -s -a optimal /dev/nbd2 "mkpart test ext4 2048 32G "
+parted  -s -a optimal /dev/nbd2 "p"
+
+mkfs.ext4 /dev/nbd2p1
+#Format hangs up due to IO errors.
+#Tested on Fedora 31, kernel 5.5.7-200.fc31.x86_64
+
+mkdir /mnt/test_qcow2
+
+mount /dev/nbd2p1 /mnt/test_qcow2
+df -H
+
+-------------------
+#! /bin/sh
+
+qemu-img create -f vdi ~/test.vdi 32G
+
+modprobe nbd max_part=8
+qemu-nbd --connect=/dev/nbd4 ~/test.vdi
+
+parted -s /dev/nbd4 "mklabel gpt"
+parted -s -a optimal /dev/nbd4 "mkpart test ext4 2048 32G "
+parted  -s -a optimal /dev/nbd4 "p"
+
+mkfs.ext4 /dev/nbd4p1
+#Format hangs up due to IO errors 
+#Tested on Fedora 31 kernel  5.5.7-200.fc31.x86_64
+
+mkdir /mnt/test_vdi
+
+mount /dev/nbd4p1 /mnt/test_vdi
+df -H
+----------------------
+
+
+Kind regards
+  Eilert
+
+PS.: There may be a connection to this bug:
+​ 	
+#1661758 qemu-nbd causes data corruption in VDI-format disk images
+
+
+
+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/118/device/187 b/results/classifier/118/device/187
new file mode 100644
index 00000000..4d1bfc1b
--- /dev/null
+++ b/results/classifier/118/device/187
@@ -0,0 +1,31 @@
+architecture: 0.974
+arm: 0.953
+device: 0.946
+kernel: 0.900
+performance: 0.732
+graphic: 0.651
+peripherals: 0.621
+network: 0.544
+debug: 0.543
+risc-v: 0.491
+PID: 0.455
+semantic: 0.436
+permissions: 0.378
+mistranslation: 0.326
+TCG: 0.321
+register: 0.277
+socket: 0.259
+boot: 0.232
+KVM: 0.227
+VMM: 0.227
+user-level: 0.090
+virtual: 0.073
+assembly: 0.073
+ppc: 0.073
+hypervisor: 0.052
+vnc: 0.050
+files: 0.042
+x86: 0.005
+i386: 0.004
+
+Cannot boot arm kernel images on s390x
diff --git a/results/classifier/118/device/1871005 b/results/classifier/118/device/1871005
new file mode 100644
index 00000000..cb5d2502
--- /dev/null
+++ b/results/classifier/118/device/1871005
@@ -0,0 +1,51 @@
+device: 0.856
+architecture: 0.738
+performance: 0.607
+register: 0.579
+files: 0.568
+graphic: 0.543
+mistranslation: 0.533
+vnc: 0.506
+risc-v: 0.504
+ppc: 0.504
+user-level: 0.488
+semantic: 0.484
+hypervisor: 0.469
+network: 0.450
+virtual: 0.449
+permissions: 0.448
+arm: 0.424
+socket: 0.402
+boot: 0.349
+debug: 0.326
+kernel: 0.324
+PID: 0.319
+TCG: 0.288
+peripherals: 0.284
+assembly: 0.213
+x86: 0.208
+VMM: 0.187
+KVM: 0.076
+i386: 0.071
+
+build fails on CLOCK_MONOTONIC
+
+Moc OS X.11.6 El Capitan
+
+build fails on this 
+
+/Users/alba/Downloads/qemu-5.0.0-rc1/include/qemu/timer.h:843:9: warning: 
+      implicit declaration of function 'clock_gettime' is invalid in C99
+      [-Wimplicit-function-declaration]
+        clock_gettime(CLOCK_MONOTONIC, &ts);
+        ^
+/Users/alba/Downloads/qemu-5.0.0-rc1/include/qemu/timer.h:843:23: error: use of
+      undeclared identifier 'CLOCK_MONOTONIC'
+        clock_gettime(CLOCK_MONOTONIC, &ts);
+                      ^
+1 warning and 1 error generated.
+make: *** [trace/control.o] Error 1
+
+Hi; I'm afraid that OSX 10.11 "El Capitan" isn't a supported build platform for QEMU. Our official support policy is that we support the two most recent versions (currently 10.14 Mojave and 10.15 Catalina); QEMU may also run on some earlier OSX versions we don't support, but we don't guarantee that or carry workarounds for missing functionality on those earlier versions. In this particular case, CLOCK_MONOTONIC was added to OSX 10.12 "Sierra".
+
+
diff --git a/results/classifier/118/device/1874486 b/results/classifier/118/device/1874486
new file mode 100644
index 00000000..1a59a1ae
--- /dev/null
+++ b/results/classifier/118/device/1874486
@@ -0,0 +1,144 @@
+device: 0.909
+register: 0.903
+permissions: 0.898
+PID: 0.886
+semantic: 0.885
+debug: 0.884
+virtual: 0.882
+assembly: 0.879
+architecture: 0.860
+files: 0.859
+graphic: 0.854
+ppc: 0.854
+arm: 0.850
+performance: 0.849
+boot: 0.846
+mistranslation: 0.822
+peripherals: 0.818
+vnc: 0.789
+hypervisor: 0.785
+socket: 0.766
+VMM: 0.754
+TCG: 0.708
+risc-v: 0.697
+user-level: 0.688
+x86: 0.578
+network: 0.573
+KVM: 0.565
+kernel: 0.477
+i386: 0.299
+
+Bug in qemu-img when converting to streamOptimized vmdk images
+
+I reviewed #1006655, and I think I'm already on a newer version, so this is either a regression or a new bug.
+
+I have been recently attempting to convert images from raw and qcow2 formats to vmdk. It appears that the option "subformat=streamOptimized" produces a broken or corrupted disk image.
+
+Current versions, running on Devuan testing:
+
+ii  ipxe-qemu                                 1.0.0+git-20190125.36a4c85-1                all          PXE boot firmware - ROM images for qemu
+ii  qemu                                      1:3.1+dfsg-8+deb10u4                        amd64        fast processor emulator, dummy package
+ii  qemu-efi-aarch64                          0~20181115.85588389-3                       all          UEFI firmware for 64-bit ARM virtual machines
+ii  qemu-efi-arm                              0~20181115.85588389-3                       all          UEFI firmware for 32-bit ARM virtual machines
+ii  qemu-kvm                                  1:3.1+dfsg-8+deb10u4                        amd64        QEMU Full virtualization on x86 hardware
+ii  qemu-slof                                 20180702+dfsg-1                             all          Slimline Open Firmware -- QEMU PowerPC version
+ii  qemu-system                               1:3.1+dfsg-8+deb10u4                        amd64        QEMU full system emulation binaries
+ii  qemu-system-arm                           1:3.1+dfsg-8+deb10u4                        amd64        QEMU full system emulation binaries (arm)
+ii  qemu-system-common                        1:3.1+dfsg-8+deb10u4                        amd64        QEMU full system emulation binaries (common files)
+ii  qemu-system-data                          1:3.1+dfsg-8+deb10u4                        all          QEMU full system emulation (data files)
+ii  qemu-system-gui                           1:3.1+dfsg-8+deb10u4                        amd64        QEMU full system emulation binaries (user interface and audio support)
+ii  qemu-system-mips                          1:3.1+dfsg-8+deb10u4                        amd64        QEMU full system emulation binaries (mips)
+ii  qemu-system-misc                          1:3.1+dfsg-8+deb10u4                        amd64        QEMU full system emulation binaries (miscellaneous)
+ii  qemu-system-ppc                           1:3.1+dfsg-8+deb10u4                        amd64        QEMU full system emulation binaries (ppc)
+ii  qemu-system-sparc                         1:3.1+dfsg-8+deb10u4                        amd64        QEMU full system emulation binaries (sparc)
+ii  qemu-system-x86                           1:3.1+dfsg-8+deb10u4                        amd64        QEMU full system emulation binaries (x86)
+ii  qemu-utils                                1:3.1+dfsg-8+deb10u4                        amd64        QEMU utilities
+
+Current uname -a:
+Linux laptop-dev 5.4.0-0.bpo.3-amd64 #1 SMP Debian 5.4.13-1~bpo10+1 (2020-02-07) x86_64 GNU/Linux
+
+Current CPU info:
+$ cat /proc/cpuinfo
+processor       : 0
+vendor_id       : GenuineIntel
+cpu family      : 6
+model           : 158
+model name      : Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
+stepping        : 10
+microcode       : 0xca
+cpu MHz         : 800.109
+cache size      : 9216 KB
+physical id     : 0
+siblings        : 12
+core id         : 0
+cpu cores       : 6
+apicid          : 0
+initial apicid  : 0
+fpu             : yes
+fpu_exception   : yes
+cpuid level     : 22
+wp              : yes
+flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
+bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
+bogomips        : 4399.99
+clflush size    : 64
+cache_alignment : 64
+address sizes   : 39 bits physical, 48 bits virtual
+power management:
+
+$ cat /proc/meminfo
+MemTotal:       16098356 kB
+MemFree:         2292720 kB
+MemAvailable:   12323616 kB
+
+
+Steps to reproduce:
+1) Create a base o/s image in .qcow2 or raw format. I am using a Debian 10 (buster) image, and my images are created using packer 1.5.5.
+2) Verify that the base image in .qcow2 format boots correctly in virt-manager when attached to a new VM.
+3) Convert the image to vmdk using the following command:
+qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,hwversion=6 <image name>.qcow2 <image name>.vmdk
+4) Create a new VM using the newly-created .vmdk, being sure to make the storage adapter SCSI
+Result: The image, on boot, will display many disk read errors. It will boot, but will start in read-only mode.
+
+This same image will also not boot correctly in ESXi or VirtualBox. In any of the three hypervisor environments, the bootloader menu (grub2) shows up correctly, but the machine will fail to boot correctly.
+
+
+I reviewed the vmdk header, and the output is here:
+
+dd if=base.vmdk of=output-vm-disk1.descriptor bs=1 skip=512 count=1024
+
+$ cat output-vm-disk1.descriptor 
+# Disk DescriptorFile
+version=1
+CID=2120740c
+parentCID=ffffffff
+createType="streamOptimized"
+
+# Extent description
+RW 61440000 SPARSE "base.vmdk"
+
+# The Disk Data Base
+#DDB
+
+ddb.virtualHWVersion = "6"
+ddb.geometry.cylinders = "3824"
+ddb.geometry.heads = "255"
+ddb.geometry.sectors = "63"
+ddb.adapterType = "lsilogic"
+
+Removing the "subformat=streamOptimized" argument from the qemu-img conversion command results in a working, albeit much larger image, with no disk read errors.
+
+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/118/device/1875080 b/results/classifier/118/device/1875080
new file mode 100644
index 00000000..7ae980f9
--- /dev/null
+++ b/results/classifier/118/device/1875080
@@ -0,0 +1,54 @@
+device: 0.952
+graphic: 0.864
+network: 0.719
+performance: 0.697
+architecture: 0.695
+socket: 0.691
+peripherals: 0.662
+user-level: 0.650
+semantic: 0.636
+kernel: 0.632
+mistranslation: 0.624
+permissions: 0.561
+files: 0.535
+arm: 0.516
+PID: 0.503
+vnc: 0.500
+risc-v: 0.500
+register: 0.492
+ppc: 0.458
+i386: 0.454
+boot: 0.442
+x86: 0.437
+debug: 0.418
+VMM: 0.400
+virtual: 0.381
+KVM: 0.305
+TCG: 0.271
+assembly: 0.257
+hypervisor: 0.236
+
+USB host device data transfer with control endpoint
+
+QEMU emulator version 4.2.0
+Host -> Arch Linux kernel version: 5.4.34-1-lts
+Guest -> Various Linux Distros
+
+I sent a control message with data through endpoint zero.
+On the other side message is received with all fields correct except data buffer.
+I've tested the data field inside guest with usbmon and data field was correct but after packet leaved qemu, data filed is lost.
+
+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/118/device/1880 b/results/classifier/118/device/1880
new file mode 100644
index 00000000..e9e5ddcb
--- /dev/null
+++ b/results/classifier/118/device/1880
@@ -0,0 +1,43 @@
+device: 0.930
+boot: 0.875
+kernel: 0.862
+graphic: 0.825
+architecture: 0.717
+semantic: 0.599
+vnc: 0.550
+socket: 0.541
+risc-v: 0.485
+network: 0.468
+PID: 0.468
+performance: 0.456
+i386: 0.434
+ppc: 0.414
+debug: 0.407
+register: 0.364
+TCG: 0.353
+x86: 0.323
+permissions: 0.308
+VMM: 0.294
+arm: 0.293
+files: 0.269
+mistranslation: 0.263
+hypervisor: 0.242
+user-level: 0.228
+KVM: 0.175
+peripherals: 0.167
+virtual: 0.097
+assembly: 0.083
+
+CXL Mem enable error
+Description of problem:
+During the process of booting, the following info indicate that the CXL Mem is not enabled.
+```
+Media not active (-16)
+probe of mem0 failed with error -16
+```
+Steps to reproduce:
+1. Compile Linux kernel v5.18 as shown in the QEMU doc
+2. Run the above-mentioned script
+3. Check the booting script
+Additional information:
+Could you give me some hints of how to operate on the CXL device properly? Thanks a lot.
diff --git a/results/classifier/118/device/1882787 b/results/classifier/118/device/1882787
new file mode 100644
index 00000000..3f087ccb
--- /dev/null
+++ b/results/classifier/118/device/1882787
@@ -0,0 +1,97 @@
+device: 0.937
+socket: 0.908
+graphic: 0.904
+hypervisor: 0.881
+register: 0.874
+files: 0.872
+PID: 0.864
+peripherals: 0.842
+ppc: 0.841
+risc-v: 0.841
+performance: 0.824
+network: 0.821
+architecture: 0.818
+arm: 0.818
+assembly: 0.806
+debug: 0.778
+semantic: 0.771
+boot: 0.765
+permissions: 0.760
+vnc: 0.755
+TCG: 0.747
+kernel: 0.727
+user-level: 0.704
+VMM: 0.703
+virtual: 0.679
+x86: 0.658
+i386: 0.635
+mistranslation: 0.632
+KVM: 0.580
+
+AUD_set_volume_out takes SWVoiceOut as parameter, but controls HWVoiceOut
+
+There was a change in https://github.com/qemu/qemu/commit/571a8c522e0095239598347ac0add93337c1e0bf#diff-230ab01fa7fb1668a1e9183241115cb0R1852-R1853 (audio/audio.c) which breaks audio output on devices which have multiple software voices on the same hardware voice.
+
+When multiple software voices use the same hardware voice, then setting a volume / mute for any of the software voices, will affect all other software voices, too.
+
+I'm not sure if such a use-case exists in QEMU; however, it does exist in my fork.
+It's also easy to see that this is a bug in the QEMU audio subsystem.
+
+The API (and broken function) for this is:
+
+```
+    void AUD_set_volume_out (SWVoiceOut *sw, int mute, uint8_t lvol, uint8_t rvol)
+```
+
+So this is supposed to modify the SWVoiceOut.
+
+However, if the backend supports `pcm_ops->volume_out` this does not work as expected. It's always as if you had called:
+
+```
+    void AUD_set_volume_out (HWVoiceOut *hw, int mute, uint8_t lvol, uint8_t rvol)
+```
+
+*(Note how this modifies the hardware voice)*
+
+
+In my specific use case, I have 2 outputs (digital and analog audio on AC97), and I want to mute the digital audio output, but I still need to keep the voice activated for timing.
+However, if I mute the digital audio SWVoiceOut, it will also affect the other SWVoiceOut (for analog audio) on the same HWVoiceOut.
+
+---
+
+Old code - if the hardware supports volume changes, it will receive the software voice which should be modified, so changes can be restricted to that one voice:
+
+```
+        HWVoiceOut *hw = sw->hw;
+        [...]
+        if (hw->pcm_ops->ctl_out) {
+            hw->pcm_ops->ctl_out (hw, VOICE_VOLUME, sw);
+        }
+```
+
+New code - the hardware backend will have no way to differentiate software voices; so any change will affect all voices. The volume which was set last on any sw voice will set a global volume / mute for all voices on the hardware backend:
+
+```
+        HWVoiceOut *hw = sw->hw;
+        [...]
+        if (hw->pcm_ops->volume_out) {
+            hw->pcm_ops->volume_out(hw, &sw->vol);
+        }
+```
+
+The old interface was already broken with some (all?) backends, because they ignored the software voice, but at least the design made sense.
+However, the new design is fundamentally broken because it doesn't even tell the backend which voice is supposed to be modified.
+
+---
+
+Bug was introduced in cecc1e79bf9ad9a0e2d3ce513d4f71792a0985f6
+The affected code was touched since then, but still remains in 49ee11555262a256afec592dfed7c5902d5eefd2
+
+
+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/74
+
+
diff --git a/results/classifier/118/device/1887 b/results/classifier/118/device/1887
new file mode 100644
index 00000000..e91498a9
--- /dev/null
+++ b/results/classifier/118/device/1887
@@ -0,0 +1,39 @@
+device: 0.906
+architecture: 0.881
+graphic: 0.800
+debug: 0.712
+performance: 0.670
+arm: 0.643
+vnc: 0.596
+semantic: 0.578
+PID: 0.537
+risc-v: 0.532
+boot: 0.527
+virtual: 0.526
+register: 0.497
+permissions: 0.477
+mistranslation: 0.448
+VMM: 0.433
+network: 0.400
+ppc: 0.331
+hypervisor: 0.327
+TCG: 0.326
+user-level: 0.325
+files: 0.260
+socket: 0.253
+peripherals: 0.213
+x86: 0.182
+assembly: 0.137
+KVM: 0.135
+kernel: 0.095
+i386: 0.081
+
+Window VM failed to resume when using GPU passthrough(GVT-d) on Intel platform if add 'hv-stimer' option, seems like it happened after V6.2.0
+Description of problem:
+Windows VM failed to be resumed if adding 'hv-stimer' after Qemu v6.2.0.
+Steps to reproduce:
+1.Set up GVTd env and launch Windows 10 VM as guest;
+2. Sleep the Windows VM with Sleep button;
+3. Resume Windows VM via telnet to qemu ,e.g.,'telnet 127.0.0.1 2222', then input 'system_wakeup' to resume Windows VM.
+Additional information:
+
diff --git a/results/classifier/118/device/1888 b/results/classifier/118/device/1888
new file mode 100644
index 00000000..36740beb
--- /dev/null
+++ b/results/classifier/118/device/1888
@@ -0,0 +1,42 @@
+device: 0.940
+kernel: 0.940
+graphic: 0.937
+debug: 0.650
+semantic: 0.644
+PID: 0.528
+peripherals: 0.504
+architecture: 0.491
+performance: 0.455
+hypervisor: 0.436
+network: 0.416
+ppc: 0.415
+boot: 0.301
+socket: 0.297
+x86: 0.287
+vnc: 0.277
+mistranslation: 0.272
+i386: 0.266
+virtual: 0.259
+register: 0.234
+assembly: 0.227
+arm: 0.226
+permissions: 0.224
+user-level: 0.180
+risc-v: 0.140
+VMM: 0.138
+TCG: 0.134
+KVM: 0.049
+files: 0.048
+
+megasas: Buffer I/O error on dev sda / critical target error, dev sda, sector 0 op 0x0:(READ)
+Description of problem:
+Since QEMU 7.2.0 when using `megasas` device the guest kernel is unable to I/O with the device (Input/output error) also producing errors messages in `dmesg` like these:
+```
+[   18.739344] critical target error, dev sda, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
+[   18.739925] Buffer I/O error on dev sda, logical block 0, async page read
+[   18.740374] Dev sda: unable to read RDB block 0
+```
+
+Relevant options are: `-device megasas -blockdev driver=null-co,read-zeroes=on,node-name=null -device scsi-hd,drive=null` then in guest `modprobe megaraid-sas`. With qcow2 images - errors are the same.
+
+I also tested that the same commands produce no errors on QEMU 6.0.0 - 7.1.0.
diff --git a/results/classifier/118/device/1898 b/results/classifier/118/device/1898
new file mode 100644
index 00000000..24c0c262
--- /dev/null
+++ b/results/classifier/118/device/1898
@@ -0,0 +1,62 @@
+device: 0.845
+graphic: 0.773
+performance: 0.701
+permissions: 0.701
+vnc: 0.674
+ppc: 0.641
+architecture: 0.619
+files: 0.618
+risc-v: 0.590
+kernel: 0.560
+PID: 0.533
+VMM: 0.485
+socket: 0.465
+network: 0.448
+boot: 0.437
+debug: 0.431
+user-level: 0.409
+register: 0.394
+TCG: 0.361
+peripherals: 0.348
+semantic: 0.334
+arm: 0.285
+mistranslation: 0.256
+assembly: 0.199
+x86: 0.099
+i386: 0.099
+hypervisor: 0.098
+virtual: 0.095
+KVM: 0.057
+
+Ninja makeserver support
+Description of problem:
+Building `qemu` using a patched version of `ninja`[0] to utilize `make`'s jobserver feature doesn't work when building `qemu`. Usually, when using a jobserver to control the number of jobs being built in parallel across multiple different builds (i.e. when building with `open-embedded` or `buildroot`), the `-j$(nproc)` argument is left out. In this case, the `Qemu` `Makefile` interprets the absent `-j` argument as a wish for a single process only, and adds a `-j1` argument to the `ninja` call.
+Steps to reproduce:
+1. Built/install the patched `ninja` from [0]: `export PATH=<path/to/ninja>:$PATH`
+2. Start the attached [jobserver.py](/uploads/8215e8a470c97cd456d2d14e2c71c6a5/jobserver.py) script: `python jobserver.py /tmp/jobserver 4`
+3. Configure `qemu`: `mkdir build; ../configure`
+4. Build `qemu`: `MAKEFLAGS="--jobserver-auth=fifo:/tmp/jobserver" make`
+5. Observe that only a single CPU/core is being used.
+
+Now, to avoid passing `-j1` to `ninja`, remove filtering of `-j` arguments from the `Makefile`:
+
+```patch
+diff --git a/Makefile b/Makefile
+index bfc4b2c8e9..d66141787e 100644
+--- a/Makefile
++++ b/Makefile
+@@ -142,7 +142,6 @@ MAKE.k = $(findstring k,$(firstword $(filter-out --%,$(MAKEFLAGS))))
+ MAKE.q = $(findstring q,$(firstword $(filter-out --%,$(MAKEFLAGS))))
+ MAKE.nq = $(if $(word 2, $(MAKE.n) $(MAKE.q)),nq)
+ NINJAFLAGS = $(if $V,-v) $(if $(MAKE.n), -n) $(if $(MAKE.k), -k0) \
+-        $(filter-out -j, $(lastword -j1 $(filter -l% -j%, $(MAKEFLAGS)))) \
+         -d keepdepfile
+ ninja-cmd-goals = $(or $(MAKECMDGOALS), all)
+ ninja-cmd-goals += $(foreach g, $(MAKECMDGOALS), $(.ninja-goals.$g))
+```
+
+Run the build again, and see four jobs being run in parallel:
+
+`make clean; MAKEFLAGS="--jobserver-auth=fifo:/tmp/jobserver" make`
+Additional information:
+[0] https://github.com/stefanb2/ninja/tree/topic-issue-1139-part-3-jobserver-fifo
diff --git a/results/classifier/118/device/1901068 b/results/classifier/118/device/1901068
new file mode 100644
index 00000000..41cce5b3
--- /dev/null
+++ b/results/classifier/118/device/1901068
@@ -0,0 +1,75 @@
+device: 0.878
+files: 0.813
+user-level: 0.799
+graphic: 0.756
+mistranslation: 0.700
+architecture: 0.683
+performance: 0.674
+hypervisor: 0.664
+PID: 0.651
+debug: 0.639
+permissions: 0.636
+network: 0.636
+vnc: 0.617
+semantic: 0.613
+virtual: 0.596
+kernel: 0.593
+ppc: 0.589
+risc-v: 0.589
+x86: 0.581
+register: 0.578
+VMM: 0.565
+i386: 0.562
+TCG: 0.561
+peripherals: 0.555
+assembly: 0.548
+socket: 0.542
+KVM: 0.508
+arm: 0.450
+boot: 0.418
+
+Deleted tests are still run if they exist in the build tree
+
+Steps to reproduce:
+1. Add a new device along with a qtest to exercise it.
+2. Run make check-qtest. It passes.
+3. Revert the commit that added the device and qtest.
+4. Run make check-qtest again. It now fails because the device no longer exists, but the test is somehow still there even though the source files are gone and it's not mentioned in tests/qtest/meson.build.
+
+After running make clean, make check-qtest passes again.
+
+$ git describe
+v5.1.0-2465-g4c5b97bfd0
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1902262 b/results/classifier/118/device/1902262
new file mode 100644
index 00000000..dac01d9a
--- /dev/null
+++ b/results/classifier/118/device/1902262
@@ -0,0 +1,83 @@
+device: 0.873
+graphic: 0.782
+files: 0.762
+mistranslation: 0.747
+virtual: 0.742
+user-level: 0.738
+peripherals: 0.721
+performance: 0.682
+architecture: 0.669
+hypervisor: 0.666
+PID: 0.644
+semantic: 0.642
+network: 0.626
+kernel: 0.616
+permissions: 0.602
+vnc: 0.599
+VMM: 0.564
+KVM: 0.557
+ppc: 0.534
+x86: 0.530
+i386: 0.501
+risc-v: 0.497
+assembly: 0.481
+arm: 0.475
+register: 0.473
+socket: 0.450
+TCG: 0.440
+boot: 0.435
+debug: 0.402
+
+vmstate_load_state return error into virtio_load function
+
+Qemu version 4.2.1
+
+In the function of virtio_load, the vmstate_load_state will return error in the following case.
+
+The virtio is legacy mode(disable-modern=on,disable-legacy=off), virtio_device is in reset state. 
+
+In the the function of "vmstate_load_state", it will load all subsection. For the vmstate_virtio_extra_state subsection. 
+It will execute:
+vmstate_load_state   -->
+          ret = field->info->get(f, curr_elem, size, field);    line 143  vmstate.c.
+           -->virtio_pci_load_extra_state
+                        -->  vmstate_load_state
+                                 -->qemu_peek_byte
+But if the f->buf_index is same with buf_size, qemu_peek_byte function will set "-EIO" error. 
+the field->info->get will return 0, then it will get the error "ret = qemu_file_get_error(f);". then the vmstate_load_state will return error.
+
+It output is "Failed to load virtio/extra_state:extra_state"
+
+Can you also reproduce this with the latest version of QEMU? Anyway:
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1902306 b/results/classifier/118/device/1902306
new file mode 100644
index 00000000..1c4bb712
--- /dev/null
+++ b/results/classifier/118/device/1902306
@@ -0,0 +1,73 @@
+device: 0.942
+virtual: 0.893
+PID: 0.875
+graphic: 0.845
+peripherals: 0.845
+ppc: 0.816
+performance: 0.802
+files: 0.793
+network: 0.765
+user-level: 0.765
+permissions: 0.749
+debug: 0.746
+vnc: 0.743
+risc-v: 0.741
+architecture: 0.741
+hypervisor: 0.699
+socket: 0.690
+boot: 0.685
+i386: 0.679
+VMM: 0.669
+kernel: 0.657
+x86: 0.644
+register: 0.641
+KVM: 0.630
+semantic: 0.623
+mistranslation: 0.612
+TCG: 0.597
+assembly: 0.592
+arm: 0.452
+
+Allow setting usb storage device ID parameters
+
+Some stubborn software requires certain VID/PID/Serial to authenticate and refuses to start in emulation. This poses a problem with unsupported programs which often require keeping an ancient hardware praying that the USB stick will not die before the (often defunct) company making it.
+
+Virtualizing such environment is desired. However, QEMU doesn't allow setting VID/PID/Serial/Name of emulated USB devices, but instead uses hardcoded values: https://github.com/qemu/qemu/blob/c99fa56b95a72f6debd50a280561895d078ae020/hw/usb/dev-storage.c#L95
+
+This request (including a patch) was already made in 2015 on the list but never got any response: https://lists.nongnu.org/archive/html/qemu-discuss/2015-07/msg00072.html
+
+
+WDYT of adding such functionality?
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1904490 b/results/classifier/118/device/1904490
new file mode 100644
index 00000000..a057cf8c
--- /dev/null
+++ b/results/classifier/118/device/1904490
@@ -0,0 +1,87 @@
+device: 0.912
+register: 0.898
+debug: 0.887
+user-level: 0.826
+architecture: 0.815
+mistranslation: 0.805
+semantic: 0.794
+graphic: 0.791
+kernel: 0.746
+peripherals: 0.725
+network: 0.718
+permissions: 0.702
+performance: 0.680
+hypervisor: 0.652
+PID: 0.645
+VMM: 0.618
+virtual: 0.608
+socket: 0.570
+TCG: 0.561
+ppc: 0.543
+assembly: 0.540
+vnc: 0.540
+arm: 0.528
+x86: 0.516
+files: 0.492
+i386: 0.480
+risc-v: 0.433
+boot: 0.429
+KVM: 0.404
+
+intel-hda: valid registers are unknown
+
+According to HDA specification, "3.1.2 General Register Behaviors and Access Requirements":
+
+"All controller registers must be addressable as byte, Word, and Dword quantities."
+
+But e.g. if you try the following to reset and enable the CORB, assuming es:esi contains the base MMIO address of the controller,
+
+ es or [esi+4bh], byte 80h   ; reset CORB
+corbresetloop:
+ es test [esi+4bh], byte 80h ; is HW done resetting yet?
+ jnz corbreset1ok            ; yes, bit is now 1
+ hlt                         ; wait a little bit
+ jmp corbresetloop           ; and check again
+corbreset1ok:
+ es and [esi+4bh], byte 7fh  ; clear the bit
+
+It will hang indefinitely because the bit never gets set, and if you enable debug output of the controller with "-device intel-hda,debug=1", you will see infinitely the line "unknown register, addr 0x4b" output. The same code on a real hardware (I tried with ICH7M) works fine, as it should according to the spec.
+
+Host/guest/version does not matter (I am writing own drivers) --- as of right now, latest version still has this code:
+
+https://github.com/qemu/qemu/blob/master/hw/audio/intel-hda.c
+
+which seems to emit "unknown register" message in intel_hda_reg_find(), and this function does not take into account range of addresses that each register occupies.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1911188 b/results/classifier/118/device/1911188
new file mode 100644
index 00000000..183af388
--- /dev/null
+++ b/results/classifier/118/device/1911188
@@ -0,0 +1,85 @@
+device: 0.912
+graphic: 0.902
+semantic: 0.853
+architecture: 0.830
+files: 0.809
+peripherals: 0.807
+hypervisor: 0.795
+x86: 0.794
+PID: 0.761
+arm: 0.744
+ppc: 0.741
+permissions: 0.729
+user-level: 0.725
+mistranslation: 0.715
+debug: 0.711
+socket: 0.710
+network: 0.697
+performance: 0.692
+kernel: 0.653
+register: 0.645
+virtual: 0.642
+vnc: 0.639
+boot: 0.638
+risc-v: 0.635
+i386: 0.535
+VMM: 0.519
+TCG: 0.499
+assembly: 0.495
+KVM: 0.485
+
+qemu-system-x86_64 prints obscure error message and exits when encountering an empty argument
+
+QEMU emulator version 4.2.1 (qemu-4.2.1-1.fc32) on Fedora 32.
+
+When writing a script to start qemu automatically, I ran into a very confusing error message due to a bug in my script and had trouble understanding it. I isolated the problem to the following:
+
+$ qemu-system-x86_64 ""
+qemu-system-x86_64: Initialization of device ide-hd failed: Device needs media, but drive is empty
+
+As you can see, running qemu with an empty argument prints a seemingly random and unrelated error message about an ide-hd device, and the program immediately exits with code 1. This happens when an empty argument appears anywhere in the arguments list, always causing the program to immediately die with this error.
+
+This is a simply baffling message to be encountering when the problem is really an empty argument.
+
+Expected behaviour: Either flatly ignore the empty argument, or at most trigger a warning (eg, "warning: saw empty argument"). It should not at all prevent the program from running.
+
+If QEMU receives an argument that isn't an option flag, then it considers it to be the path to a disk. The block code treats the empty string as indicating that no backing file should be opened for the device. This only makes sense for devices that support removable media (ie CDROM, floppy), hence getting an error message for the ide-hd disk.
+
+So weird as this message might seem, I believe it does ultimately make sense, and I don't think we can just ignore the empty string without potentially breaking other things.
+
+Thanks for the quick reply Daniel. I've looked at the qemu man page many times but somehow never noticed that it can take one non-option argument alongside any other options. That does explain what is going on here. In that case I'm not going to push for a potentially breaking change.
+
+Perhaps it would still be beneficial to emit a warning about the empty string, at least when it has occurred in conjunction with a non-removable drive (I suppose one is created automatically if no other options are present?) which doesn't make sense to get such a path. I feel like the scenario in which it is intended might be less common than the scenario in which it has happened accidentally. Maybe I'm biased though ;)
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1922102 b/results/classifier/118/device/1922102
new file mode 100644
index 00000000..f1bb0b06
--- /dev/null
+++ b/results/classifier/118/device/1922102
@@ -0,0 +1,112 @@
+device: 0.948
+kernel: 0.920
+hypervisor: 0.919
+network: 0.912
+peripherals: 0.904
+files: 0.887
+architecture: 0.861
+user-level: 0.816
+PID: 0.811
+mistranslation: 0.804
+permissions: 0.798
+risc-v: 0.778
+assembly: 0.770
+graphic: 0.766
+boot: 0.763
+performance: 0.760
+x86: 0.756
+socket: 0.735
+debug: 0.703
+vnc: 0.700
+virtual: 0.678
+TCG: 0.664
+VMM: 0.662
+arm: 0.647
+KVM: 0.618
+register: 0.608
+ppc: 0.603
+semantic: 0.591
+i386: 0.570
+
+Broken tap networking on macOS host
+
+Building QEMU with GLib newer than 2.58.3 corrupts tap networking. 
+Tap device was provided by Tun/Tap kernel extension installed from brew:
+  brew install tuntap
+
+Checked revisions:
+  553032d (v5.2.0)
+  6d40ce0 (v6.0.0-rc1)
+
+Host:
+ MacBook Pro (Retina, 15-inch, Mid 2015)
+ macOS Catalina 10.15.6 (19G2021)
+
+Guest:
+  Linux Ubuntu 4.4.0-206-generic x86_64
+  Also tested macOS Catalina 10.15.7 as a guest, the behaviour is the same.
+
+QEMU command line:
+
+qemu-system-x86_64 \
+  -drive file=hdd.qcow2,if=virtio,format=qcow2 \
+  -m 3G \
+  -nic tap,script=tap-up.sh
+
+tap-up.sh:
+ 
+ #!/bin/sh
+
+ TAPDEV="$1"
+ BRIDGEDEV="bridge0"
+
+ ifconfig "$BRIDGEDEV" addm "$TAPDEV"
+
+Enabling/disabling Hypervisor.Framework acceleration (`-accel hvf`) has no effect. 
+
+How to reproduce: 
+  1. Build & install GLib > 2.58.3 (tested 2.60.7, 2.60.7)
+  2. Build qemu-system-x86_64 with GLib > 2.58.3
+  3. Boot any guest any guest with tap networking enabled
+  4. See that the external network is inaccessible
+
+Hotfix:
+  1. Build & install GLib 2.58.3
+  2. Build qemu-system-x86_64 with GLib 2.58.3
+  3. Boot any guest with tap networking enabled
+  4. See that the external network is accessible, everything is working as expected
+
+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.
+
+
+Ticket has been moved here (thanks, Vladislav!):
+https://gitlab.com/qemu-project/qemu/-/issues/335
+... thus I'm closing this on Launchpad now.
+
diff --git a/results/classifier/118/device/1922252 b/results/classifier/118/device/1922252
new file mode 100644
index 00000000..8435e110
--- /dev/null
+++ b/results/classifier/118/device/1922252
@@ -0,0 +1,54 @@
+device: 0.881
+graphic: 0.789
+user-level: 0.650
+performance: 0.646
+mistranslation: 0.638
+semantic: 0.627
+PID: 0.518
+boot: 0.494
+virtual: 0.481
+vnc: 0.462
+permissions: 0.462
+risc-v: 0.428
+network: 0.424
+kernel: 0.419
+ppc: 0.416
+i386: 0.376
+register: 0.346
+TCG: 0.326
+peripherals: 0.321
+arm: 0.316
+KVM: 0.272
+x86: 0.271
+VMM: 0.265
+debug: 0.257
+hypervisor: 0.248
+socket: 0.247
+architecture: 0.176
+files: 0.170
+assembly: 0.110
+
+[feature request] webcam support
+
+Please
+
+I am impatient to get something as "-device usb-webcam" to share dynamically the webcam between host and guest.
+
+Thanks
+
+Have you already tried to simply pass the host USB webcam through to the guest? ... that's likely easier and faster than adding software emulation...
+
+I use
+
+-device usb-host,vendorid=0x046d,productid=0x081b
+
+But in this case the webcam belongs to the guest and the host can't use the webcam.
+
+I want a dynamical sharing like the mouse sharing for example.
+
+Thanks
+
+Ticket has been moved to the new issue tracker at GitLab (thanks!):
+https://gitlab.com/qemu-project/qemu/-/issues/316
+... so I'm closing this ticket on Launchpad now.
+
diff --git a/results/classifier/118/device/1925094 b/results/classifier/118/device/1925094
new file mode 100644
index 00000000..47d136e6
--- /dev/null
+++ b/results/classifier/118/device/1925094
@@ -0,0 +1,68 @@
+device: 0.827
+virtual: 0.777
+graphic: 0.679
+user-level: 0.636
+semantic: 0.609
+architecture: 0.579
+hypervisor: 0.572
+network: 0.571
+ppc: 0.570
+performance: 0.549
+KVM: 0.525
+vnc: 0.517
+TCG: 0.512
+debug: 0.509
+risc-v: 0.508
+mistranslation: 0.508
+PID: 0.505
+permissions: 0.498
+files: 0.498
+VMM: 0.485
+peripherals: 0.469
+register: 0.459
+socket: 0.430
+i386: 0.394
+x86: 0.369
+kernel: 0.363
+boot: 0.355
+arm: 0.315
+assembly: 0.301
+
+DISCARD support for Crypto Block Devices
+
+It appears that running `fstrim` or similar is useless when the VM is on a LUKS-encrypted device using QEMU's native LUKS support.
+
+Looking at the source, it seems that block/crypto.c lacks an implementation for bdrv_co_pdiscard, which probably needs to delegate to a per-crypto type discard helper.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/1926995 b/results/classifier/118/device/1926995
new file mode 100644
index 00000000..178318f0
--- /dev/null
+++ b/results/classifier/118/device/1926995
@@ -0,0 +1,55 @@
+device: 0.845
+vnc: 0.808
+ppc: 0.788
+network: 0.688
+register: 0.649
+files: 0.623
+socket: 0.581
+PID: 0.511
+arm: 0.468
+architecture: 0.446
+graphic: 0.441
+semantic: 0.441
+kernel: 0.431
+boot: 0.385
+virtual: 0.364
+VMM: 0.341
+TCG: 0.335
+risc-v: 0.300
+i386: 0.287
+permissions: 0.271
+x86: 0.267
+debug: 0.266
+KVM: 0.220
+performance: 0.207
+hypervisor: 0.181
+mistranslation: 0.180
+peripherals: 0.176
+user-level: 0.115
+assembly: 0.076
+
+hw/remote/mpqemu-link.c:221: bad error checking ?
+
+hw/remote/mpqemu-link.c:221:36: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op]
+
+Source code is
+
+   if (msg->cmd >= MPQEMU_CMD_MAX && msg->cmd < 0) {
+        return false;
+    }
+
+Maybe better code:
+
+   if (msg->cmd >= MPQEMU_CMD_MAX || msg->cmd < 0) {
+        return false;
+    }
+
+It might be useful to switch on gcc compiler flag -Wlogical-op
+to see these warnings.
+
+Thanks, I've reported it on the mailing list, and a patch has now been posted here:
+https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg02106.html
+
+Fix has been merged now:
+https://gitlab.com/qemu-project/qemu/-/commit/dcf20655ffca2b0219d2914d
+
diff --git a/results/classifier/118/device/1927408 b/results/classifier/118/device/1927408
new file mode 100644
index 00000000..6ca28292
--- /dev/null
+++ b/results/classifier/118/device/1927408
@@ -0,0 +1,87 @@
+device: 0.911
+mistranslation: 0.892
+network: 0.833
+performance: 0.826
+user-level: 0.821
+graphic: 0.807
+peripherals: 0.791
+PID: 0.790
+socket: 0.779
+i386: 0.733
+permissions: 0.696
+semantic: 0.693
+vnc: 0.669
+x86: 0.668
+files: 0.667
+risc-v: 0.659
+register: 0.657
+kernel: 0.605
+ppc: 0.595
+boot: 0.569
+TCG: 0.539
+architecture: 0.536
+VMM: 0.532
+KVM: 0.515
+hypervisor: 0.456
+debug: 0.394
+virtual: 0.391
+assembly: 0.368
+arm: 0.343
+
+USB Ethernet device (RNDIS) does not work on several tested operating systems
+
+The USB ethernet device does not work on most versions of operating systems I have tested. For each operating system the command to use this device was: -netdev user,id=mynet1 -device usb-net,netdev=mynet1.
+
+
+Windows 2000 (qemu-system-i386):
+- failed to load a driver for the device
+
+
+Windows 7 (qemu-system-x86_64):
+- Did not find a driver
+- Followed the directions here: https://developer.toradex.com/knowledge-base/how-to-install-microsoft-rndis-driver-for-windows-7
+-- The device failed to start with error 10.
+- Did see this message in the terminal on the host: 
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+
+
+Mac OS 10.4.11 (qemu-system-ppc):
+- It actually works.
+- did see these messages in the terminal on the host:
+usbnet: failed control transaction: request 0x2143 value 0x1c index 0x0 length 0x0
+usbnet: failed control transaction: request 0x2143 value 0x1e index 0x0 length 0x0
+
+
+Mac OS 10.8.5 (qemu-system-x86_64):
+- Fails to obtain IP address using DHCP.
+- The Network pane does say the device is connected. 
+- A self-assigned IP address is given: 169.254.186.53.
+-- It still did not work
+- Did see this message in the terminal of the host:
+usbnet: failed control transaction: request 0x2143 value 0x1c index 0x0 length 0x0
+usbnet: failed control transaction: request 0x2143 value 0x1e index 0x0 length 0x0
+
+
+Mac OS 10.2.3 (qemu-system-ppc):
+- Did not appear to detect the USB NIC. Did not see it in the network pane.
+- Apple System Profiler does see this device.
+- Saw this message in there terminal of the host: qemu-system-ppc: Slirp: Failed to send packet, ret: -1
+
+
+Mac OS 9.2 (qemu-system-ppc):
+- Apple System Profiler does show the device connected.
+- The Tcp/ip control panel did not detect this device.
+
+
+My guess is this device is buggy. If anyone has any tips or suggestions please let me know.
+
+Thank you.
+
+Please do not open new tickets in the Launchpad bug tracker. Use the gitlab issue tracker now instead:
+
+  https://gitlab.com/qemu-project/qemu/-/issues
+
+See https://gitlab.com/qemu-project/qemu/-/issues/198 for further updates.
+
+Thanks for re-opening it there!
+
diff --git a/results/classifier/118/device/1933 b/results/classifier/118/device/1933
new file mode 100644
index 00000000..746a93aa
--- /dev/null
+++ b/results/classifier/118/device/1933
@@ -0,0 +1,71 @@
+device: 0.856
+hypervisor: 0.828
+PID: 0.814
+graphic: 0.789
+ppc: 0.763
+register: 0.743
+architecture: 0.736
+performance: 0.735
+x86: 0.730
+socket: 0.725
+KVM: 0.710
+kernel: 0.705
+permissions: 0.693
+VMM: 0.683
+virtual: 0.666
+vnc: 0.663
+arm: 0.658
+debug: 0.638
+semantic: 0.605
+risc-v: 0.604
+i386: 0.598
+network: 0.594
+files: 0.594
+boot: 0.591
+assembly: 0.578
+TCG: 0.561
+user-level: 0.525
+peripherals: 0.500
+mistranslation: 0.486
+
+qemu 8.1.1 and 7.2.6 live migration with qcow2 attached to vm using postcopy crashes
+Description of problem:
+Live migrating a vm with a qcow2 disk attached using postcopy will cause vm to crash during migration.
+Steps to reproduce:
+1. Create a generic vm and attach a qcow2 file to the vm.
+<disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' cache='none'/>
+      <source file='/var/lib/libvirt/images/jlow2.qcow2'/>
+      <target dev='vda' bus='virtio'/>
+      <boot order='1'/>
+</disk>
+
+2. virsh migrate jlow2 --change-protection --persistent --live --verbose --undefinesource --abort-on-error --postcopy --postcopy-after-precopy --timeout 1 --timeout-postcopy qemu+tcp://10.18.64.118/system
+
+vm will start migrating and then pause on the source and be shut down on the target once migration switches to postcopy
+
+Migration: [33.08 %]error: internal error: QEMU unexpectedly closed the monitor (vm='jlow2'): 2023-10-12T06:23:44.354387Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable
+2023-10-12T06:23:44.354538Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable
+qemu-system-x86_64: ../block/qcow2.c:5257: qcow2_get_specific_info: Assertion `false' failed.
+
+
+Logs from source
+
+2023-10-12 06:23:43.412+0000: initiating migration
+
+2023-10-12T06:23:44.362392Z qemu-system-x86_64: failed to save SaveStateEntry with id(name): 3(ram): -5
+
+2023-10-12T06:23:44.362485Z qemu-system-x86_64: Detected IO failure for postcopy. Migration paused.
+
+Logs from target
+
+2023-10-12T06:23:44.354387Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable
+
+2023-10-12T06:23:44.354538Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2892749 kHz) and host (2799999 kHz), and TSC scaling unavailable
+
+qemu-system-x86_64: ../block/qcow2.c:5257: qcow2_get_specific_info: Assertion `false' failed.
+2023-10-12 06:23:44.408+0000: shutting down, reason=failed
+
+If postcopy is disabled with command below, migration will succeed:
+
+virsh migrate jlow2 --change-protection --persistent --live --verbose --undefinesource --abort-on-error  qemu+tcp://10.18.64.118/system
diff --git a/results/classifier/118/device/1935 b/results/classifier/118/device/1935
new file mode 100644
index 00000000..dda7c07e
--- /dev/null
+++ b/results/classifier/118/device/1935
@@ -0,0 +1,35 @@
+device: 0.860
+ppc: 0.711
+graphic: 0.700
+risc-v: 0.662
+vnc: 0.645
+PID: 0.634
+socket: 0.600
+boot: 0.571
+register: 0.548
+performance: 0.544
+files: 0.521
+architecture: 0.508
+network: 0.478
+VMM: 0.470
+debug: 0.468
+TCG: 0.377
+arm: 0.368
+kernel: 0.367
+semantic: 0.309
+permissions: 0.297
+mistranslation: 0.260
+i386: 0.204
+x86: 0.181
+KVM: 0.166
+hypervisor: 0.159
+peripherals: 0.155
+user-level: 0.074
+virtual: 0.065
+assembly: 0.064
+
+migrate problem when add SCSI reservations with iSCSI backed disks
+Description of problem:
+When performing migrations with QEMU using iSCSI as the backend, it's common for the migration to start successfully. However, in scenarios where Persistent Reservations are added in the guest, the target host, under the precopy mode, preempts the Persistent Reservations right from the beginning, causing migration issues. Is there a way to control the Persistent Reservations lock within QEMU at an appropriate time, ensuring that it's only preempted during the switchover phase？
+
+Isn't libiscsi thread-safe? Can multiple threads operate on Persistent Reservations lock simultaneously?
diff --git a/results/classifier/118/device/1959 b/results/classifier/118/device/1959
new file mode 100644
index 00000000..d92c0214
--- /dev/null
+++ b/results/classifier/118/device/1959
@@ -0,0 +1,31 @@
+device: 0.867
+performance: 0.711
+graphic: 0.577
+network: 0.551
+arm: 0.472
+architecture: 0.438
+files: 0.344
+hypervisor: 0.277
+virtual: 0.210
+boot: 0.175
+i386: 0.172
+x86: 0.167
+debug: 0.142
+semantic: 0.128
+register: 0.094
+peripherals: 0.089
+VMM: 0.087
+mistranslation: 0.086
+ppc: 0.082
+PID: 0.067
+user-level: 0.054
+kernel: 0.049
+assembly: 0.045
+TCG: 0.034
+socket: 0.029
+vnc: 0.027
+permissions: 0.025
+risc-v: 0.009
+KVM: 0.003
+
+qemu-img: support ZSTD compression level customization
diff --git a/results/classifier/118/device/1961 b/results/classifier/118/device/1961
new file mode 100644
index 00000000..c139a2e6
--- /dev/null
+++ b/results/classifier/118/device/1961
@@ -0,0 +1,31 @@
+device: 0.834
+risc-v: 0.680
+TCG: 0.622
+performance: 0.537
+network: 0.477
+arm: 0.457
+kernel: 0.442
+boot: 0.394
+graphic: 0.393
+peripherals: 0.374
+architecture: 0.367
+semantic: 0.246
+hypervisor: 0.222
+VMM: 0.219
+socket: 0.210
+vnc: 0.182
+ppc: 0.164
+mistranslation: 0.156
+permissions: 0.126
+register: 0.124
+PID: 0.107
+files: 0.104
+debug: 0.088
+user-level: 0.050
+assembly: 0.047
+KVM: 0.034
+virtual: 0.020
+x86: 0.018
+i386: 0.005
+
+Commit accel/tcg: Always require can_do_io breaks riscv64 bare metal firmware
diff --git a/results/classifier/118/device/1969 b/results/classifier/118/device/1969
new file mode 100644
index 00000000..a5e2da15
--- /dev/null
+++ b/results/classifier/118/device/1969
@@ -0,0 +1,31 @@
+device: 0.812
+performance: 0.701
+network: 0.685
+graphic: 0.582
+debug: 0.481
+vnc: 0.427
+arm: 0.421
+kernel: 0.415
+risc-v: 0.414
+x86: 0.376
+KVM: 0.374
+i386: 0.333
+socket: 0.322
+architecture: 0.308
+hypervisor: 0.280
+semantic: 0.209
+ppc: 0.200
+boot: 0.134
+peripherals: 0.130
+mistranslation: 0.104
+permissions: 0.102
+register: 0.097
+user-level: 0.086
+assembly: 0.081
+files: 0.077
+VMM: 0.062
+virtual: 0.054
+TCG: 0.020
+PID: 0.016
+
+Test fails with SIGSEGV because of use-after-free
diff --git a/results/classifier/118/device/1973 b/results/classifier/118/device/1973
new file mode 100644
index 00000000..d07f0965
--- /dev/null
+++ b/results/classifier/118/device/1973
@@ -0,0 +1,31 @@
+device: 0.863
+performance: 0.513
+mistranslation: 0.306
+debug: 0.304
+architecture: 0.293
+semantic: 0.261
+peripherals: 0.230
+graphic: 0.226
+network: 0.216
+user-level: 0.208
+i386: 0.103
+permissions: 0.102
+virtual: 0.091
+ppc: 0.090
+arm: 0.076
+PID: 0.071
+VMM: 0.068
+risc-v: 0.060
+TCG: 0.058
+assembly: 0.056
+KVM: 0.051
+boot: 0.045
+x86: 0.038
+hypervisor: 0.036
+register: 0.034
+socket: 0.030
+vnc: 0.029
+files: 0.013
+kernel: 0.006
+
+Issues with dmabuf use in dbus interface
diff --git a/results/classifier/118/device/1979 b/results/classifier/118/device/1979
new file mode 100644
index 00000000..61ac1344
--- /dev/null
+++ b/results/classifier/118/device/1979
@@ -0,0 +1,61 @@
+device: 0.905
+debug: 0.820
+ppc: 0.793
+kernel: 0.786
+PID: 0.708
+user-level: 0.698
+register: 0.670
+peripherals: 0.655
+graphic: 0.650
+vnc: 0.630
+files: 0.591
+socket: 0.553
+boot: 0.549
+risc-v: 0.536
+assembly: 0.536
+architecture: 0.526
+x86: 0.522
+semantic: 0.500
+TCG: 0.486
+VMM: 0.474
+mistranslation: 0.470
+performance: 0.466
+network: 0.466
+hypervisor: 0.462
+i386: 0.457
+arm: 0.431
+permissions: 0.396
+KVM: 0.355
+virtual: 0.225
+
+pc-q35-7.2 breaks the pcie hot plugin
+Description of problem:
+the new pc-q35 version >6.0 break the pcie hot plug feature
+if I use 5.2, 6.0, it works fine. `dmesg | grep pcieport` shows that:
+there is pciehp which provide functionality of hot plug for PCIE device
+```
+[test@localhost ~]$ dmesg | grep pcieport
+[    1.161129] pcieport 0000:00:02.0: PME: Signaling with IRQ 24
+[    1.162254] pcieport 0000:00:02.0: AER: enabled with IRQ 24
+[    1.163218] pcieport 0000:00:02.0: pciehp: Slot #0 AttnBtn+ PwrCtrl+ MRL- AttnInd+ PwrInd+ HotPlug+ Surprise+ Interlock+ NoCompl- IbPresDis- LLActRep+
+```
+
+if I switch to 6.1, 6.2, 7.0, 7.1 ,7.2, the pciehp does not show any control slot.
+```
+[test@localhost ~]$ dmesg | grep pcieport
+[    1.164311] pcieport 0000:00:02.0: PME: Signaling with IRQ 24
+[    1.165446] pcieport 0000:00:02.0: AER: enabled with IRQ 24
+```
+Steps to reproduce:
+1. run the qemu command as I produced
+2. connect to console
+3. run `dmesg | grep pcieport`
+4. you can try to plug in a GPU or something else, the device initialization will fail because there is no pciehp slow to power it on, normall you will see something like following, with >6.0 you cannot see them:
+  ```
+  pciehp: Slot(0-8): Attention button pressed
+  pciehp: Slot(0-8) Powering on due to button press
+  pciehp: Slot(0-8): Card present
+  pciehp: Slot(0-8): Link Up
+  ```
+Additional information:
+
diff --git a/results/classifier/118/device/1980 b/results/classifier/118/device/1980
new file mode 100644
index 00000000..42167410
--- /dev/null
+++ b/results/classifier/118/device/1980
@@ -0,0 +1,43 @@
+device: 0.879
+ppc: 0.767
+PID: 0.761
+graphic: 0.739
+network: 0.732
+peripherals: 0.703
+virtual: 0.691
+register: 0.563
+hypervisor: 0.561
+performance: 0.513
+vnc: 0.507
+semantic: 0.476
+mistranslation: 0.426
+i386: 0.404
+arm: 0.370
+boot: 0.352
+VMM: 0.340
+assembly: 0.291
+debug: 0.278
+TCG: 0.265
+risc-v: 0.263
+files: 0.253
+architecture: 0.215
+x86: 0.204
+user-level: 0.200
+permissions: 0.192
+kernel: 0.185
+socket: 0.158
+KVM: 0.099
+
+pipewire backend, bad mic sound
+Description of problem:
+Qemu VM and openSUSE share the webcam mic.
+Pipewire is used by openSUSE.
+
+If using qemu with pa backend, there is no sound problem when mic is used by Skype in openSUSE.
+If using qemu with pipewire backend and Skype used the mic then my contact says he does not recognize my voice and there are cracks.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/118/device/1984 b/results/classifier/118/device/1984
new file mode 100644
index 00000000..c147eb15
--- /dev/null
+++ b/results/classifier/118/device/1984
@@ -0,0 +1,31 @@
+device: 0.880
+performance: 0.867
+network: 0.766
+architecture: 0.716
+arm: 0.646
+debug: 0.605
+graphic: 0.540
+PID: 0.440
+ppc: 0.431
+semantic: 0.365
+boot: 0.329
+TCG: 0.327
+i386: 0.313
+files: 0.294
+permissions: 0.248
+virtual: 0.231
+VMM: 0.216
+vnc: 0.206
+x86: 0.185
+hypervisor: 0.172
+register: 0.170
+peripherals: 0.124
+mistranslation: 0.101
+user-level: 0.090
+risc-v: 0.049
+kernel: 0.049
+socket: 0.047
+assembly: 0.041
+KVM: 0.028
+
+Fails to start dataplane while using vdpa-dev with vduse backend
diff --git a/results/classifier/118/device/2002 b/results/classifier/118/device/2002
new file mode 100644
index 00000000..464904f0
--- /dev/null
+++ b/results/classifier/118/device/2002
@@ -0,0 +1,33 @@
+device: 0.857
+network: 0.649
+register: 0.611
+architecture: 0.551
+performance: 0.487
+boot: 0.447
+arm: 0.440
+socket: 0.426
+graphic: 0.349
+semantic: 0.333
+hypervisor: 0.311
+debug: 0.271
+files: 0.248
+peripherals: 0.232
+kernel: 0.229
+risc-v: 0.225
+mistranslation: 0.160
+vnc: 0.154
+ppc: 0.129
+permissions: 0.105
+VMM: 0.074
+KVM: 0.071
+assembly: 0.064
+TCG: 0.053
+i386: 0.043
+user-level: 0.041
+virtual: 0.040
+PID: 0.007
+x86: 0.005
+
+Need to be able to set WM_CLASS under X11
+Additional information:
+
diff --git a/results/classifier/118/device/2008 b/results/classifier/118/device/2008
new file mode 100644
index 00000000..ee31ffe6
--- /dev/null
+++ b/results/classifier/118/device/2008
@@ -0,0 +1,42 @@
+device: 0.831
+ppc: 0.830
+graphic: 0.829
+semantic: 0.754
+performance: 0.606
+network: 0.550
+architecture: 0.523
+vnc: 0.506
+boot: 0.452
+mistranslation: 0.441
+risc-v: 0.399
+socket: 0.395
+kernel: 0.327
+debug: 0.321
+arm: 0.318
+user-level: 0.317
+VMM: 0.297
+peripherals: 0.292
+virtual: 0.290
+PID: 0.265
+register: 0.259
+hypervisor: 0.203
+TCG: 0.194
+files: 0.181
+i386: 0.133
+permissions: 0.129
+x86: 0.106
+assembly: 0.094
+KVM: 0.047
+
+querying smbios type=1 UUID in Windows not possible when using SMBIOS 64 bit entry
+Description of problem:
+Querying the UUID in Powershell with
+`get-wmiobject win32_computersystemproduct | Select-Object -expandProperty UUID`
+will return no value. When using `-machine 'pc-i440fx-8.1,smbios-entry-point-type=32'` or `-machine 'pc-i440fx-8.0'` the command works as expected. When using `-machine 'pc-i440fx-8.0,smbios-entry-point-type=64'` the issue is also present.
+
+Commit bf376f3020dfd7bcb2c4158b4ffa85c04d44f56d changed the default for machine version 8.1, so that explains that part.
+
+It's not clear to me if this is a bug in QEMU or a bug/limitation of the guest OS when 64 bit entry is used by SMBIOS.
+Additional information:
+Originally reported for Windows 10 in the Proxmox VE community forum (AFAIK the downstream build in Proxmox VE does not patch the relevant code paths):
+https://forum.proxmox.com/threads/136942/
diff --git a/results/classifier/118/device/2018 b/results/classifier/118/device/2018
new file mode 100644
index 00000000..cae0f118
--- /dev/null
+++ b/results/classifier/118/device/2018
@@ -0,0 +1,48 @@
+device: 0.850
+kernel: 0.833
+graphic: 0.823
+socket: 0.714
+network: 0.713
+performance: 0.658
+ppc: 0.612
+semantic: 0.582
+architecture: 0.579
+permissions: 0.528
+PID: 0.520
+peripherals: 0.480
+vnc: 0.477
+risc-v: 0.472
+register: 0.446
+debug: 0.432
+hypervisor: 0.424
+boot: 0.403
+VMM: 0.354
+i386: 0.351
+files: 0.345
+KVM: 0.329
+x86: 0.325
+arm: 0.318
+TCG: 0.313
+mistranslation: 0.265
+user-level: 0.230
+virtual: 0.226
+assembly: 0.215
+
+QEMU would not start when trying to create two UFS host controllers
+Description of problem:
+This issue is reported by Akinobu Mita.
+https://lore.kernel.org/qemu-devel/20231204150543.48252-1-akinobu.mita@gmail.com/
+
+> QEMU would not start when trying to create two UFS host controllers and a UFS logical unit for each with the following options:
+> 
+> -device ufs,id=bus0 \
+> -device ufs-lu,drive=drive1,bus=bus0,lun=0 \
+> -device ufs,id=bus1 \
+> -device ufs-lu,drive=drive2,bus=bus1,lun=0 \
+> 
+> This is because the same ID string ("0:0:0/scsi-disk") is generated
+> for both UFS logical units.
+> 
+> To fix this issue, prepend the parent pci device's path to make
+> the ID string unique.
+> ("0000:00:03.0/0:0:0/scsi-disk" and "0000:00:04.0/0:0:0/scsi-disk")
diff --git a/results/classifier/118/device/2020 b/results/classifier/118/device/2020
new file mode 100644
index 00000000..ba8e091c
--- /dev/null
+++ b/results/classifier/118/device/2020
@@ -0,0 +1,41 @@
+device: 0.899
+x86: 0.893
+virtual: 0.883
+KVM: 0.804
+graphic: 0.749
+vnc: 0.728
+socket: 0.703
+network: 0.672
+PID: 0.664
+semantic: 0.648
+risc-v: 0.629
+i386: 0.592
+files: 0.557
+ppc: 0.537
+performance: 0.475
+VMM: 0.461
+debug: 0.434
+hypervisor: 0.404
+register: 0.382
+architecture: 0.370
+boot: 0.342
+mistranslation: 0.341
+TCG: 0.313
+arm: 0.294
+kernel: 0.287
+permissions: 0.286
+user-level: 0.155
+assembly: 0.154
+peripherals: 0.050
+
+qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed.
+Description of problem:
+VM just crashed, likely because of a time / NTP change
+```
+qemu-system-x86_64: ../../hw/rtc/mc146818rtc.c:203: periodic_timer_update: Assertion `lost_clock >= 0' failed.
+2023-12-04 15:51:40.571+0000: shutting down, reason=crashed
+```
+Steps to reproduce:
+1. N/A
+
+/label ~"kind::Bug"
diff --git a/results/classifier/118/device/2021 b/results/classifier/118/device/2021
new file mode 100644
index 00000000..20a5b99b
--- /dev/null
+++ b/results/classifier/118/device/2021
@@ -0,0 +1,31 @@
+device: 0.968
+performance: 0.963
+debug: 0.927
+register: 0.855
+peripherals: 0.803
+graphic: 0.766
+VMM: 0.766
+arm: 0.765
+risc-v: 0.751
+ppc: 0.743
+network: 0.723
+PID: 0.698
+TCG: 0.636
+kernel: 0.592
+vnc: 0.534
+boot: 0.495
+KVM: 0.269
+permissions: 0.231
+user-level: 0.223
+i386: 0.217
+architecture: 0.154
+socket: 0.141
+semantic: 0.111
+virtual: 0.104
+hypervisor: 0.090
+mistranslation: 0.082
+files: 0.034
+assembly: 0.030
+x86: 0.028
+
+crashing when trying to read data from sensor though usb
diff --git a/results/classifier/118/device/2026 b/results/classifier/118/device/2026
new file mode 100644
index 00000000..fd8b63e9
--- /dev/null
+++ b/results/classifier/118/device/2026
@@ -0,0 +1,38 @@
+device: 0.904
+virtual: 0.801
+graphic: 0.721
+boot: 0.695
+mistranslation: 0.685
+architecture: 0.592
+hypervisor: 0.570
+performance: 0.534
+PID: 0.513
+network: 0.507
+kernel: 0.500
+register: 0.432
+debug: 0.403
+socket: 0.399
+vnc: 0.385
+VMM: 0.376
+semantic: 0.372
+risc-v: 0.347
+arm: 0.259
+i386: 0.252
+KVM: 0.251
+x86: 0.249
+permissions: 0.191
+user-level: 0.187
+TCG: 0.166
+peripherals: 0.159
+files: 0.143
+ppc: 0.143
+assembly: 0.089
+
+Virtio-vga-gl: If xres/yres is set, Qemu should not inherit the resolution of the window
+Description of problem:
+Despite setting xres=1920,yres-1080 when the VM the resolution the VM gets set to is inherited from the window.
+Steps to reproduce:
+1. Launch VM with xres/yres set
+2. check display size
+Additional information:
+
diff --git a/results/classifier/118/device/2028 b/results/classifier/118/device/2028
new file mode 100644
index 00000000..756c345f
--- /dev/null
+++ b/results/classifier/118/device/2028
@@ -0,0 +1,31 @@
+device: 0.867
+mistranslation: 0.859
+performance: 0.810
+network: 0.503
+graphic: 0.319
+semantic: 0.307
+debug: 0.294
+boot: 0.246
+arm: 0.167
+files: 0.156
+architecture: 0.129
+ppc: 0.129
+assembly: 0.122
+register: 0.122
+user-level: 0.121
+peripherals: 0.119
+VMM: 0.117
+risc-v: 0.115
+vnc: 0.087
+permissions: 0.077
+virtual: 0.068
+PID: 0.049
+TCG: 0.046
+socket: 0.044
+kernel: 0.033
+hypervisor: 0.027
+KVM: 0.024
+i386: 0.005
+x86: 0.003
+
+CAN sja1000 standard frame filter bug
diff --git a/results/classifier/118/device/203 b/results/classifier/118/device/203
new file mode 100644
index 00000000..d9b2081a
--- /dev/null
+++ b/results/classifier/118/device/203
@@ -0,0 +1,31 @@
+device: 0.840
+files: 0.698
+performance: 0.693
+architecture: 0.681
+virtual: 0.659
+boot: 0.609
+network: 0.599
+semantic: 0.588
+ppc: 0.565
+arm: 0.523
+VMM: 0.490
+graphic: 0.449
+mistranslation: 0.445
+register: 0.437
+PID: 0.434
+permissions: 0.427
+TCG: 0.399
+peripherals: 0.389
+debug: 0.318
+x86: 0.261
+socket: 0.254
+hypervisor: 0.251
+assembly: 0.250
+i386: 0.249
+vnc: 0.246
+user-level: 0.201
+KVM: 0.119
+risc-v: 0.062
+kernel: 0.024
+
+move ./scripts/qapi/ to ./python/qemu/qapi/
diff --git a/results/classifier/118/device/2033 b/results/classifier/118/device/2033
new file mode 100644
index 00000000..1113f4f0
--- /dev/null
+++ b/results/classifier/118/device/2033
@@ -0,0 +1,31 @@
+mistranslation: 0.992
+device: 0.945
+performance: 0.717
+network: 0.712
+graphic: 0.611
+architecture: 0.445
+debug: 0.403
+semantic: 0.355
+peripherals: 0.337
+hypervisor: 0.238
+virtual: 0.211
+VMM: 0.210
+arm: 0.206
+boot: 0.167
+register: 0.156
+vnc: 0.119
+files: 0.093
+permissions: 0.082
+i386: 0.069
+PID: 0.060
+assembly: 0.054
+risc-v: 0.053
+x86: 0.040
+TCG: 0.031
+user-level: 0.018
+kernel: 0.013
+ppc: 0.010
+socket: 0.008
+KVM: 0.005
+
+goldfish_rtc device incorrectly migrates tick offset as an offset from QEMU_CLOCK_VIRTUAL
diff --git a/results/classifier/118/device/2039 b/results/classifier/118/device/2039
new file mode 100644
index 00000000..586813f5
--- /dev/null
+++ b/results/classifier/118/device/2039
@@ -0,0 +1,41 @@
+device: 0.874
+performance: 0.866
+graphic: 0.850
+virtual: 0.795
+mistranslation: 0.766
+network: 0.745
+semantic: 0.741
+kernel: 0.695
+VMM: 0.692
+permissions: 0.675
+PID: 0.674
+vnc: 0.656
+risc-v: 0.655
+ppc: 0.636
+debug: 0.632
+architecture: 0.629
+boot: 0.626
+register: 0.624
+arm: 0.588
+peripherals: 0.508
+hypervisor: 0.446
+socket: 0.433
+user-level: 0.397
+TCG: 0.369
+i386: 0.346
+KVM: 0.326
+assembly: 0.322
+x86: 0.232
+files: 0.151
+
+there is no 'write' lock checked when exec `qemu-img check lvqcow2`
+Description of problem:
+There is a difference between a qcow2 file image and a lvqcow2 img.
+
+'write' lock will be checked when using a normal qcow2-format image (/path/to/img/test.qcow2) to avoid some risky operations. However, when I create a qcow2 img on a lv, there is not any write lock checked when I perform `qemu-img check` on this lvqcow2 even though it was attached to a vm.
+Steps to reproduce:
+1. create a lvqcow2: `qemu-img create -f qcow2 /path/to/lv  xxG`
+2. create a vm using this lvqcow2
+3. exec `qemu-img check` on this lvqcow2, there is no any perm (such as 'write' lock) check and notifaction even though this lvqcow2 is using in qemu vm.
+Additional information:
+
diff --git a/results/classifier/118/device/204 b/results/classifier/118/device/204
new file mode 100644
index 00000000..5fa52ab7
--- /dev/null
+++ b/results/classifier/118/device/204
@@ -0,0 +1,31 @@
+device: 0.937
+performance: 0.698
+graphic: 0.512
+debug: 0.395
+risc-v: 0.368
+i386: 0.358
+ppc: 0.339
+TCG: 0.268
+user-level: 0.215
+vnc: 0.210
+PID: 0.200
+peripherals: 0.197
+semantic: 0.189
+VMM: 0.186
+mistranslation: 0.185
+arm: 0.180
+x86: 0.163
+virtual: 0.163
+register: 0.068
+network: 0.066
+assembly: 0.061
+KVM: 0.052
+boot: 0.049
+permissions: 0.038
+architecture: 0.019
+socket: 0.017
+kernel: 0.010
+hypervisor: 0.005
+files: 0.002
+
+Dos Keypad is not working for numbers - numlock is not working
diff --git a/results/classifier/118/device/2044 b/results/classifier/118/device/2044
new file mode 100644
index 00000000..76c73c5c
--- /dev/null
+++ b/results/classifier/118/device/2044
@@ -0,0 +1,35 @@
+device: 0.963
+graphic: 0.933
+boot: 0.884
+ppc: 0.671
+mistranslation: 0.656
+hypervisor: 0.599
+semantic: 0.596
+debug: 0.583
+register: 0.569
+arm: 0.552
+files: 0.471
+architecture: 0.458
+user-level: 0.404
+risc-v: 0.396
+PID: 0.395
+socket: 0.391
+VMM: 0.364
+vnc: 0.344
+network: 0.288
+i386: 0.284
+performance: 0.228
+TCG: 0.214
+x86: 0.182
+peripherals: 0.167
+permissions: 0.132
+virtual: 0.125
+kernel: 0.121
+assembly: 0.096
+KVM: 0.007
+
+HP-UX 10.20 doesn't boot on QEMU 8.2.0-rc4
+Description of problem:
+After update QEMU for v8.2.0-rc4 existing HP-UX 10.20 installation doesn't work anymore. I also tried to boot the installation media and SeaBIOS stays in loop.
+Additional information:
+#
diff --git a/results/classifier/118/device/2048 b/results/classifier/118/device/2048
new file mode 100644
index 00000000..d80c52a1
--- /dev/null
+++ b/results/classifier/118/device/2048
@@ -0,0 +1,31 @@
+device: 0.840
+mistranslation: 0.712
+debug: 0.572
+performance: 0.543
+virtual: 0.411
+network: 0.407
+semantic: 0.318
+files: 0.290
+ppc: 0.284
+graphic: 0.282
+boot: 0.208
+PID: 0.203
+risc-v: 0.196
+permissions: 0.175
+arm: 0.148
+architecture: 0.141
+VMM: 0.137
+vnc: 0.137
+register: 0.120
+TCG: 0.084
+socket: 0.053
+peripherals: 0.046
+i386: 0.045
+user-level: 0.026
+assembly: 0.015
+x86: 0.012
+hypervisor: 0.007
+KVM: 0.003
+kernel: 0.001
+
+Host: Wayland sdl display problem
diff --git a/results/classifier/118/device/2049 b/results/classifier/118/device/2049
new file mode 100644
index 00000000..21e99df5
--- /dev/null
+++ b/results/classifier/118/device/2049
@@ -0,0 +1,41 @@
+device: 0.926
+graphic: 0.867
+semantic: 0.845
+socket: 0.782
+ppc: 0.766
+mistranslation: 0.715
+network: 0.710
+register: 0.668
+debug: 0.641
+peripherals: 0.631
+user-level: 0.567
+vnc: 0.552
+performance: 0.543
+architecture: 0.513
+arm: 0.495
+boot: 0.490
+virtual: 0.466
+kernel: 0.465
+PID: 0.456
+x86: 0.443
+i386: 0.428
+VMM: 0.419
+files: 0.417
+hypervisor: 0.417
+TCG: 0.345
+permissions: 0.300
+assembly: 0.295
+KVM: 0.231
+risc-v: 0.206
+
+drive-mirror RBD thin
+Description of problem:
+I found that this problem was first discovered in 2014. There was a post 
+[2014 bug description](https://lists.gnu.org/archive/html/qemu-devel/2014-10/msg01231.html )、
+[2014 patch](https://patchwork.ozlabs.org/project/qemu-devel/patch/1433747185-16797-2-git-send-email-famz@redhat.com/)
+mentioning this bug. 
+The patch in the post said that this problem had been solved, but after trying and asking, I found that the problem had not been solved.
+Later, I saw this problem in the [2017 bug description](https://forum.proxmox.com/threads/drive-mirror-rbd-thin.33250/#post-613502) forum and it was said that there was a patch to fix it, but it was not.
+I tried the latest qemu version and found that this problem has not been solved.
+Additional information:
+nbd is normal, but rbd is wrong！
diff --git a/results/classifier/118/device/2055 b/results/classifier/118/device/2055
new file mode 100644
index 00000000..9754f9aa
--- /dev/null
+++ b/results/classifier/118/device/2055
@@ -0,0 +1,37 @@
+device: 0.888
+register: 0.886
+vnc: 0.796
+graphic: 0.754
+risc-v: 0.753
+socket: 0.692
+network: 0.658
+ppc: 0.628
+kernel: 0.594
+semantic: 0.572
+performance: 0.533
+arm: 0.512
+debug: 0.475
+architecture: 0.429
+files: 0.399
+boot: 0.276
+permissions: 0.271
+peripherals: 0.254
+mistranslation: 0.240
+assembly: 0.146
+user-level: 0.140
+PID: 0.118
+hypervisor: 0.105
+VMM: 0.099
+TCG: 0.082
+virtual: 0.060
+KVM: 0.010
+x86: 0.004
+i386: 0.003
+
+Unable to set the PBMTE bit in the menvcfg register for RISCV 64 bit
+Description of problem:
+We are unable to program the PBMTE bit in the menvcfg register of a RV64 machine. The following is the command that was used to do this.
+ 
+write_csr(menvcfg,PTE_PBMT);
+Steps to reproduce:
+1. A simple test program with the above command should be able to reproduce this issue.
diff --git a/results/classifier/118/device/2067 b/results/classifier/118/device/2067
new file mode 100644
index 00000000..a4ca5521
--- /dev/null
+++ b/results/classifier/118/device/2067
@@ -0,0 +1,31 @@
+device: 0.917
+performance: 0.862
+debug: 0.799
+graphic: 0.497
+boot: 0.493
+arm: 0.482
+network: 0.438
+PID: 0.414
+register: 0.412
+ppc: 0.409
+user-level: 0.364
+architecture: 0.297
+semantic: 0.259
+virtual: 0.207
+assembly: 0.190
+VMM: 0.174
+risc-v: 0.162
+socket: 0.115
+peripherals: 0.104
+mistranslation: 0.088
+TCG: 0.087
+vnc: 0.081
+permissions: 0.072
+hypervisor: 0.056
+files: 0.052
+i386: 0.029
+KVM: 0.010
+x86: 0.007
+kernel: 0.007
+
+screen unblanking issue with debian 12 gui
diff --git a/results/classifier/118/device/2086 b/results/classifier/118/device/2086
new file mode 100644
index 00000000..c629cef1
--- /dev/null
+++ b/results/classifier/118/device/2086
@@ -0,0 +1,45 @@
+device: 0.905
+graphic: 0.890
+virtual: 0.845
+files: 0.820
+performance: 0.767
+boot: 0.727
+hypervisor: 0.723
+architecture: 0.703
+PID: 0.645
+semantic: 0.569
+VMM: 0.559
+socket: 0.530
+x86: 0.515
+debug: 0.507
+i386: 0.490
+user-level: 0.488
+permissions: 0.486
+mistranslation: 0.478
+peripherals: 0.475
+ppc: 0.472
+kernel: 0.461
+risc-v: 0.426
+KVM: 0.400
+network: 0.383
+arm: 0.376
+vnc: 0.357
+register: 0.337
+TCG: 0.329
+assembly: 0.308
+
+qemu-img created VMDK files lead to "Unsupported or invalid disk type 7" on ESXi
+Description of problem:
+Trying to start the VM using vmdk converted with qemu-img fails with
+
+Failed to start the virtual machine.
+Module DevicePowerOn power on failed.
+Unable to create virtual SCSI device for scsi0:1, '/vmfs/volumes/5cca0155-bdddf31d-2714-00215acbeb1e/AppD-VM01/AppDdisk1-VM01.vmdk'
+Failed to open disk scsi0:1: Unsupported or invalid disk type 7. Ensure that the disk has been imported.
+Steps to reproduce:
+1. Convert booting OS (in both Qemu and VMWare with the help of drivers) to vmdk 
+2. Push vmdk file to ESXi datastore 
+3. Try to boot
+![image](/uploads/68bea874d75b1a8f6ad7f89f28feb176/image.png)
+Additional information:
+ESXi seem to use a specific implementation of vmdk, with a *name*.vmdk file being the descriptor of the virtual disk and a *name*-flat.vmdk.
diff --git a/results/classifier/118/device/2087 b/results/classifier/118/device/2087
new file mode 100644
index 00000000..40fa32b7
--- /dev/null
+++ b/results/classifier/118/device/2087
@@ -0,0 +1,58 @@
+device: 0.812
+performance: 0.629
+debug: 0.595
+ppc: 0.591
+socket: 0.563
+semantic: 0.558
+peripherals: 0.540
+PID: 0.506
+files: 0.505
+vnc: 0.499
+register: 0.466
+VMM: 0.443
+network: 0.441
+boot: 0.429
+mistranslation: 0.419
+risc-v: 0.410
+user-level: 0.385
+permissions: 0.351
+kernel: 0.351
+virtual: 0.320
+arm: 0.301
+architecture: 0.270
+TCG: 0.268
+graphic: 0.261
+KVM: 0.243
+i386: 0.229
+hypervisor: 0.181
+x86: 0.154
+assembly: 0.122
+
+usb-host / libusb: handling of clear_halt leads to slow device attach, possibly unusable VMs (edit:fix within)
+Description of problem:
+When passing through a common JMicron USB SATA IDE brige storage device to a windows guest, the windows VM and the attached device become unusable. It appears to take several minutes to identify the connected device, and many minutes to pull up the device properties (though they are correct). The trace log seems to indicate a retry/reset retry loop is occuring.
+
+The device works fine passed through to a fedora guest VM. Device also work fine when used by the Windows host system.
+
+The primary difference may be the XHCI controller device behavior in the Windows and fedora guest VMs.\
+It appears there may possibly be 2 separate issues:
+
+1. Incompatible handling of this type of storage device in usb-host / libusb.
+2. Windows XHCI not properly handling malformed or possibly mis-behaved devices.
+
+I also tried the nec-usb-xhci device instead of qemu-xhci, and also tried the ICH9 usb device; no difference in behavior in the Windows VM. (Though windows appears to use the same xhci device driver in all cases).
+
+A simple USB 3.x storage stick (at speed 5000) works fine passed through to the Windows guest VM, configured in the same way, with both cases using WinUSB to allow passthrough/attach to work.
+Additional information:
+lsusb output in the working Fedora VM case:
+
+only the debug descriptor fails to dump, running as root
+
+[lsusb.txt](/uploads/c1a702bc628ed9bc983dba3e703e8af4/lsusb.txt)
+
+\-trace enable=usb_host\_\* output (fragment of logfile) from the non-working Windows VM case:
+
+[usb_noprogress.txt](/uploads/f66b2ff7d4658f9569859ac122413d9f/usb_noprogress.txt)
+
+```plaintext
+```
diff --git a/results/classifier/118/device/2091 b/results/classifier/118/device/2091
new file mode 100644
index 00000000..b213a5c5
--- /dev/null
+++ b/results/classifier/118/device/2091
@@ -0,0 +1,33 @@
+device: 0.876
+boot: 0.868
+arm: 0.713
+architecture: 0.680
+performance: 0.572
+register: 0.525
+kernel: 0.500
+VMM: 0.455
+hypervisor: 0.451
+risc-v: 0.379
+network: 0.370
+files: 0.361
+graphic: 0.349
+mistranslation: 0.298
+x86: 0.292
+debug: 0.267
+PID: 0.249
+semantic: 0.227
+socket: 0.217
+TCG: 0.198
+virtual: 0.191
+vnc: 0.186
+KVM: 0.159
+i386: 0.114
+ppc: 0.065
+permissions: 0.039
+user-level: 0.033
+assembly: 0.031
+peripherals: 0.011
+
+m68k: virt: Pass the configured cpu type via bootinfo instead of the default 68040
+Additional information:
+
diff --git a/results/classifier/118/device/2093 b/results/classifier/118/device/2093
new file mode 100644
index 00000000..ee05a781
--- /dev/null
+++ b/results/classifier/118/device/2093
@@ -0,0 +1,33 @@
+device: 0.904
+performance: 0.717
+architecture: 0.716
+network: 0.627
+arm: 0.602
+register: 0.531
+graphic: 0.527
+socket: 0.497
+semantic: 0.440
+kernel: 0.435
+ppc: 0.431
+boot: 0.418
+VMM: 0.413
+debug: 0.333
+risc-v: 0.296
+hypervisor: 0.281
+PID: 0.280
+vnc: 0.276
+files: 0.262
+mistranslation: 0.213
+i386: 0.195
+x86: 0.186
+TCG: 0.184
+virtual: 0.178
+KVM: 0.177
+permissions: 0.146
+assembly: 0.133
+peripherals: 0.100
+user-level: 0.096
+
+m68k: virt: Add command to virt-ctrl device to pause cpu until an interrupt happens
+Additional information:
+I'm working on how to implement this myself. Any hints would be great.
diff --git a/results/classifier/118/device/2122 b/results/classifier/118/device/2122
new file mode 100644
index 00000000..d5568341
--- /dev/null
+++ b/results/classifier/118/device/2122
@@ -0,0 +1,37 @@
+x86: 0.998
+architecture: 0.969
+user-level: 0.952
+device: 0.947
+arm: 0.932
+graphic: 0.885
+semantic: 0.864
+debug: 0.666
+performance: 0.561
+permissions: 0.531
+network: 0.523
+virtual: 0.431
+peripherals: 0.424
+mistranslation: 0.389
+boot: 0.387
+PID: 0.318
+vnc: 0.276
+kernel: 0.250
+socket: 0.229
+files: 0.219
+register: 0.174
+VMM: 0.173
+hypervisor: 0.171
+TCG: 0.138
+i386: 0.097
+ppc: 0.095
+risc-v: 0.027
+assembly: 0.023
+KVM: 0.011
+
+qemu-user-static segfault running ldconfig on host x86_64 with client arm64
+Description of problem:
+qemu segfault
+Steps to reproduce:
+1. download ubuntu jammy arm64 rootfs (I assume any will do)
+2. mount it (with /proc from host so apt is happy)
+3. execute an apt uninstall that triggers libc-bin processing
diff --git a/results/classifier/118/device/2125 b/results/classifier/118/device/2125
new file mode 100644
index 00000000..9bdafb75
--- /dev/null
+++ b/results/classifier/118/device/2125
@@ -0,0 +1,44 @@
+device: 0.906
+boot: 0.895
+x86: 0.830
+peripherals: 0.733
+network: 0.726
+performance: 0.710
+graphic: 0.671
+hypervisor: 0.610
+ppc: 0.574
+mistranslation: 0.568
+architecture: 0.565
+PID: 0.543
+vnc: 0.538
+socket: 0.535
+files: 0.480
+risc-v: 0.476
+register: 0.444
+permissions: 0.405
+semantic: 0.396
+kernel: 0.381
+VMM: 0.375
+user-level: 0.340
+arm: 0.336
+TCG: 0.328
+i386: 0.324
+debug: 0.305
+assembly: 0.209
+KVM: 0.089
+virtual: 0.073
+
+The value of 'tx_queue_size' is set to only 256 in the network device option on qemu 8.2.
+Description of problem:
+I have been using the 'tx_queue_size' value set to 1024 in the network device option on qemu 7.2 without any issues.\
+but when I upgrade to qemu 8.2 I got this error message (and also qemu 8.1) and I cannot use any value other than 256
+```
+qemu-system-x86_64: -device virtio-net-pci,mq=on,vectors=6,netdev=hostnet_34,id=dpdk_34,mac=F2:20:AF:40:12:65,bus=bridge,addr=0x7,page-per-vq=on,rx_queue_size=1024,tx_queue_size=1024,mrg_rxbuf=on,disable-legacy=on,disable-modern=off,host_mtu=1500,csum=on,guest_csum=on,host_tso4=on,host_tso6=on: Invalid tx_queue_size (= 1024), must be a power of 2 between 256 and 256
+```
+
+and I think virtqueue max size value has never changed from 1024.\
+https://gitlab.com/qemu-project/qemu/-/blob/staging-8.2/include/hw/virtio/virtio.h?ref_type=heads#L62
+Steps to reproduce:
+1. boot qemu-system-x86_64 on qemu 8.2 and network device option set tx_queue_size value over 256
+Additional information:
+- I'm using hardware vDPA offloading with mellanox NIC card.
diff --git a/results/classifier/118/device/2132 b/results/classifier/118/device/2132
new file mode 100644
index 00000000..b9d0ec61
--- /dev/null
+++ b/results/classifier/118/device/2132
@@ -0,0 +1,41 @@
+device: 0.832
+graphic: 0.798
+performance: 0.761
+kernel: 0.683
+architecture: 0.678
+mistranslation: 0.653
+register: 0.644
+semantic: 0.621
+KVM: 0.605
+permissions: 0.598
+peripherals: 0.584
+debug: 0.564
+network: 0.558
+user-level: 0.523
+PID: 0.478
+VMM: 0.475
+i386: 0.448
+boot: 0.444
+socket: 0.438
+assembly: 0.433
+vnc: 0.419
+risc-v: 0.418
+arm: 0.417
+hypervisor: 0.372
+ppc: 0.357
+x86: 0.356
+files: 0.218
+TCG: 0.214
+virtual: 0.089
+
+USB Hub as USB Host Device: Child devices not recognized in Win11
+Description of problem:
+I wanted to give the Windows environment direct access to some of the physical USB ports on my pc. So I mapped a selection of ports to Windows via the associated hub. Windows correctly recognizes the hub. Also, when devices are plugged into or removed from the associated ports, Windows recognizes the connection of a new device or its removal. However, regardless of the device, Windows reports:
+"USB device not recognized.
+The last USB device you connected to this computer has malfunctioned, and Windows does not recognize it."
+Steps to reproduce:
+1. Add one of the hosts USB hubs to a Windows VM as a USB Host Device.
+2. Verify that Windows recognizes the host hub in device manager.
+3. Try plugging in a USB device into one of the corresponding physical ports.
+Additional information:
+
diff --git a/results/classifier/118/device/2156 b/results/classifier/118/device/2156
new file mode 100644
index 00000000..0e553fc6
--- /dev/null
+++ b/results/classifier/118/device/2156
@@ -0,0 +1,45 @@
+device: 0.847
+graphic: 0.813
+x86: 0.806
+architecture: 0.795
+user-level: 0.793
+semantic: 0.723
+network: 0.631
+vnc: 0.607
+socket: 0.606
+kernel: 0.579
+PID: 0.577
+ppc: 0.509
+permissions: 0.506
+performance: 0.498
+files: 0.439
+i386: 0.438
+debug: 0.417
+TCG: 0.382
+register: 0.329
+risc-v: 0.304
+VMM: 0.297
+boot: 0.293
+arm: 0.260
+mistranslation: 0.218
+hypervisor: 0.208
+KVM: 0.128
+virtual: 0.089
+assembly: 0.070
+peripherals: 0.068
+
+Userland QEMU segfaults when emulating itself thrice
+Description of problem:
+See title. 
+```
+$ qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true
+qemu-x86_64-static: QEMU internal SIGSEGV {code=ACCERR, addr=0x7f9ae80001a0}
+[1]    15705 segmentation fault (core dumped)  qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true
+```
+Steps to reproduce:
+1. Execute command above
+Additional information:
+Coredump (~322MB uncompressed)
+[qemu_qemu-x86_64-static_20240208-123447_15705.core.xz](/uploads/a6723aaf956dfd1efc434303e62c25e2/qemu_qemu-x86_64-static_20240208-123447_15705.core.xz)
+
+SHA1: 31c2b06a61f63dca5199b64b767aa2fdeefbeec6
diff --git a/results/classifier/118/device/2158 b/results/classifier/118/device/2158
new file mode 100644
index 00000000..eafd0231
--- /dev/null
+++ b/results/classifier/118/device/2158
@@ -0,0 +1,39 @@
+device: 0.845
+graphic: 0.806
+performance: 0.687
+debug: 0.607
+vnc: 0.569
+semantic: 0.567
+virtual: 0.554
+network: 0.521
+peripherals: 0.520
+architecture: 0.500
+permissions: 0.485
+PID: 0.420
+mistranslation: 0.416
+kernel: 0.370
+socket: 0.360
+i386: 0.344
+register: 0.336
+hypervisor: 0.310
+user-level: 0.306
+risc-v: 0.304
+arm: 0.286
+boot: 0.278
+files: 0.269
+TCG: 0.254
+x86: 0.253
+ppc: 0.236
+assembly: 0.112
+KVM: 0.097
+VMM: 0.032
+
+Qemu will not release mouse even after using the release mouse keybind
+Description of problem:
+There wasn't a crash but this is an annoying problem. The mouse does not release when the VM sizes the window larger because, as far as I know, qemu moves the window and relies on the user to click to release the mouse.
+Steps to reproduce:
+1. Open qemu 
+2. Try to release the mouse using the keybind shown.
+3. It move the window and won't release.
+Additional information:
+In case it's really needed, I am using a custom QEMU VM Manager called "QEMU Manager".
diff --git a/results/classifier/118/device/2161 b/results/classifier/118/device/2161
new file mode 100644
index 00000000..18724ff6
--- /dev/null
+++ b/results/classifier/118/device/2161
@@ -0,0 +1,31 @@
+device: 0.877
+debug: 0.805
+register: 0.668
+network: 0.660
+arm: 0.599
+performance: 0.543
+risc-v: 0.516
+graphic: 0.493
+TCG: 0.457
+boot: 0.447
+files: 0.438
+architecture: 0.390
+VMM: 0.360
+socket: 0.307
+semantic: 0.269
+PID: 0.212
+vnc: 0.206
+kernel: 0.179
+permissions: 0.169
+mistranslation: 0.116
+peripherals: 0.112
+assembly: 0.109
+ppc: 0.097
+hypervisor: 0.078
+user-level: 0.052
+virtual: 0.032
+KVM: 0.013
+x86: 0.003
+i386: 0.002
+
+warnings when building lockstep plugin on s390
diff --git a/results/classifier/118/device/2164 b/results/classifier/118/device/2164
new file mode 100644
index 00000000..656c8329
--- /dev/null
+++ b/results/classifier/118/device/2164
@@ -0,0 +1,37 @@
+device: 0.876
+graphic: 0.772
+network: 0.642
+socket: 0.590
+kernel: 0.575
+register: 0.553
+vnc: 0.540
+PID: 0.505
+files: 0.466
+arm: 0.458
+semantic: 0.437
+risc-v: 0.407
+ppc: 0.387
+debug: 0.385
+VMM: 0.365
+boot: 0.354
+mistranslation: 0.339
+architecture: 0.289
+permissions: 0.277
+TCG: 0.264
+performance: 0.199
+peripherals: 0.171
+i386: 0.140
+virtual: 0.133
+KVM: 0.097
+user-level: 0.080
+hypervisor: 0.065
+assembly: 0.043
+x86: 0.017
+
+m68k: 68010 exception format is incorrect
+Description of problem:
+The exception format for the original 68000 is different to the 68010 and QEMU uses the incorrect format for 68010.
+Steps to reproduce:
+You need to have something that depends on the stack layout (i.e. nommu linux) to notice it.
+Additional information:
+I have posted a patch to fix it already: https://lists.gnu.org/archive/html/qemu-devel/2024-01/msg02800.html
diff --git a/results/classifier/118/device/217 b/results/classifier/118/device/217
new file mode 100644
index 00000000..266d3d36
--- /dev/null
+++ b/results/classifier/118/device/217
@@ -0,0 +1,31 @@
+device: 0.865
+performance: 0.727
+architecture: 0.724
+network: 0.701
+graphic: 0.635
+register: 0.543
+files: 0.541
+hypervisor: 0.530
+virtual: 0.516
+user-level: 0.494
+permissions: 0.487
+semantic: 0.441
+i386: 0.419
+arm: 0.395
+risc-v: 0.378
+vnc: 0.352
+x86: 0.351
+kernel: 0.347
+peripherals: 0.336
+mistranslation: 0.335
+ppc: 0.319
+socket: 0.297
+assembly: 0.288
+PID: 0.283
+boot: 0.271
+debug: 0.246
+TCG: 0.166
+VMM: 0.116
+KVM: 0.007
+
+Qemu does not force SSE data alignment
diff --git a/results/classifier/118/device/2174 b/results/classifier/118/device/2174
new file mode 100644
index 00000000..97206537
--- /dev/null
+++ b/results/classifier/118/device/2174
@@ -0,0 +1,31 @@
+architecture: 0.946
+device: 0.938
+performance: 0.738
+peripherals: 0.701
+network: 0.595
+graphic: 0.565
+virtual: 0.530
+semantic: 0.477
+boot: 0.454
+arm: 0.433
+socket: 0.430
+risc-v: 0.381
+vnc: 0.365
+mistranslation: 0.363
+debug: 0.357
+user-level: 0.345
+permissions: 0.318
+hypervisor: 0.303
+assembly: 0.268
+register: 0.260
+PID: 0.167
+ppc: 0.164
+VMM: 0.152
+i386: 0.147
+TCG: 0.084
+files: 0.075
+x86: 0.039
+kernel: 0.022
+KVM: 0.009
+
+XenBus machines have almost no hotplug support
diff --git a/results/classifier/118/device/2179 b/results/classifier/118/device/2179
new file mode 100644
index 00000000..24442a95
--- /dev/null
+++ b/results/classifier/118/device/2179
@@ -0,0 +1,81 @@
+device: 0.828
+semantic: 0.673
+graphic: 0.581
+PID: 0.376
+mistranslation: 0.313
+performance: 0.310
+debug: 0.224
+user-level: 0.204
+x86: 0.202
+vnc: 0.190
+kernel: 0.177
+network: 0.176
+socket: 0.168
+architecture: 0.136
+peripherals: 0.127
+risc-v: 0.125
+i386: 0.120
+ppc: 0.119
+virtual: 0.115
+permissions: 0.100
+arm: 0.088
+assembly: 0.083
+boot: 0.078
+hypervisor: 0.059
+register: 0.046
+files: 0.040
+TCG: 0.035
+KVM: 0.034
+VMM: 0.032
+
+qemu-storage-daemon: fuse export deadlock
+Steps to reproduce:
+1. Start QSD
+2. Issue a `block-stream` and a read from the fuse export at the same time 
+
+```
+Term 1:
+(QEMU) block-stream device=root job-id=job1
+{"return": {}}
+(QEMU) 
+{'timestamp': {'seconds': 1708386076, 'microseconds': 965781}, 'event': 'JOB_STATUS_CHANGE', 'data': {'status': 'created', 'id': 'job1'}}
+{'timestamp': {'seconds': 1708386076, 'microseconds': 965838}, 'event': 'JOB_STATUS_CHANGE', 'data': {'status': 'running', 'id': 'job1'}}
+(QEMU) 
+(QEMU) 
+(QEMU) 
+(QEMU) query-block-jobs
+
+<HANGS>
+
+
+Term 2:
+dd if=/tmp/fuse_exp of=/dev/null bs=1M skip=2000
+<HANGS>
+```
+
+```
+$ pidof qemu-storage-daemon 
+ 92313
+$ sudo cat /proc/92313/task/92313/stack 
+[<0>] do_sys_poll+0x4e1/0x5d0
+[<0>] __x64_sys_ppoll+0xe2/0x170
+[<0>] do_syscall_64+0x64/0xe0
+[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
+
+$ sudo cat /proc/92313/task/92314/stack 
+[<0>] futex_wait_queue+0x63/0x90
+[<0>] __futex_wait+0x14f/0x1c0
+[<0>] futex_wait+0x77/0x110
+[<0>] do_futex+0xcb/0x190
+[<0>] __x64_sys_futex+0x129/0x1e0
+[<0>] do_syscall_64+0x64/0xe0
+[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
+```
+Additional information:
+This might also be a general between `block-stream` and `copy-on-read` but I could only trigger the problem with FUSE and not NBD. E.g this command does not deadlock:
+```
+--export type=nbd,id=nbd-root,node-name=root_crw,name=root_crw,writable=off 
+
+nbdfuse /tmp/tmp.69dRvNXj1O/disk nbd://localhost:10809/root_crw
+dd if=/tmp/tmp.69dRvNXj1O/disk of=/dev/null bs=1M skip=2000
+```
diff --git a/results/classifier/118/device/219 b/results/classifier/118/device/219
new file mode 100644
index 00000000..7de9fdee
--- /dev/null
+++ b/results/classifier/118/device/219
@@ -0,0 +1,31 @@
+device: 0.926
+peripherals: 0.863
+permissions: 0.694
+performance: 0.617
+architecture: 0.477
+mistranslation: 0.393
+semantic: 0.393
+arm: 0.317
+graphic: 0.304
+hypervisor: 0.291
+boot: 0.220
+risc-v: 0.171
+virtual: 0.139
+user-level: 0.137
+socket: 0.121
+ppc: 0.115
+assembly: 0.090
+network: 0.084
+files: 0.068
+register: 0.067
+PID: 0.037
+i386: 0.034
+vnc: 0.030
+TCG: 0.027
+VMM: 0.026
+debug: 0.020
+x86: 0.004
+kernel: 0.004
+KVM: 0.002
+
+Request A Port of QEMU to UWP for xbox dev mode
diff --git a/results/classifier/118/device/2192 b/results/classifier/118/device/2192
new file mode 100644
index 00000000..829598fe
--- /dev/null
+++ b/results/classifier/118/device/2192
@@ -0,0 +1,31 @@
+device: 0.848
+virtual: 0.788
+VMM: 0.685
+mistranslation: 0.648
+network: 0.640
+architecture: 0.445
+files: 0.399
+performance: 0.359
+graphic: 0.357
+semantic: 0.325
+PID: 0.250
+x86: 0.233
+permissions: 0.229
+boot: 0.222
+i386: 0.204
+user-level: 0.177
+peripherals: 0.172
+ppc: 0.166
+vnc: 0.162
+debug: 0.161
+TCG: 0.151
+socket: 0.139
+arm: 0.109
+register: 0.098
+hypervisor: 0.073
+KVM: 0.039
+assembly: 0.039
+risc-v: 0.021
+kernel: 0.017
+
+make vm-build-openbsd tries to download nonexistent 7.2 install ISO: need to update to 7.4
diff --git a/results/classifier/118/device/220 b/results/classifier/118/device/220
new file mode 100644
index 00000000..7431edd0
--- /dev/null
+++ b/results/classifier/118/device/220
@@ -0,0 +1,31 @@
+device: 0.857
+graphic: 0.785
+performance: 0.643
+debug: 0.606
+VMM: 0.443
+boot: 0.390
+register: 0.377
+risc-v: 0.330
+PID: 0.266
+ppc: 0.237
+kernel: 0.216
+KVM: 0.206
+peripherals: 0.191
+TCG: 0.183
+permissions: 0.173
+vnc: 0.139
+semantic: 0.126
+user-level: 0.111
+mistranslation: 0.059
+network: 0.051
+architecture: 0.033
+assembly: 0.033
+arm: 0.027
+virtual: 0.023
+files: 0.014
+socket: 0.010
+hypervisor: 0.004
+i386: 0.000
+x86: 0.000
+
+Broken mouse movement inside MS-DOS for at least one program
diff --git a/results/classifier/118/device/2201 b/results/classifier/118/device/2201
new file mode 100644
index 00000000..b908b59b
--- /dev/null
+++ b/results/classifier/118/device/2201
@@ -0,0 +1,41 @@
+device: 0.915
+graphic: 0.852
+vnc: 0.830
+permissions: 0.817
+performance: 0.718
+semantic: 0.696
+socket: 0.686
+architecture: 0.684
+arm: 0.660
+PID: 0.655
+network: 0.655
+VMM: 0.642
+register: 0.622
+risc-v: 0.615
+mistranslation: 0.584
+hypervisor: 0.582
+kernel: 0.572
+virtual: 0.549
+assembly: 0.496
+debug: 0.478
+ppc: 0.470
+TCG: 0.452
+boot: 0.383
+peripherals: 0.369
+files: 0.366
+KVM: 0.345
+user-level: 0.272
+i386: 0.272
+x86: 0.246
+
+Windows 11 Guests ExtendedDesktopSize Not Working
+Description of problem:
+Windows 11 VM with the latest virtio-win drivers installed (v0.1.240) does not respond to remote resize requests.
+Steps to reproduce:
+1. Create a Windows 11 VM with virtio-win drivers installed and virtio video enabled.
+2. Create a VNC session with resizeSession enabled.
+3. Try resizing the window.
+Additional information:
+The resolution can be resized within the VM itself (i.e., from display settings), just doesn't automatically resize when the viewing window changes. Other VMs (including Windows 10) created and viewed within the same setup do change with the window resize.
+
+The Chrome console log has a number of `Server did not accept resize request: Unknown reason` errors in it.
diff --git a/results/classifier/118/device/221 b/results/classifier/118/device/221
new file mode 100644
index 00000000..3c1fe2fa
--- /dev/null
+++ b/results/classifier/118/device/221
@@ -0,0 +1,31 @@
+device: 0.937
+performance: 0.923
+peripherals: 0.874
+network: 0.850
+graphic: 0.798
+arm: 0.573
+debug: 0.506
+mistranslation: 0.502
+boot: 0.386
+architecture: 0.283
+permissions: 0.261
+user-level: 0.242
+semantic: 0.215
+hypervisor: 0.206
+socket: 0.175
+ppc: 0.120
+PID: 0.085
+register: 0.074
+assembly: 0.066
+VMM: 0.055
+files: 0.045
+virtual: 0.041
+TCG: 0.031
+vnc: 0.022
+risc-v: 0.012
+i386: 0.008
+kernel: 0.004
+KVM: 0.002
+x86: 0.002
+
+piix crashes on mips when accessing acpi-pci-hotplug
diff --git a/results/classifier/118/device/2213 b/results/classifier/118/device/2213
new file mode 100644
index 00000000..1f332273
--- /dev/null
+++ b/results/classifier/118/device/2213
@@ -0,0 +1,45 @@
+device: 0.935
+graphic: 0.929
+peripherals: 0.761
+boot: 0.646
+vnc: 0.616
+architecture: 0.593
+semantic: 0.588
+performance: 0.585
+debug: 0.546
+register: 0.528
+permissions: 0.524
+mistranslation: 0.520
+hypervisor: 0.484
+socket: 0.471
+PID: 0.469
+kernel: 0.440
+risc-v: 0.369
+ppc: 0.361
+network: 0.346
+x86: 0.340
+files: 0.337
+VMM: 0.330
+user-level: 0.256
+arm: 0.222
+i386: 0.208
+assembly: 0.175
+virtual: 0.144
+TCG: 0.140
+KVM: 0.031
+
+QEMU fails with duplicate SaveStateEntry when using two legacy virtio input devices
+Description of problem:
+QEMU bails out when it is started with two virtio-input devices running in legacy virtio mode, using two different transports (like PCI and CCW on s390x).
+Steps to reproduce:
+```
+qemu-system-s390x -M s390-ccw-virtio-2.6 -cpu max -nographic -device virtio-multitouch-pci -device virtio-tablet-ccw
+```
+fails with:
+```
+qemu-system-s390x: -device virtio-tablet-ccw: savevm_state_handler_insert: Detected duplicate SaveStateEntry: id=virtio-input, instance_id=0x0
+```
+Additional information:
+The problem does *not* occur if using modern virtio devices (which automatically happens for -M s390-ccw-virtio-2.7 and newer) or if using virtio-input devices with the same transport (e.g. two PCI devices instead of one PCI and one CCW).
+
+Also note that the problem only occurs since QEMU 8.1 since older versions did not check for duplicate SaveStateEntries (see commit caa91b3c44cdb2d2921e25 ).
diff --git a/results/classifier/118/device/2215 b/results/classifier/118/device/2215
new file mode 100644
index 00000000..7424d731
--- /dev/null
+++ b/results/classifier/118/device/2215
@@ -0,0 +1,31 @@
+device: 0.858
+performance: 0.805
+debug: 0.643
+network: 0.568
+graphic: 0.552
+architecture: 0.518
+VMM: 0.506
+arm: 0.469
+files: 0.430
+vnc: 0.390
+semantic: 0.381
+register: 0.374
+permissions: 0.361
+mistranslation: 0.314
+ppc: 0.296
+assembly: 0.274
+TCG: 0.261
+PID: 0.255
+boot: 0.243
+peripherals: 0.216
+socket: 0.190
+risc-v: 0.184
+hypervisor: 0.173
+virtual: 0.155
+user-level: 0.116
+kernel: 0.079
+x86: 0.062
+i386: 0.042
+KVM: 0.040
+
+qemu-8.2.2 compile failure against musl
diff --git a/results/classifier/118/device/2218 b/results/classifier/118/device/2218
new file mode 100644
index 00000000..851d4df8
--- /dev/null
+++ b/results/classifier/118/device/2218
@@ -0,0 +1,42 @@
+device: 0.878
+graphic: 0.831
+performance: 0.807
+files: 0.771
+permissions: 0.718
+debug: 0.683
+network: 0.656
+boot: 0.613
+mistranslation: 0.612
+kernel: 0.572
+VMM: 0.564
+PID: 0.546
+register: 0.543
+TCG: 0.543
+semantic: 0.542
+risc-v: 0.536
+architecture: 0.525
+peripherals: 0.506
+vnc: 0.499
+KVM: 0.496
+ppc: 0.466
+i386: 0.458
+arm: 0.449
+user-level: 0.440
+socket: 0.417
+x86: 0.344
+virtual: 0.331
+hypervisor: 0.266
+assembly: 0.241
+
+MIDI playback issue on Windows 98 / 2000 / XP guest
+Description of problem:
+In Windows 98 / 2000 / XP guest, playback MIDI using Windows Media Player will cause audio slow.
+
+In Windows 98 / 2000 / XP guest, playback MP3 or WMA or WAV using Windows Media Player is works OK.
+Steps to reproduce:
+1. In Windows XP guest, open C:\WINDOWS\Media\Flourish.mid using Windows Media Player.
+2. In Windows XP guest, open C:\WINDOWS\System32\OOBE\images\title.wma using Windows Media Player.
+3. In Windows 98 guest, open C:\WINDOWS\Media\Passport.mid using Windows Media Player.
+4. In Windows 98 guest, open C:\WINDOWS\Application Data\Microsoft\WELCOME\WELCOM98.WAV using Windows Media Player.
+Additional information:
+
diff --git a/results/classifier/118/device/2222 b/results/classifier/118/device/2222
new file mode 100644
index 00000000..0ea40e8a
--- /dev/null
+++ b/results/classifier/118/device/2222
@@ -0,0 +1,31 @@
+device: 0.915
+performance: 0.663
+mistranslation: 0.646
+network: 0.585
+graphic: 0.515
+files: 0.478
+architecture: 0.469
+arm: 0.467
+debug: 0.263
+semantic: 0.253
+peripherals: 0.230
+permissions: 0.205
+assembly: 0.172
+virtual: 0.147
+user-level: 0.137
+boot: 0.114
+hypervisor: 0.099
+register: 0.098
+i386: 0.095
+PID: 0.081
+socket: 0.064
+ppc: 0.041
+x86: 0.039
+risc-v: 0.033
+kernel: 0.017
+vnc: 0.015
+VMM: 0.012
+TCG: 0.004
+KVM: 0.003
+
+elf2dmp has endianness bugs
diff --git a/results/classifier/118/device/224 b/results/classifier/118/device/224
new file mode 100644
index 00000000..e15c7412
--- /dev/null
+++ b/results/classifier/118/device/224
@@ -0,0 +1,31 @@
+device: 0.956
+peripherals: 0.871
+debug: 0.869
+performance: 0.825
+architecture: 0.814
+mistranslation: 0.797
+graphic: 0.732
+network: 0.665
+risc-v: 0.623
+arm: 0.613
+boot: 0.363
+vnc: 0.329
+ppc: 0.300
+semantic: 0.297
+register: 0.293
+VMM: 0.257
+TCG: 0.208
+permissions: 0.199
+PID: 0.153
+socket: 0.146
+hypervisor: 0.103
+user-level: 0.082
+virtual: 0.079
+assembly: 0.076
+kernel: 0.066
+files: 0.024
+KVM: 0.021
+i386: 0.018
+x86: 0.016
+
+Wrong interrupts generated for I.MX6 FEC controller
diff --git a/results/classifier/118/device/2243 b/results/classifier/118/device/2243
new file mode 100644
index 00000000..4137c975
--- /dev/null
+++ b/results/classifier/118/device/2243
@@ -0,0 +1,39 @@
+device: 0.938
+graphic: 0.853
+register: 0.762
+peripherals: 0.669
+permissions: 0.530
+risc-v: 0.527
+socket: 0.525
+semantic: 0.520
+VMM: 0.483
+boot: 0.475
+debug: 0.468
+mistranslation: 0.445
+arm: 0.443
+vnc: 0.437
+files: 0.435
+architecture: 0.422
+TCG: 0.410
+PID: 0.397
+network: 0.366
+performance: 0.354
+user-level: 0.318
+ppc: 0.270
+KVM: 0.199
+x86: 0.197
+kernel: 0.160
+hypervisor: 0.145
+i386: 0.135
+assembly: 0.133
+virtual: 0.105
+
+ES1370 sound card can crash the Windows 2000 and Windows XP guest.
+Description of problem:
+If using ES1370 sound card with Windows 2000 and Windows XP guest, it will crash the Windows 2000 and Windows XP guest. Windows 2000 and Windows XP have built in ES1370 driver.
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/118/device/225 b/results/classifier/118/device/225
new file mode 100644
index 00000000..26ef9c9e
--- /dev/null
+++ b/results/classifier/118/device/225
@@ -0,0 +1,31 @@
+device: 0.850
+semantic: 0.673
+TCG: 0.605
+user-level: 0.588
+performance: 0.503
+graphic: 0.479
+arm: 0.460
+PID: 0.447
+virtual: 0.427
+ppc: 0.416
+network: 0.386
+mistranslation: 0.342
+risc-v: 0.327
+assembly: 0.318
+kernel: 0.312
+debug: 0.306
+architecture: 0.297
+vnc: 0.270
+register: 0.255
+VMM: 0.230
+permissions: 0.228
+boot: 0.186
+hypervisor: 0.184
+socket: 0.127
+files: 0.089
+peripherals: 0.064
+i386: 0.054
+KVM: 0.051
+x86: 0.023
+
+Menu is not clickable on OSX Catalina
diff --git a/results/classifier/118/device/2268 b/results/classifier/118/device/2268
new file mode 100644
index 00000000..483ec6b0
--- /dev/null
+++ b/results/classifier/118/device/2268
@@ -0,0 +1,73 @@
+device: 0.934
+risc-v: 0.925
+ppc: 0.913
+arm: 0.913
+debug: 0.910
+register: 0.907
+kernel: 0.902
+assembly: 0.902
+network: 0.900
+PID: 0.896
+permissions: 0.895
+performance: 0.892
+boot: 0.883
+files: 0.880
+peripherals: 0.879
+TCG: 0.858
+architecture: 0.857
+graphic: 0.855
+user-level: 0.837
+socket: 0.826
+semantic: 0.784
+hypervisor: 0.736
+vnc: 0.729
+mistranslation: 0.716
+x86: 0.666
+virtual: 0.662
+i386: 0.638
+VMM: 0.585
+KVM: 0.556
+
+Out of bounds access in smc91c111_readb()
+Description of problem:
+I detected an out-of-bounds access in smc91c111_readb with my fuzzer.
+
+Stack trace (part):\
+`hw/net/smc91c111.c:607:24: runtime error: index 175 out of bounds for`\
+`type 'uint8_t[4][2048]' (aka 'unsigned char[4][2048]')`\
+`SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior`\
+`hw/net/smc91c111.c:607:24 in`\
+`AddressSanitizer:DEADLYSIGNAL`\
+`==============================`<wbr>`==============================`<wbr>`=====`\
+`==397944==ERROR: AddressSanitizer: SEGV on unknown address`\
+`0x629000077db4 (pc 0x56272aed3b8d bp 0x7ffd1471f290 sp 0x7ffd1471ea20`\
+`T0)`\
+`==397944==The signal is caused by a READ memory access.`\
+    `#0 0x56272aed3b8d in smc91c111_readb hw/net/smc91c111.c:607:24`\
+    `#1 0x56272aecfd61 in smc91c111_readfn hw/net/smc91c111.c:650:16`\
+    `#2 0x56272d4b228b in memory_region_read_accessor system/memory.c:445:11`\
+    `#3 0x56272d46fb85 in access_with_adjusted_size system/memory.c:573:18`\
+    `#4 0x56272d46c58e in memory_region_dispatch_read1 system/memory.c:1426:16`\
+    `#5 0x56272d46bcd7 in memory_region_dispatch_read system/memory.c:1459:9`\
+    `#6 0x56272d4e8e03 in flatview_read_continue_step system/physmem.c:2794:18`\
+    `#7 0x56272d4e871e in flatview_read_continue system/physmem.c:2835:19`\
+    `#8 0x56272d4e98b8 in flatview_read system/physmem.c:2865:12`\
+    `#9 0x56272d4e9388 in address_space_read_full system/physmem.c:2878:18`\
+    `#10 0x56272d6e7840 in address_space_read include/exec/memory.h:3026:18`\
+`...`\
+Bug analysis: I found s-\>packet_num = 175 at line 599.
+Steps to reproduce:
+Reproducer:\
+export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine\
+mainstone"\
+cat \<\< EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio\
+outl 0xcf8 0x80000010\
+outl 0xcfc 0x10000300\
+outl 0xcf8 0x80000004\
+outl 0xcfc 0x07\
+writel 0x1000030c 0x66027cd6\
+writel 0x10000300 0x64af8eda\
+readw 0x10000308\
+EOF
+Additional information:
+Ack: Chuhong Yuan (hslester96@gmail.com)
diff --git a/results/classifier/118/device/2275 b/results/classifier/118/device/2275
new file mode 100644
index 00000000..00e0f5f0
--- /dev/null
+++ b/results/classifier/118/device/2275
@@ -0,0 +1,39 @@
+device: 0.842
+performance: 0.734
+graphic: 0.697
+vnc: 0.673
+risc-v: 0.623
+VMM: 0.616
+network: 0.544
+register: 0.533
+debug: 0.473
+files: 0.419
+kernel: 0.417
+arm: 0.336
+semantic: 0.333
+boot: 0.327
+ppc: 0.215
+KVM: 0.200
+socket: 0.189
+virtual: 0.189
+permissions: 0.160
+mistranslation: 0.140
+PID: 0.131
+user-level: 0.108
+architecture: 0.094
+hypervisor: 0.091
+assembly: 0.087
+TCG: 0.060
+peripherals: 0.058
+i386: 0.041
+x86: 0.023
+
+qemu crash
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/118/device/2282 b/results/classifier/118/device/2282
new file mode 100644
index 00000000..9cdcc476
--- /dev/null
+++ b/results/classifier/118/device/2282
@@ -0,0 +1,31 @@
+device: 0.950
+architecture: 0.897
+graphic: 0.863
+arm: 0.748
+performance: 0.594
+debug: 0.463
+ppc: 0.359
+virtual: 0.277
+semantic: 0.242
+network: 0.238
+files: 0.234
+risc-v: 0.170
+permissions: 0.124
+vnc: 0.119
+TCG: 0.112
+mistranslation: 0.110
+PID: 0.105
+VMM: 0.103
+register: 0.084
+user-level: 0.061
+hypervisor: 0.046
+peripherals: 0.024
+x86: 0.020
+i386: 0.018
+boot: 0.016
+socket: 0.007
+assembly: 0.006
+KVM: 0.003
+kernel: 0.003
+
+Corrupted output when using Intel Arc GPU with qemu+spice+virgl in headed mode
diff --git a/results/classifier/118/device/2285 b/results/classifier/118/device/2285
new file mode 100644
index 00000000..32424704
--- /dev/null
+++ b/results/classifier/118/device/2285
@@ -0,0 +1,31 @@
+device: 0.854
+graphic: 0.714
+performance: 0.684
+mistranslation: 0.664
+network: 0.633
+semantic: 0.408
+boot: 0.363
+arm: 0.309
+register: 0.257
+virtual: 0.210
+hypervisor: 0.188
+VMM: 0.188
+peripherals: 0.186
+debug: 0.166
+vnc: 0.154
+permissions: 0.146
+user-level: 0.119
+files: 0.114
+KVM: 0.113
+TCG: 0.099
+kernel: 0.089
+architecture: 0.086
+PID: 0.062
+socket: 0.037
+risc-v: 0.034
+ppc: 0.027
+assembly: 0.020
+x86: 0.014
+i386: 0.005
+
+cross-i686-tci job intermittent timeouts
diff --git a/results/classifier/118/device/2306 b/results/classifier/118/device/2306
new file mode 100644
index 00000000..50811f96
--- /dev/null
+++ b/results/classifier/118/device/2306
@@ -0,0 +1,31 @@
+device: 0.857
+arm: 0.539
+debug: 0.499
+performance: 0.436
+graphic: 0.363
+network: 0.320
+boot: 0.266
+i386: 0.260
+permissions: 0.246
+x86: 0.196
+VMM: 0.191
+KVM: 0.135
+architecture: 0.130
+TCG: 0.125
+files: 0.113
+risc-v: 0.112
+semantic: 0.107
+ppc: 0.092
+PID: 0.066
+virtual: 0.064
+register: 0.052
+mistranslation: 0.040
+vnc: 0.035
+hypervisor: 0.028
+user-level: 0.027
+assembly: 0.024
+peripherals: 0.020
+socket: 0.010
+kernel: 0.002
+
+A bug of ptimer that the freq can't set more than 1000M
diff --git a/results/classifier/118/device/2314 b/results/classifier/118/device/2314
new file mode 100644
index 00000000..8f654bf0
--- /dev/null
+++ b/results/classifier/118/device/2314
@@ -0,0 +1,46 @@
+device: 0.873
+graphic: 0.768
+network: 0.686
+PID: 0.685
+files: 0.680
+vnc: 0.678
+semantic: 0.656
+permissions: 0.623
+socket: 0.617
+ppc: 0.555
+architecture: 0.514
+kernel: 0.512
+boot: 0.494
+register: 0.460
+risc-v: 0.434
+debug: 0.414
+arm: 0.398
+TCG: 0.337
+hypervisor: 0.298
+user-level: 0.291
+performance: 0.264
+mistranslation: 0.258
+peripherals: 0.213
+VMM: 0.207
+virtual: 0.199
+assembly: 0.184
+i386: 0.162
+x86: 0.139
+KVM: 0.098
+
+Building QEMU 9.0.0 fails on MacOS 10.15.7 (error: initializing 'NSEdgeInsets' (aka 'struct NSEdgeInsets') with an expression of incompatible type 'id')
+Description of problem:
+QEMU fails to compile using Homebrew on OS X 10.15.7:
+```
+../ui/cocoa.m:542:18: error: initializing 'NSEdgeInsets' (aka 'struct NSEdgeInsets') with an expression of incompatible type 'id'
+    NSEdgeInsets insets = [[[self window] screen] safeAreaInsets];
+                 ^        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+1 error generated.
+```
+Steps to reproduce:
+1. Compile QEMU on OS X 10.15.7 using Homebrew
+2.
+3.
+Additional information:
+Build log
+[02.make.zip](/uploads/dfb618b86984ed6cf699d94bf9d6c9e1/02.make.zip)
diff --git a/results/classifier/118/device/2317 b/results/classifier/118/device/2317
new file mode 100644
index 00000000..c6427ac2
--- /dev/null
+++ b/results/classifier/118/device/2317
@@ -0,0 +1,68 @@
+device: 0.841
+ppc: 0.814
+register: 0.813
+socket: 0.672
+permissions: 0.667
+graphic: 0.665
+vnc: 0.650
+hypervisor: 0.644
+kernel: 0.641
+performance: 0.638
+architecture: 0.630
+network: 0.620
+semantic: 0.613
+assembly: 0.550
+boot: 0.545
+risc-v: 0.518
+peripherals: 0.494
+mistranslation: 0.480
+PID: 0.474
+files: 0.448
+arm: 0.443
+debug: 0.369
+user-level: 0.317
+VMM: 0.300
+x86: 0.274
+i386: 0.240
+TCG: 0.232
+KVM: 0.048
+virtual: 0.026
+
+SH4:  ADDV instruction not emulated properly
+Description of problem:
+ADDV opcode is emulated incorrectly.
+
+The documentation says:
+
+`ADDV Rm, Rn        Rn + Rm -> Rn, overflow -> T`
+
+What Qemu actually emulates:
+
+`ADDV Rm, Rn        Rn + Rm -> Rm, overflow -> T`
+Steps to reproduce:
+```c
+#include <stdio.h>
+
+int main(void)
+{
+	register unsigned int a asm("r8") = 0x7fffffff;
+	register unsigned int b asm("r9") = 1;
+	register unsigned int c asm("r10");
+
+	asm volatile("clrt\n"
+		     "addv %2,%0\n"
+		     "movt %1\n"
+		     : "+r"(a), "=r"(c) : "r"(b) :);
+
+	printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c);
+
+	return 0;
+}
+
+```
+Additional information:
+Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints:
+`Values: a=0x80000000 b=0x1 c=0x1`
+
+Running with Qemu (and GCC 13.0), the same program prints:
+`Values: a=0x7fffffff b=0x80000000 c=0x1`
diff --git a/results/classifier/118/device/232 b/results/classifier/118/device/232
new file mode 100644
index 00000000..555425a0
--- /dev/null
+++ b/results/classifier/118/device/232
@@ -0,0 +1,31 @@
+device: 0.846
+performance: 0.609
+network: 0.566
+socket: 0.518
+ppc: 0.402
+graphic: 0.368
+arm: 0.366
+architecture: 0.340
+peripherals: 0.326
+debug: 0.254
+vnc: 0.197
+PID: 0.193
+risc-v: 0.187
+i386: 0.179
+x86: 0.129
+hypervisor: 0.120
+TCG: 0.111
+semantic: 0.109
+kernel: 0.098
+files: 0.078
+VMM: 0.076
+mistranslation: 0.064
+boot: 0.063
+virtual: 0.050
+register: 0.042
+user-level: 0.041
+permissions: 0.040
+KVM: 0.016
+assembly: 0.010
+
+I/O write make QXL abort in qxl_set_mode()
diff --git a/results/classifier/118/device/2329 b/results/classifier/118/device/2329
new file mode 100644
index 00000000..391f6f5c
--- /dev/null
+++ b/results/classifier/118/device/2329
@@ -0,0 +1,31 @@
+device: 0.803
+architecture: 0.677
+graphic: 0.523
+performance: 0.478
+mistranslation: 0.452
+permissions: 0.336
+semantic: 0.295
+user-level: 0.280
+arm: 0.178
+virtual: 0.176
+peripherals: 0.158
+hypervisor: 0.154
+boot: 0.125
+VMM: 0.109
+PID: 0.100
+register: 0.075
+debug: 0.059
+files: 0.048
+vnc: 0.042
+risc-v: 0.038
+network: 0.037
+KVM: 0.024
+ppc: 0.021
+TCG: 0.017
+assembly: 0.016
+socket: 0.011
+kernel: 0.010
+x86: 0.006
+i386: 0.001
+
+Windows 64-bit, qemu-monitor, change
diff --git a/results/classifier/118/device/233 b/results/classifier/118/device/233
new file mode 100644
index 00000000..127188b9
--- /dev/null
+++ b/results/classifier/118/device/233
@@ -0,0 +1,31 @@
+device: 0.874
+architecture: 0.755
+network: 0.689
+semantic: 0.544
+performance: 0.540
+hypervisor: 0.481
+boot: 0.481
+arm: 0.444
+peripherals: 0.347
+graphic: 0.330
+files: 0.328
+register: 0.279
+permissions: 0.269
+assembly: 0.245
+mistranslation: 0.237
+virtual: 0.202
+x86: 0.161
+i386: 0.153
+socket: 0.116
+user-level: 0.103
+ppc: 0.093
+risc-v: 0.091
+kernel: 0.085
+PID: 0.063
+vnc: 0.052
+debug: 0.020
+TCG: 0.015
+VMM: 0.014
+KVM: 0.002
+
+QEMU installer with WHPX support
diff --git a/results/classifier/118/device/2336 b/results/classifier/118/device/2336
new file mode 100644
index 00000000..694994ff
--- /dev/null
+++ b/results/classifier/118/device/2336
@@ -0,0 +1,53 @@
+x86: 0.953
+device: 0.944
+graphic: 0.928
+architecture: 0.920
+files: 0.895
+user-level: 0.873
+PID: 0.838
+network: 0.804
+performance: 0.778
+semantic: 0.744
+debug: 0.738
+permissions: 0.630
+ppc: 0.609
+vnc: 0.607
+socket: 0.599
+boot: 0.555
+kernel: 0.548
+hypervisor: 0.509
+VMM: 0.490
+TCG: 0.483
+risc-v: 0.351
+register: 0.302
+virtual: 0.273
+arm: 0.268
+mistranslation: 0.227
+assembly: 0.182
+KVM: 0.107
+peripherals: 0.090
+i386: 0.018
+
+qemu-x86_64 crash on LoongArch
+Description of problem:
+
+Steps to reproduce:
+1. build a static  hello test on x86_64 machine.
+2. build qemu-x86_64 on LoongArch.
+3. run 'qemu-x86_64 hello 'on LoongArch.
+Additional information:
+1  result
+
+[root@localhost qemu]# ./build/qemu-x86_64 ~/hello  
+Bus error (core dumped)
+
+2  Since commit 45bf0e7aa648369cf8ab2333bd20144806fc1be3 
+
+3  full log with -d in_asm,op,out_asm,strace
+see log.txt
+
+[log.txt](/uploads/9a0e3250bfafa6db31d6688b8c60feb7/log.txt)
+
+[qemu-x86_64](/uploads/728fc4f4633054097b6028cd99a20e8b/qemu-x86_64)
+
+[hello](/uploads/d7dec3bdb844273a8e26464ed418c1a0/hello)
diff --git a/results/classifier/118/device/2348 b/results/classifier/118/device/2348
new file mode 100644
index 00000000..13184167
--- /dev/null
+++ b/results/classifier/118/device/2348
@@ -0,0 +1,37 @@
+mistranslation: 0.956
+device: 0.935
+graphic: 0.840
+architecture: 0.796
+semantic: 0.717
+performance: 0.700
+boot: 0.679
+debug: 0.656
+peripherals: 0.557
+permissions: 0.503
+arm: 0.490
+risc-v: 0.489
+PID: 0.429
+TCG: 0.414
+vnc: 0.401
+assembly: 0.378
+register: 0.356
+i386: 0.292
+files: 0.286
+user-level: 0.274
+ppc: 0.249
+VMM: 0.226
+kernel: 0.207
+x86: 0.171
+hypervisor: 0.137
+virtual: 0.109
+socket: 0.099
+network: 0.050
+KVM: 0.040
+
+Grabbing is not possible with menu-mode disabled
+Description of problem:
+When starting a Qemu and bringing it into Focus, I expected Ctrl + Alt + g to enable Input Grab mode. This does not occur when the menu-bar is hidden. It does occur when the menu-bar is visible.
+Steps to reproduce:
+1. Open a QEMU instance in a Arch / KDE host (not fullscreen)
+2. Focus the instance and attempt to enable Input Grabbing (Ctrl + Alt + G)
+3. Observe that Input Grab Mode is not toggled
diff --git a/results/classifier/118/device/2351 b/results/classifier/118/device/2351
new file mode 100644
index 00000000..a2092522
--- /dev/null
+++ b/results/classifier/118/device/2351
@@ -0,0 +1,45 @@
+device: 0.918
+ppc: 0.866
+graphic: 0.809
+network: 0.807
+PID: 0.792
+performance: 0.788
+socket: 0.721
+files: 0.721
+architecture: 0.677
+vnc: 0.618
+semantic: 0.577
+arm: 0.562
+peripherals: 0.558
+TCG: 0.556
+permissions: 0.549
+debug: 0.544
+register: 0.509
+boot: 0.449
+user-level: 0.443
+risc-v: 0.409
+kernel: 0.398
+VMM: 0.381
+mistranslation: 0.294
+i386: 0.281
+x86: 0.209
+hypervisor: 0.148
+virtual: 0.131
+assembly: 0.083
+KVM: 0.072
+
+Raspberry Pi: Unable to start raspios bookworm
+Description of problem:
+I am able to start RaspiOS bullseye (2023-05-03-raspios-bullseye-arm64-lite) in both, the rpi3 and rpi4 configurations, by first extracting the DTB and the kernel from the downloaded image (see the command lines).
+
+When I attempt to start RaspiOS bookworm (2024-03-15-raspios-bookworm-arm64-lite), I only get the following messages on the host's terminal:
+
+```
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+usbnet: failed control transaction: request 0x8006 value 0x600 index 0x0 length 0xa
+```
+
+[start-raspios.sh](/uploads/041fb113d1d0d920e52f3b11a9f51290/start-raspios.sh)
+Steps to reproduce:
+To reproduce, adapt the attached script, download the raspios images and run it.
diff --git a/results/classifier/118/device/2357 b/results/classifier/118/device/2357
new file mode 100644
index 00000000..ee988a49
--- /dev/null
+++ b/results/classifier/118/device/2357
@@ -0,0 +1,48 @@
+device: 0.935
+graphic: 0.916
+performance: 0.851
+network: 0.795
+ppc: 0.763
+architecture: 0.757
+socket: 0.753
+peripherals: 0.725
+kernel: 0.717
+vnc: 0.701
+PID: 0.694
+register: 0.669
+debug: 0.669
+files: 0.655
+arm: 0.588
+semantic: 0.553
+TCG: 0.490
+hypervisor: 0.460
+boot: 0.402
+VMM: 0.397
+i386: 0.287
+user-level: 0.284
+virtual: 0.281
+permissions: 0.274
+KVM: 0.267
+risc-v: 0.237
+mistranslation: 0.206
+assembly: 0.163
+x86: 0.122
+
+assert in dwc2
+Description of problem:
+The following log reveals it:
+
+```
+ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached
+Bail out! ERROR:../hw/usb/hcd-dwc2.c:1131:dwc2_hsotg_read: code should not be reached
+Aborted
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-aarch64 -display \
+none -machine accel=qtest, -m 512M -machine raspi2b -m 1G -nodefaults \
+-usb -drive file=null-co://,if=none,format=raw,id=disk0 -device \
+usb-storage,port=1,drive=disk0 -qtest stdio
+readl 0x3f980dfb
+EOF
+```
diff --git a/results/classifier/118/device/2362 b/results/classifier/118/device/2362
new file mode 100644
index 00000000..03707914
--- /dev/null
+++ b/results/classifier/118/device/2362
@@ -0,0 +1,93 @@
+device: 0.866
+graphic: 0.845
+virtual: 0.844
+architecture: 0.830
+debug: 0.819
+performance: 0.803
+semantic: 0.795
+register: 0.776
+network: 0.774
+socket: 0.752
+arm: 0.744
+PID: 0.735
+VMM: 0.723
+hypervisor: 0.723
+permissions: 0.703
+assembly: 0.698
+vnc: 0.696
+mistranslation: 0.660
+risc-v: 0.656
+boot: 0.646
+files: 0.645
+KVM: 0.643
+peripherals: 0.635
+kernel: 0.631
+TCG: 0.625
+user-level: 0.579
+ppc: 0.565
+x86: 0.512
+i386: 0.193
+
+short packets dropped by some network cards when using certain network backends
+Description of problem:
+Effectively a duplicate of https://gitlab.com/qemu-project/qemu/-/issues/2058 -- short ethernet packets (such as ARP packets) are discarded by various networking devices now.
+
+QEMU previously padded ethernet frames to 64 bytes when some network cards received them, but this was removed in various commits (140eae9c8f760e9260356fe9b56b802a02f0a9d2, c445f200ad241b443aa7a61a5381b26f56a18f0e, c58da33f2f8410b6f22cd1d33377dadf3a4d8867, 05db4476c5d25e437d807175de9f862bf5bf732c, 6d0d261dbfa6122e9b3bdcab7d934ca49f069c21, 63b901bfd30a0975bc326ba8527880fabac2e66, aee87b43fe2206acb8f5e334b42790df33a1cbad).
+
+969e50b61a285b0cc8dea6d4d2ade3f758d5ecc7 fixed SLIRP and TAP support, however the other various network backends (socket, dgram, vde, others) all have the same issue that some network cards will reject short packets.
+
+This does not fail on older versions of QEMU.
+Steps to reproduce:
+I have a python script that shows connecting two VMs of your choice using a socketpair connected to one of the affected NIC types (pcnet). If you start your OS (I used alpine linux as my test), and give each VM a unique IP address (eg, `ip addr add 192.168.0.1/24 dev eth0`), ping will fail to work. When you run tcpdump, you can see that the OS is sending out short ARP packets, but the other VM cannot see them.
+
+Using an older version of QEMU allows the ping to succeed.
+
+```python
+#!/usr/bin/env python3
+
+import argparse
+import shlex
+import socket
+import subprocess
+
+
+QEMU_PATH = "bin/qemu-system-x86_64"
+NIC = "pcnet"
+vnc = True
+
+if __name__ == "__main__":
+    parser = argparse.ArgumentParser()
+    parser.add_argument("qcow")
+    args = parser.parse_args()
+
+    p1, p2 = socket.socketpair()
+
+    qargs1 = [
+        QEMU_PATH, "-snapshot",
+        "-m", "2G",
+        "-drive", f"file={args.qcow}",
+        "-device", f"{NIC},netdev=n,mac=52:54:00:00:00:01",
+        "-netdev", f"socket,id=n,fd={p1.fileno()}"
+    ]
+    if vnc:
+        qargs1 += ["-display", "vnc=:2"]
+
+    print("+", shlex.join(qargs1))
+    proc1 = subprocess.Popen(qargs1, pass_fds=[p1.fileno()])
+
+    qargs2 = [
+        QEMU_PATH, "-snapshot",
+        "-m", "2G",
+        "-drive", f"file={args.qcow}",
+        "-device", f"{NIC},netdev=n,mac=52:54:00:00:00:02",
+        "-netdev", f"socket,id=n,fd={p2.fileno()}"
+    ]
+    if vnc:
+        qargs2 += ["-display", "vnc=:3"]
+
+    print("+", shlex.join(qargs2))
+    proc2 = subprocess.Popen(qargs2, pass_fds=[p2.fileno()])
+
+    proc1.wait()
+    proc2.wait()
+```
diff --git a/results/classifier/118/device/2370 b/results/classifier/118/device/2370
new file mode 100644
index 00000000..93bbd2dd
--- /dev/null
+++ b/results/classifier/118/device/2370
@@ -0,0 +1,41 @@
+device: 0.876
+virtual: 0.871
+network: 0.832
+graphic: 0.654
+register: 0.640
+files: 0.581
+socket: 0.576
+PID: 0.571
+vnc: 0.561
+user-level: 0.544
+risc-v: 0.533
+boot: 0.473
+semantic: 0.464
+mistranslation: 0.458
+VMM: 0.442
+ppc: 0.426
+debug: 0.426
+arm: 0.417
+permissions: 0.357
+performance: 0.347
+architecture: 0.324
+peripherals: 0.323
+TCG: 0.280
+kernel: 0.266
+hypervisor: 0.142
+assembly: 0.045
+x86: 0.036
+KVM: 0.028
+i386: 0.023
+
+[RFE] vde support on Windows
+Additional information:
+A vdeswitch approach can be yet another solution for #2364 .   
+On Windows, other methods to simultaneously bridge local qemu-VMs and allow bridge members to connect to the internet are troublesome. 
+Compared to MAC/Linux wherein who use kernel provided bridging. Windows users don't have it easy.  
+
+**Ref**: 
+1. qemu manual for ```netdev vde```  
+   https://qemu.readthedocs.io/_/downloads/en/v8.2.1/pdf/#page=75 
+2. virtualsquare/VDE-2 github bug Can't understand how to get it running on Windows10 64 bit ```#28```  
+   https://github.com/virtualsquare/vde-2/issues/28
diff --git a/results/classifier/118/device/240 b/results/classifier/118/device/240
new file mode 100644
index 00000000..6d44ad4a
--- /dev/null
+++ b/results/classifier/118/device/240
@@ -0,0 +1,31 @@
+device: 0.885
+performance: 0.783
+network: 0.744
+architecture: 0.735
+peripherals: 0.682
+socket: 0.589
+arm: 0.580
+kernel: 0.472
+boot: 0.469
+debug: 0.450
+files: 0.437
+PID: 0.428
+permissions: 0.425
+vnc: 0.415
+VMM: 0.388
+hypervisor: 0.346
+graphic: 0.320
+TCG: 0.318
+register: 0.308
+semantic: 0.298
+ppc: 0.261
+x86: 0.245
+virtual: 0.225
+i386: 0.213
+risc-v: 0.160
+mistranslation: 0.141
+assembly: 0.098
+user-level: 0.095
+KVM: 0.026
+
+qemu-3.1.0-rc0: mips emulation hangs when executing invalid instructions
diff --git a/results/classifier/118/device/2406 b/results/classifier/118/device/2406
new file mode 100644
index 00000000..01cf1b44
--- /dev/null
+++ b/results/classifier/118/device/2406
@@ -0,0 +1,37 @@
+device: 0.804
+graphic: 0.792
+performance: 0.709
+peripherals: 0.653
+mistranslation: 0.629
+boot: 0.562
+architecture: 0.538
+semantic: 0.502
+risc-v: 0.461
+kernel: 0.435
+network: 0.430
+socket: 0.429
+i386: 0.399
+permissions: 0.383
+PID: 0.375
+debug: 0.360
+vnc: 0.327
+arm: 0.325
+x86: 0.286
+register: 0.267
+VMM: 0.249
+files: 0.227
+TCG: 0.204
+user-level: 0.176
+hypervisor: 0.173
+virtual: 0.161
+ppc: 0.145
+KVM: 0.134
+assembly: 0.095
+
+SDL UI on KMSDRM Frontend flips qemu-consoles
+Description of problem:
+If I launch qemu on the kms/drm console (without X11 or Wayland), the screen flips automatically between all qemu-consoles. The first (500?) milliseconds, there is the maschine output (boot messages), than the next (200?) milliseconds there is the monitor0 console, the next milliseconds, the serial0 console, and than the parallel0 console. And again from beginning (maschine, monitor0, serial0, parallel0, ... maschine, monitor0, serial0, parallel0, ...) - I dont press any key.
+
+If I disable monitor0, serial0, parallel0, all is fine, except one thing: I cannot issue a command on monitor0, because its disabled ;).
+Steps to reproduce:
+1. Start qemu without X11 and without wayland on the KMSDRM console.
diff --git a/results/classifier/118/device/2416 b/results/classifier/118/device/2416
new file mode 100644
index 00000000..392c78a8
--- /dev/null
+++ b/results/classifier/118/device/2416
@@ -0,0 +1,69 @@
+device: 0.875
+x86: 0.861
+kernel: 0.611
+graphic: 0.586
+PID: 0.539
+ppc: 0.523
+debug: 0.473
+socket: 0.438
+performance: 0.408
+permissions: 0.388
+vnc: 0.383
+peripherals: 0.371
+network: 0.358
+register: 0.336
+hypervisor: 0.326
+files: 0.321
+arm: 0.316
+risc-v: 0.298
+semantic: 0.293
+i386: 0.283
+architecture: 0.281
+virtual: 0.235
+boot: 0.179
+assembly: 0.165
+user-level: 0.142
+VMM: 0.141
+mistranslation: 0.138
+TCG: 0.131
+KVM: 0.108
+
+Assertion failure in virtio_snd_get_qemu_format()
+Description of problem:
+The following log reveals it:
+
+```
+ERROR:hw/audio/virtio-snd.c:356:virtio_snd_get_qemu_format: code should not be reached
+Bail out! ERROR:hw/audio/virtio-snd.c:356:virtio_snd_get_qemu_format: code should not be reached
+Aborted
+```
+Steps to reproduce:
+```
+cat << EOF | qemu-system-x86_64 -display none \
+-machine accel=qtest, -m 512M -machine q35 -device \
+virtio-sound,audiodev=my_audiodev,streams=2 -audiodev \
+alsa,id=my_audiodev -qtest stdio
+outl 0xcf8 0x80001804
+outw 0xcfc 0x06
+outl 0xcf8 0x80001820
+outl 0xcfc 0xe0008000
+write 0xe0008020 0x4 0x00001000
+write 0xe0008028 0x4 0x00101000
+write 0xe000801c 0x1 0x01
+write 0x10c000 0x1 0x01
+write 0x10c001 0x1 0x01
+write 0x10c014 0x1 0x01
+write 0x10c015 0x1 0x51
+write 0x100001 0x1 0xc0
+write 0x100002 0x1 0x10
+write 0x100008 0x1 0x18
+write 0x10f000 0x1 0x02
+write 0x10f001 0x1 0x01
+write 0x100021 0x1 0xf0
+write 0x100022 0x1 0x10
+write 0x100028 0x1 0x08
+write 0x101006 0x1 0x02
+write 0x101002 0x1 0x02
+write 0xe000b001 0x1 0x00
+EOF
+```
diff --git a/results/classifier/118/device/243 b/results/classifier/118/device/243
new file mode 100644
index 00000000..df2a3cc2
--- /dev/null
+++ b/results/classifier/118/device/243
@@ -0,0 +1,31 @@
+device: 0.890
+kernel: 0.808
+architecture: 0.775
+performance: 0.731
+graphic: 0.503
+network: 0.490
+mistranslation: 0.468
+permissions: 0.436
+semantic: 0.395
+boot: 0.352
+virtual: 0.265
+arm: 0.261
+hypervisor: 0.248
+peripherals: 0.222
+debug: 0.216
+user-level: 0.205
+register: 0.190
+vnc: 0.190
+ppc: 0.159
+socket: 0.154
+risc-v: 0.142
+VMM: 0.137
+files: 0.130
+PID: 0.115
+assembly: 0.108
+x86: 0.074
+TCG: 0.044
+KVM: 0.043
+i386: 0.042
+
+Qemu refuses to multiboot Elf64 kernels
diff --git a/results/classifier/118/device/2438 b/results/classifier/118/device/2438
new file mode 100644
index 00000000..099b54b8
--- /dev/null
+++ b/results/classifier/118/device/2438
@@ -0,0 +1,31 @@
+architecture: 0.936
+device: 0.931
+performance: 0.785
+assembly: 0.772
+network: 0.700
+boot: 0.438
+permissions: 0.426
+arm: 0.401
+debug: 0.398
+graphic: 0.390
+register: 0.332
+risc-v: 0.269
+semantic: 0.239
+files: 0.234
+hypervisor: 0.225
+vnc: 0.212
+ppc: 0.187
+mistranslation: 0.162
+kernel: 0.157
+socket: 0.139
+i386: 0.130
+TCG: 0.124
+x86: 0.111
+VMM: 0.067
+virtual: 0.064
+peripherals: 0.051
+PID: 0.042
+user-level: 0.036
+KVM: 0.002
+
+QEMU needs compat tweak to build against upstream capstone 6
diff --git a/results/classifier/118/device/2443 b/results/classifier/118/device/2443
new file mode 100644
index 00000000..f09dc26a
--- /dev/null
+++ b/results/classifier/118/device/2443
@@ -0,0 +1,48 @@
+device: 0.987
+peripherals: 0.940
+PID: 0.715
+network: 0.667
+x86: 0.640
+mistranslation: 0.630
+architecture: 0.589
+graphic: 0.581
+vnc: 0.558
+ppc: 0.537
+socket: 0.507
+arm: 0.488
+VMM: 0.485
+register: 0.477
+permissions: 0.474
+debug: 0.472
+performance: 0.471
+semantic: 0.469
+virtual: 0.462
+files: 0.410
+TCG: 0.399
+hypervisor: 0.392
+risc-v: 0.392
+i386: 0.391
+user-level: 0.371
+boot: 0.345
+kernel: 0.321
+assembly: 0.232
+KVM: 0.125
+
+virtio-gpu-gl: "opengl is not available" message is too vague and doesn't suggest how to fix the problem
+Description of problem:
+I finally compiled qemu for Apple Silicon M2 Pro with opengl enabled and virtglrenderer enabled thanks to instruction from homebrew formula,
+but I did it without homebrew nor macports just manually compiling necessary libraries.
+Qemu was compiled succesfully with flags:
+````
+./configure --target-list=aarch64-softmmu,x86_64-softmmu --enable-cocoa  --enable-sdl --enable-virglrenderer --enable-vhost-net   --enable-spice-protocol --enable-tools --enable-opengl --enable-pixman --enable-vmnet
+````
+
+the device is clearly listed:
+````
+name "virtio-gpu-device", bus virtio-bus
+name "virtio-gpu-gl-device", bus virtio-bus
+name "virtio-gpu-gl-pci", bus PCI, alias "virtio-gpu-gl"
+name "virtio-gpu-pci", bus PCI, alias "virtio-gpu"
+````
+
+So why it not working and gives that info while opengl is clearly there and is enabled.
diff --git a/results/classifier/118/device/2454 b/results/classifier/118/device/2454
new file mode 100644
index 00000000..99dca224
--- /dev/null
+++ b/results/classifier/118/device/2454
@@ -0,0 +1,38 @@
+device: 0.935
+graphic: 0.904
+kernel: 0.806
+ppc: 0.794
+PID: 0.724
+socket: 0.690
+semantic: 0.685
+hypervisor: 0.671
+performance: 0.662
+debug: 0.628
+KVM: 0.621
+network: 0.490
+architecture: 0.421
+files: 0.393
+TCG: 0.371
+assembly: 0.356
+x86: 0.335
+VMM: 0.308
+i386: 0.291
+arm: 0.264
+user-level: 0.264
+vnc: 0.261
+register: 0.201
+boot: 0.183
+risc-v: 0.164
+mistranslation: 0.144
+virtual: 0.140
+peripherals: 0.084
+permissions: 0.016
+
+sd: assertion in sd_read_byte()
+Description of problem:
+The following log reveals it:
+
+```
+ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached
+Bail out! ERROR: qemu/hw/sd/sd.c:2541:sd_read_byte: code should not be reached Aborted (core dumped)
+```
diff --git a/results/classifier/118/device/2465 b/results/classifier/118/device/2465
new file mode 100644
index 00000000..d6764147
--- /dev/null
+++ b/results/classifier/118/device/2465
@@ -0,0 +1,31 @@
+device: 0.822
+performance: 0.766
+network: 0.682
+peripherals: 0.504
+architecture: 0.495
+permissions: 0.495
+arm: 0.491
+PID: 0.375
+risc-v: 0.374
+kernel: 0.374
+semantic: 0.368
+i386: 0.332
+debug: 0.308
+vnc: 0.285
+socket: 0.284
+hypervisor: 0.282
+boot: 0.275
+ppc: 0.262
+files: 0.257
+graphic: 0.256
+x86: 0.248
+VMM: 0.239
+register: 0.231
+virtual: 0.225
+TCG: 0.217
+user-level: 0.166
+mistranslation: 0.162
+assembly: 0.124
+KVM: 0.024
+
+QEMU does not stop other threads when hitting a breakpoint
diff --git a/results/classifier/118/device/2468 b/results/classifier/118/device/2468
new file mode 100644
index 00000000..ba30f68a
--- /dev/null
+++ b/results/classifier/118/device/2468
@@ -0,0 +1,63 @@
+device: 0.929
+peripherals: 0.910
+architecture: 0.865
+VMM: 0.863
+register: 0.858
+debug: 0.836
+graphic: 0.774
+kernel: 0.758
+user-level: 0.736
+assembly: 0.717
+vnc: 0.693
+boot: 0.674
+socket: 0.671
+ppc: 0.662
+performance: 0.654
+x86: 0.636
+network: 0.606
+risc-v: 0.541
+files: 0.504
+semantic: 0.490
+TCG: 0.456
+arm: 0.434
+PID: 0.407
+mistranslation: 0.400
+i386: 0.390
+permissions: 0.383
+virtual: 0.371
+hypervisor: 0.328
+KVM: 0.236
+
+m68k: movec to/from CAAR not emulated?
+Description of problem:
+
+Steps to reproduce:
+1. Start adding a machine for the Motorola MVME147 VME module
+2. Step through the standard ROM for this board (147BUG)
+3. Step until `ff823bf0 4e 7b 18 02     movec      D1,CAAR`
+4. Watch QEMU show a fatal error for an unimplemented control register:
+
+```
+QEMU 9.0.50 monitor - type 'help' for more information
+(qemu) qemu: fatal: Unimplemented control register write 0x802 = 0xffffffff
+
+D0 = ffffffff   A0 = fffe0000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = ffffffff   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = ffff271f   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = ffffffff   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = ffffffff   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = ffffffff   A5 = 00000400   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = ffffffff   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = ffffffff   A7 = 000037dc   F7 = 7fff ffffffffffffffff  (         nan)
+PC = ff823bf0   SR = 2714 T:0 I:7 SI X-Z--
+FPSR = 00000000 ---- 
+                                FPCR =     0000 X RN 
+  A7(MSP) = 00000000   A7(USP) = ffffffff ->A7(ISP) = 000037dc
+VBR = 0xffffffff
+SFC = 0 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+```
+Additional information:
+
diff --git a/results/classifier/118/device/2471 b/results/classifier/118/device/2471
new file mode 100644
index 00000000..c17e5c3e
--- /dev/null
+++ b/results/classifier/118/device/2471
@@ -0,0 +1,31 @@
+device: 0.854
+network: 0.701
+debug: 0.537
+graphic: 0.446
+ppc: 0.420
+performance: 0.360
+arm: 0.332
+mistranslation: 0.320
+kernel: 0.286
+boot: 0.232
+architecture: 0.231
+vnc: 0.199
+assembly: 0.196
+socket: 0.192
+semantic: 0.181
+permissions: 0.179
+i386: 0.163
+hypervisor: 0.156
+TCG: 0.150
+VMM: 0.142
+PID: 0.129
+risc-v: 0.129
+x86: 0.098
+peripherals: 0.072
+virtual: 0.065
+user-level: 0.062
+KVM: 0.060
+files: 0.055
+register: 0.042
+
+error handling in of_dpa_cmd_add_acl()
diff --git a/results/classifier/118/device/2475 b/results/classifier/118/device/2475
new file mode 100644
index 00000000..30853b3c
--- /dev/null
+++ b/results/classifier/118/device/2475
@@ -0,0 +1,31 @@
+device: 0.828
+mistranslation: 0.756
+performance: 0.660
+network: 0.619
+register: 0.523
+debug: 0.519
+kernel: 0.512
+arm: 0.462
+graphic: 0.439
+architecture: 0.400
+boot: 0.368
+semantic: 0.349
+hypervisor: 0.345
+VMM: 0.295
+TCG: 0.276
+i386: 0.227
+ppc: 0.223
+vnc: 0.197
+virtual: 0.183
+x86: 0.152
+KVM: 0.148
+socket: 0.137
+assembly: 0.135
+risc-v: 0.110
+peripherals: 0.082
+user-level: 0.061
+PID: 0.031
+files: 0.029
+permissions: 0.019
+
+Inconsistency between cpu_tb_exec() and qemu_plugin_register_vcpu_tb_exec_cb()?
diff --git a/results/classifier/118/device/2477 b/results/classifier/118/device/2477
new file mode 100644
index 00000000..647ac0da
--- /dev/null
+++ b/results/classifier/118/device/2477
@@ -0,0 +1,31 @@
+device: 0.813
+mistranslation: 0.806
+network: 0.619
+performance: 0.533
+debug: 0.512
+graphic: 0.500
+arm: 0.454
+semantic: 0.449
+virtual: 0.336
+boot: 0.317
+architecture: 0.297
+i386: 0.263
+ppc: 0.245
+hypervisor: 0.241
+socket: 0.233
+peripherals: 0.233
+user-level: 0.215
+x86: 0.211
+register: 0.195
+files: 0.183
+risc-v: 0.151
+permissions: 0.133
+kernel: 0.128
+vnc: 0.109
+assembly: 0.091
+VMM: 0.059
+TCG: 0.054
+PID: 0.041
+KVM: 0.015
+
+GDB_HAS_MTE detection is incomplete
diff --git a/results/classifier/118/device/248 b/results/classifier/118/device/248
new file mode 100644
index 00000000..5797623d
--- /dev/null
+++ b/results/classifier/118/device/248
@@ -0,0 +1,31 @@
+device: 0.937
+network: 0.910
+performance: 0.837
+VMM: 0.777
+graphic: 0.757
+architecture: 0.735
+hypervisor: 0.594
+arm: 0.588
+vnc: 0.584
+risc-v: 0.515
+TCG: 0.486
+PID: 0.469
+mistranslation: 0.428
+semantic: 0.351
+debug: 0.343
+x86: 0.299
+socket: 0.285
+permissions: 0.285
+user-level: 0.276
+peripherals: 0.272
+virtual: 0.271
+i386: 0.261
+KVM: 0.239
+boot: 0.216
+files: 0.209
+ppc: 0.151
+register: 0.125
+kernel: 0.067
+assembly: 0.034
+
+Reconnect failed with loopback virtio1.1 server mode test
diff --git a/results/classifier/118/device/2480 b/results/classifier/118/device/2480
new file mode 100644
index 00000000..e467ebec
--- /dev/null
+++ b/results/classifier/118/device/2480
@@ -0,0 +1,59 @@
+device: 0.880
+kernel: 0.654
+performance: 0.600
+graphic: 0.583
+PID: 0.545
+ppc: 0.500
+VMM: 0.482
+risc-v: 0.474
+mistranslation: 0.445
+socket: 0.444
+register: 0.444
+i386: 0.432
+x86: 0.415
+boot: 0.415
+files: 0.411
+architecture: 0.408
+network: 0.405
+TCG: 0.395
+vnc: 0.383
+debug: 0.378
+arm: 0.363
+peripherals: 0.343
+permissions: 0.288
+semantic: 0.278
+user-level: 0.236
+hypervisor: 0.214
+assembly: 0.182
+virtual: 0.153
+KVM: 0.137
+
+Two questions about VFIO device live migration
+Description of problem:
+For my own pcie device, i implement system memory && device memory dirty bitmap track and works well
+
+use pre-copy mode live migration by the way.
+
+first question:
+- for system memory dirty bitmap sync, notice that last sync will come early than i expected
+  read qemu code and found qemu will call every savevm_state.handlers->save_live_complete_precopy callback 
+  in "qemu_savevm_state_complete_precopy_iterable", and "vfio" handler will always behind "ram".
+  so here is question, my own vfio device will only be halted after "vfio" handler enter 
+  save_live_complete_precopy, and last system memory dirty bitmap sync will come with "ram"'s 
+  save_live_complete_precopy, there will be some system dirty between this period, should we add one more 
+  system dirty bitmap sync after "vfio"'s save_live_complete_precopy
+
+second question:
+- notice that qemu will clean up migration and call every savevm_state.handlers->save_cleanup call back, and   
+  in this function, qemu will only call vfio listener's log_global_stop call back when vm_is_running 
+  but for my vfio device, state will be paused(postmigrate) when enter here, so there is no chance for qemu 
+  to relese some resource create by my device kernel mode driver, where should i put the logic about "stop 
+  migration resource" anyway
+
+Thanks ^_^
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/118/device/2508 b/results/classifier/118/device/2508
new file mode 100644
index 00000000..5dd6fbbe
--- /dev/null
+++ b/results/classifier/118/device/2508
@@ -0,0 +1,31 @@
+device: 0.876
+performance: 0.852
+network: 0.588
+architecture: 0.585
+arm: 0.463
+boot: 0.369
+permissions: 0.344
+risc-v: 0.330
+semantic: 0.330
+hypervisor: 0.313
+user-level: 0.310
+graphic: 0.295
+vnc: 0.286
+mistranslation: 0.278
+peripherals: 0.246
+ppc: 0.224
+register: 0.220
+files: 0.166
+virtual: 0.156
+PID: 0.092
+socket: 0.074
+assembly: 0.071
+debug: 0.064
+kernel: 0.060
+x86: 0.031
+TCG: 0.025
+VMM: 0.018
+i386: 0.016
+KVM: 0.004
+
+test-aio unreliable on MSYS2
diff --git a/results/classifier/118/device/251 b/results/classifier/118/device/251
new file mode 100644
index 00000000..d75107e0
--- /dev/null
+++ b/results/classifier/118/device/251
@@ -0,0 +1,31 @@
+device: 0.927
+performance: 0.866
+graphic: 0.682
+semantic: 0.409
+architecture: 0.304
+arm: 0.254
+peripherals: 0.207
+virtual: 0.162
+mistranslation: 0.162
+register: 0.132
+debug: 0.127
+user-level: 0.126
+socket: 0.112
+vnc: 0.086
+boot: 0.081
+risc-v: 0.079
+files: 0.077
+permissions: 0.073
+assembly: 0.070
+PID: 0.069
+VMM: 0.054
+network: 0.039
+ppc: 0.038
+i386: 0.018
+kernel: 0.009
+hypervisor: 0.005
+x86: 0.003
+KVM: 0.001
+TCG: 0.001
+
+Qemu DOS Quake - 640x480 and above resolutions - Unable to load VESA palette in dos prompt and game crashing are not working
diff --git a/results/classifier/118/device/2516 b/results/classifier/118/device/2516
new file mode 100644
index 00000000..65f9f48a
--- /dev/null
+++ b/results/classifier/118/device/2516
@@ -0,0 +1,31 @@
+device: 0.891
+architecture: 0.729
+network: 0.684
+hypervisor: 0.617
+graphic: 0.612
+virtual: 0.563
+permissions: 0.531
+files: 0.510
+PID: 0.478
+performance: 0.477
+semantic: 0.471
+arm: 0.462
+register: 0.462
+user-level: 0.412
+ppc: 0.395
+debug: 0.384
+socket: 0.374
+peripherals: 0.341
+vnc: 0.322
+boot: 0.318
+mistranslation: 0.311
+assembly: 0.295
+risc-v: 0.275
+kernel: 0.260
+x86: 0.241
+TCG: 0.227
+i386: 0.205
+VMM: 0.197
+KVM: 0.019
+
+Qemu 9.1 dropped support for Ubuntu 20.04
diff --git a/results/classifier/118/device/2533 b/results/classifier/118/device/2533
new file mode 100644
index 00000000..42bcb1ef
--- /dev/null
+++ b/results/classifier/118/device/2533
@@ -0,0 +1,31 @@
+device: 0.886
+performance: 0.776
+graphic: 0.640
+debug: 0.435
+arm: 0.360
+user-level: 0.227
+semantic: 0.178
+mistranslation: 0.153
+boot: 0.142
+ppc: 0.130
+virtual: 0.125
+permissions: 0.102
+register: 0.091
+assembly: 0.074
+socket: 0.052
+peripherals: 0.047
+PID: 0.045
+network: 0.042
+TCG: 0.021
+VMM: 0.017
+files: 0.016
+hypervisor: 0.013
+vnc: 0.012
+risc-v: 0.012
+i386: 0.006
+architecture: 0.004
+kernel: 0.003
+x86: 0.003
+KVM: 0.002
+
+Black screen while I'm trying to emulate Android using "-machine raspi4b"
diff --git a/results/classifier/118/device/2535 b/results/classifier/118/device/2535
new file mode 100644
index 00000000..11a174a8
--- /dev/null
+++ b/results/classifier/118/device/2535
@@ -0,0 +1,31 @@
+device: 0.820
+network: 0.717
+kernel: 0.624
+socket: 0.497
+KVM: 0.407
+x86: 0.376
+VMM: 0.355
+register: 0.351
+architecture: 0.350
+vnc: 0.339
+boot: 0.326
+ppc: 0.322
+arm: 0.320
+hypervisor: 0.314
+PID: 0.308
+i386: 0.230
+risc-v: 0.223
+peripherals: 0.220
+TCG: 0.220
+files: 0.208
+semantic: 0.191
+user-level: 0.181
+graphic: 0.148
+mistranslation: 0.141
+virtual: 0.138
+debug: 0.126
+assembly: 0.113
+permissions: 0.043
+performance: 0.008
+
+Security patch of CVE-2024-4693 backport request
diff --git a/results/classifier/118/device/2539 b/results/classifier/118/device/2539
new file mode 100644
index 00000000..bfba1095
--- /dev/null
+++ b/results/classifier/118/device/2539
@@ -0,0 +1,31 @@
+device: 0.895
+performance: 0.854
+graphic: 0.725
+debug: 0.621
+arm: 0.584
+architecture: 0.562
+network: 0.558
+ppc: 0.463
+risc-v: 0.446
+socket: 0.434
+PID: 0.403
+files: 0.391
+boot: 0.385
+TCG: 0.348
+user-level: 0.299
+register: 0.230
+VMM: 0.223
+semantic: 0.210
+vnc: 0.208
+permissions: 0.158
+peripherals: 0.146
+kernel: 0.142
+assembly: 0.118
+hypervisor: 0.104
+virtual: 0.078
+mistranslation: 0.075
+KVM: 0.056
+i386: 0.037
+x86: 0.028
+
+Crash in early_gtk_display_init() on macOS 14.6.1
diff --git a/results/classifier/118/device/254 b/results/classifier/118/device/254
new file mode 100644
index 00000000..76f09c63
--- /dev/null
+++ b/results/classifier/118/device/254
@@ -0,0 +1,31 @@
+device: 0.864
+performance: 0.693
+ppc: 0.448
+graphic: 0.379
+virtual: 0.346
+risc-v: 0.327
+architecture: 0.240
+arm: 0.229
+boot: 0.229
+vnc: 0.220
+semantic: 0.201
+debug: 0.198
+PID: 0.181
+peripherals: 0.174
+user-level: 0.168
+VMM: 0.164
+register: 0.152
+mistranslation: 0.151
+TCG: 0.110
+socket: 0.049
+permissions: 0.044
+assembly: 0.023
+files: 0.012
+network: 0.009
+KVM: 0.008
+hypervisor: 0.003
+kernel: 0.002
+i386: 0.001
+x86: 0.001
+
+Windows 98 videocard passthrough - unable to load higher resolution -Desktop, after some games crashes, without whole physical machine reset..
diff --git a/results/classifier/118/device/2544 b/results/classifier/118/device/2544
new file mode 100644
index 00000000..4e429f91
--- /dev/null
+++ b/results/classifier/118/device/2544
@@ -0,0 +1,31 @@
+device: 0.864
+performance: 0.492
+arm: 0.442
+PID: 0.428
+debug: 0.367
+register: 0.348
+boot: 0.336
+graphic: 0.272
+risc-v: 0.226
+ppc: 0.219
+network: 0.195
+i386: 0.185
+TCG: 0.176
+vnc: 0.167
+architecture: 0.141
+semantic: 0.126
+virtual: 0.124
+VMM: 0.103
+permissions: 0.101
+x86: 0.099
+files: 0.090
+socket: 0.074
+mistranslation: 0.072
+user-level: 0.067
+hypervisor: 0.052
+peripherals: 0.037
+assembly: 0.031
+kernel: 0.002
+KVM: 0.001
+
+Bug: qemu not properly flushing error messages related to bad arguments
diff --git a/results/classifier/118/device/2547 b/results/classifier/118/device/2547
new file mode 100644
index 00000000..99d9a87a
--- /dev/null
+++ b/results/classifier/118/device/2547
@@ -0,0 +1,33 @@
+device: 0.860
+network: 0.854
+graphic: 0.849
+arm: 0.807
+mistranslation: 0.778
+semantic: 0.775
+architecture: 0.761
+socket: 0.684
+assembly: 0.646
+ppc: 0.531
+register: 0.492
+vnc: 0.453
+peripherals: 0.452
+performance: 0.451
+boot: 0.401
+risc-v: 0.371
+PID: 0.361
+debug: 0.236
+permissions: 0.235
+VMM: 0.226
+TCG: 0.182
+files: 0.182
+KVM: 0.143
+virtual: 0.137
+kernel: 0.102
+user-level: 0.092
+hypervisor: 0.054
+x86: 0.016
+i386: 0.014
+
+Raspberry 4B Ethernet support
+Additional information:
+There is available WIP patch https://patchew.org/QEMU/20240226000259.2752893-1-sergey.kambalin@auriga.com/
diff --git a/results/classifier/118/device/259 b/results/classifier/118/device/259
new file mode 100644
index 00000000..ac1a4804
--- /dev/null
+++ b/results/classifier/118/device/259
@@ -0,0 +1,31 @@
+device: 0.913
+performance: 0.784
+kernel: 0.604
+graphic: 0.543
+debug: 0.498
+i386: 0.358
+arm: 0.353
+socket: 0.299
+x86: 0.276
+boot: 0.222
+ppc: 0.187
+KVM: 0.184
+architecture: 0.168
+assembly: 0.166
+VMM: 0.166
+hypervisor: 0.144
+vnc: 0.131
+mistranslation: 0.124
+register: 0.121
+semantic: 0.080
+TCG: 0.077
+virtual: 0.061
+PID: 0.061
+network: 0.059
+user-level: 0.054
+files: 0.052
+peripherals: 0.028
+risc-v: 0.026
+permissions: 0.016
+
+dma_blk_cb leaks memory map handles on misaligned IO
diff --git a/results/classifier/118/device/261 b/results/classifier/118/device/261
new file mode 100644
index 00000000..963b71d3
--- /dev/null
+++ b/results/classifier/118/device/261
@@ -0,0 +1,31 @@
+device: 0.883
+architecture: 0.743
+network: 0.728
+user-level: 0.638
+arm: 0.626
+graphic: 0.559
+performance: 0.546
+debug: 0.473
+PID: 0.337
+socket: 0.311
+boot: 0.301
+register: 0.219
+risc-v: 0.145
+mistranslation: 0.124
+TCG: 0.117
+peripherals: 0.069
+ppc: 0.067
+semantic: 0.063
+VMM: 0.048
+virtual: 0.047
+vnc: 0.032
+permissions: 0.027
+hypervisor: 0.019
+files: 0.010
+assembly: 0.008
+i386: 0.006
+kernel: 0.004
+KVM: 0.003
+x86: 0.003
+
+broken signal handling in nios2 user-mode emulation
diff --git a/results/classifier/118/device/2615 b/results/classifier/118/device/2615
new file mode 100644
index 00000000..b336da26
--- /dev/null
+++ b/results/classifier/118/device/2615
@@ -0,0 +1,40 @@
+device: 0.903
+performance: 0.871
+ppc: 0.860
+graphic: 0.821
+files: 0.730
+TCG: 0.679
+register: 0.664
+network: 0.663
+risc-v: 0.620
+vnc: 0.618
+semantic: 0.565
+debug: 0.556
+architecture: 0.532
+permissions: 0.471
+i386: 0.449
+socket: 0.435
+peripherals: 0.420
+mistranslation: 0.406
+PID: 0.376
+VMM: 0.355
+user-level: 0.353
+boot: 0.329
+arm: 0.322
+x86: 0.317
+assembly: 0.262
+hypervisor: 0.256
+virtual: 0.238
+kernel: 0.153
+KVM: 0.127
+
+tpm_emulator: the qemu process will be blocked while receiving an unexpected ctrl command's response from the swtpm
+Description of problem:
+When the swtpm sends the unexpected ctrl command's repsonse to the qemu process, the qemu will be blocked. When we use the gdb to attach the qemu process, we will find out that the qemu process is blocked in `recv_msg` function.
+Steps to reproduce:
+1.The QEMU process sends a `CMD_GET_TPMESTABLISHED` control command to the swtpm.
+2.If the swtpm is not currently active (`tpm_running` is false), it responds to the QEMU process with an err_not_running message, which has a fixed size of 4 bytes.
+(Reference: https://github.com/stefanberger/swtpm/blob/master/src/swtpm/ctrlchannel.c#L938)
+3. However, the QEMU process expects to receive a valid response (ptm_est est) of 8 bytes. Consequently, the QEMU process will be blocked in the recv_msg function if the response does not match the expected format.
+Additional information:
+After analysing the source codes in `tpm_emulator.c`, we found that qemu does not process the unexpected ctrol command response from the swtpm correctly (e.g. `CMD_GET_TPMESTABLISHED`). The qemu would be blocked in this function if it received unexpected response from the swtpm (https://gitlab.com/qemu-project/qemu/-/blob/3e9f48bcdabe57f8f90cf19f01bbbf3c86937267/backends/tpm/tpm_emulator.c#L140).
diff --git a/results/classifier/118/device/262 b/results/classifier/118/device/262
new file mode 100644
index 00000000..0dad39c7
--- /dev/null
+++ b/results/classifier/118/device/262
@@ -0,0 +1,31 @@
+device: 0.861
+graphic: 0.733
+performance: 0.645
+debug: 0.632
+arm: 0.478
+mistranslation: 0.363
+network: 0.231
+architecture: 0.156
+semantic: 0.130
+user-level: 0.094
+PID: 0.091
+peripherals: 0.081
+ppc: 0.068
+register: 0.050
+TCG: 0.049
+virtual: 0.046
+risc-v: 0.041
+VMM: 0.039
+assembly: 0.033
+permissions: 0.032
+files: 0.029
+boot: 0.024
+socket: 0.017
+vnc: 0.014
+hypervisor: 0.013
+i386: 0.005
+KVM: 0.004
+x86: 0.003
+kernel: 0.002
+
+Broken scaling with gtk,gl=on on a hidpi display
diff --git a/results/classifier/118/device/2636 b/results/classifier/118/device/2636
new file mode 100644
index 00000000..f7df8f06
--- /dev/null
+++ b/results/classifier/118/device/2636
@@ -0,0 +1,31 @@
+device: 0.955
+performance: 0.891
+arm: 0.734
+architecture: 0.697
+graphic: 0.625
+mistranslation: 0.617
+files: 0.617
+network: 0.599
+boot: 0.594
+semantic: 0.437
+user-level: 0.340
+debug: 0.323
+register: 0.286
+risc-v: 0.286
+hypervisor: 0.213
+permissions: 0.194
+peripherals: 0.170
+VMM: 0.143
+socket: 0.133
+virtual: 0.125
+ppc: 0.119
+PID: 0.119
+vnc: 0.104
+assembly: 0.091
+TCG: 0.074
+x86: 0.066
+kernel: 0.042
+KVM: 0.014
+i386: 0.013
+
+ast2600 fails to run u-boot
diff --git a/results/classifier/118/device/2640 b/results/classifier/118/device/2640
new file mode 100644
index 00000000..35464681
--- /dev/null
+++ b/results/classifier/118/device/2640
@@ -0,0 +1,31 @@
+device: 0.940
+debug: 0.822
+performance: 0.792
+network: 0.752
+peripherals: 0.600
+arm: 0.436
+graphic: 0.424
+architecture: 0.407
+files: 0.300
+boot: 0.288
+register: 0.271
+user-level: 0.240
+permissions: 0.234
+semantic: 0.227
+virtual: 0.177
+PID: 0.154
+mistranslation: 0.123
+ppc: 0.073
+hypervisor: 0.071
+i386: 0.061
+socket: 0.045
+risc-v: 0.042
+assembly: 0.040
+vnc: 0.036
+x86: 0.018
+kernel: 0.010
+VMM: 0.009
+TCG: 0.007
+KVM: 0.003
+
+QEMU twice logging when use SDL.
diff --git a/results/classifier/118/device/2653 b/results/classifier/118/device/2653
new file mode 100644
index 00000000..e908d893
--- /dev/null
+++ b/results/classifier/118/device/2653
@@ -0,0 +1,31 @@
+device: 0.934
+architecture: 0.884
+mistranslation: 0.804
+performance: 0.690
+peripherals: 0.533
+graphic: 0.478
+risc-v: 0.377
+virtual: 0.291
+semantic: 0.288
+permissions: 0.241
+boot: 0.202
+vnc: 0.166
+user-level: 0.140
+debug: 0.131
+PID: 0.074
+assembly: 0.071
+network: 0.062
+register: 0.059
+ppc: 0.054
+arm: 0.036
+files: 0.020
+i386: 0.016
+VMM: 0.015
+hypervisor: 0.011
+x86: 0.007
+TCG: 0.004
+socket: 0.004
+kernel: 0.003
+KVM: 0.001
+
+Intel iGPU sriov
diff --git a/results/classifier/118/device/2654 b/results/classifier/118/device/2654
new file mode 100644
index 00000000..57168c06
--- /dev/null
+++ b/results/classifier/118/device/2654
@@ -0,0 +1,44 @@
+device: 0.931
+network: 0.912
+i386: 0.870
+boot: 0.838
+graphic: 0.816
+PID: 0.748
+register: 0.730
+files: 0.714
+socket: 0.664
+vnc: 0.660
+performance: 0.599
+architecture: 0.541
+semantic: 0.472
+ppc: 0.471
+permissions: 0.441
+debug: 0.437
+TCG: 0.422
+mistranslation: 0.358
+VMM: 0.337
+arm: 0.326
+kernel: 0.228
+risc-v: 0.205
+x86: 0.180
+peripherals: 0.111
+user-level: 0.090
+virtual: 0.070
+assembly: 0.059
+hypervisor: 0.039
+KVM: 0.026
+
+qemu-system-i386 no longer boots NetBSD
+Description of problem:
+Since qemu commit b56617bbcb473c25815d1bf475e326f84563b1de, qemu-system-i386 can no longer boot NetBSD.
+Steps to reproduce:
+```
+wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/images/NetBSD-10.0-i386.iso
+qemu-system-i386 -cdrom NetBSD-10.0-i386.iso
+```
+
+Expected behavior: Boots into the NetBSD installer
+
+Observed incorrect behavior: Boot hangs with a black screen
+Additional information:
+This regression is a critical issue to the NetBSD project as its automated testing infrastructure is heavily dependent on qemu-system-i386.
diff --git a/results/classifier/118/device/2659 b/results/classifier/118/device/2659
new file mode 100644
index 00000000..321d9f4f
--- /dev/null
+++ b/results/classifier/118/device/2659
@@ -0,0 +1,31 @@
+device: 0.816
+performance: 0.759
+network: 0.610
+debug: 0.599
+graphic: 0.552
+architecture: 0.478
+arm: 0.380
+semantic: 0.367
+boot: 0.287
+socket: 0.250
+mistranslation: 0.170
+vnc: 0.169
+register: 0.131
+files: 0.096
+virtual: 0.076
+PID: 0.073
+VMM: 0.069
+TCG: 0.033
+ppc: 0.032
+permissions: 0.023
+user-level: 0.022
+kernel: 0.022
+risc-v: 0.011
+peripherals: 0.010
+hypervisor: 0.006
+x86: 0.004
+assembly: 0.003
+i386: 0.002
+KVM: 0.001
+
+msys2-64bit test-aio intermittent CI failure with "test_timer_schedule: assertion failed: (aio_poll(ctx, true)) FAIL"
diff --git a/results/classifier/118/device/2663 b/results/classifier/118/device/2663
new file mode 100644
index 00000000..f917ee60
--- /dev/null
+++ b/results/classifier/118/device/2663
@@ -0,0 +1,37 @@
+ppc: 0.996
+architecture: 0.991
+device: 0.933
+files: 0.821
+kernel: 0.749
+network: 0.722
+performance: 0.712
+register: 0.686
+arm: 0.677
+graphic: 0.662
+x86: 0.660
+semantic: 0.641
+i386: 0.620
+debug: 0.588
+socket: 0.547
+vnc: 0.544
+risc-v: 0.486
+boot: 0.466
+user-level: 0.361
+permissions: 0.352
+VMM: 0.351
+peripherals: 0.349
+hypervisor: 0.346
+PID: 0.318
+mistranslation: 0.252
+virtual: 0.237
+TCG: 0.186
+assembly: 0.158
+KVM: 0.151
+
+powerpc: for 6xx,7xx,74xx msr and srr1 are not set correctly on exception
+Description of problem:
+When an exception is raised, qemu does not set bits in SRR1 and MSR correctly.
+
+This causes some operating systems to not work, in particular early little endian ones like Windows NT.
+Additional information:
+The following patch changes the MSR and SRR1 bit settings on exception to what is mentioned in the various user manuals for the 6xx, 7xx and 74xx series (6xx and 7xx are effectively identical, 74xx has some additional changes): [exception_msr.patch](/uploads/aae17dd35f0f0e72b831243fcfd0c416/exception_msr.patch)
diff --git a/results/classifier/118/device/2664 b/results/classifier/118/device/2664
new file mode 100644
index 00000000..783e00fe
--- /dev/null
+++ b/results/classifier/118/device/2664
@@ -0,0 +1,39 @@
+device: 0.811
+graphic: 0.651
+architecture: 0.523
+performance: 0.493
+debug: 0.433
+arm: 0.340
+semantic: 0.309
+boot: 0.271
+register: 0.261
+network: 0.213
+vnc: 0.155
+user-level: 0.131
+files: 0.130
+risc-v: 0.130
+assembly: 0.125
+mistranslation: 0.113
+socket: 0.112
+peripherals: 0.099
+PID: 0.086
+ppc: 0.075
+hypervisor: 0.039
+permissions: 0.037
+VMM: 0.036
+kernel: 0.036
+virtual: 0.029
+TCG: 0.009
+x86: 0.003
+i386: 0.002
+KVM: 0.001
+
+Building in Windows MSYS2/Mingw64 fails
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/118/device/2666 b/results/classifier/118/device/2666
new file mode 100644
index 00000000..2c00c2c9
--- /dev/null
+++ b/results/classifier/118/device/2666
@@ -0,0 +1,52 @@
+device: 0.856
+boot: 0.851
+graphic: 0.822
+semantic: 0.712
+mistranslation: 0.631
+architecture: 0.612
+performance: 0.580
+x86: 0.494
+ppc: 0.468
+i386: 0.450
+user-level: 0.447
+socket: 0.407
+vnc: 0.404
+risc-v: 0.396
+files: 0.380
+peripherals: 0.352
+PID: 0.345
+kernel: 0.322
+permissions: 0.289
+hypervisor: 0.268
+register: 0.236
+debug: 0.235
+TCG: 0.233
+arm: 0.217
+VMM: 0.188
+network: 0.158
+virtual: 0.123
+KVM: 0.062
+assembly: 0.059
+
+OPENSTEP 4.2 for Intel does not boot from SCSI cd connected to am53c974
+Description of problem:
+Get OPENSTEP 4.2 installation media from 
+https://fsck.technology/software/NeXT/OpenStep%20Installation%20Media/
+
+Boot qemu like command line above
+
+Follow on-screen instruction, do not forgot to "change floppy0 path_to_driver_disk.img" in qemu monitor
+Additional information:
+![os42-qemu-amd](/uploads/88eddae2f9ec6acd83274a98ab11f2e4/os42-qemu-amd.png)
+
+driver select screen
+
+![os42-qemu-amd-1](/uploads/37d96d04d7f40f6c80aa3f9f6e03f4ff/os42-qemu-amd-1.png)
+
+it boots ..
+
+![os42-qemu-amd-2](/uploads/d3640682a1af90218885ecee31f45ec6/os42-qemu-amd-2.png)
+
+find a bit too much LUNs and eventually give up after scanning them all
+
+Note there is 0-sized disk "detected" in there somewhere
diff --git a/results/classifier/118/device/2679 b/results/classifier/118/device/2679
new file mode 100644
index 00000000..7e8afd84
--- /dev/null
+++ b/results/classifier/118/device/2679
@@ -0,0 +1,31 @@
+device: 0.844
+performance: 0.615
+mistranslation: 0.519
+graphic: 0.423
+architecture: 0.416
+semantic: 0.370
+network: 0.285
+arm: 0.285
+register: 0.216
+hypervisor: 0.207
+risc-v: 0.190
+socket: 0.146
+virtual: 0.133
+peripherals: 0.131
+boot: 0.123
+PID: 0.105
+files: 0.090
+ppc: 0.080
+user-level: 0.071
+permissions: 0.067
+i386: 0.044
+debug: 0.043
+vnc: 0.038
+x86: 0.032
+kernel: 0.032
+TCG: 0.028
+VMM: 0.017
+assembly: 0.006
+KVM: 0.002
+
+TCX emulation missing 1152x900 mode
diff --git a/results/classifier/118/device/2681 b/results/classifier/118/device/2681
new file mode 100644
index 00000000..496880db
--- /dev/null
+++ b/results/classifier/118/device/2681
@@ -0,0 +1,31 @@
+device: 0.804
+performance: 0.688
+network: 0.585
+architecture: 0.583
+register: 0.385
+PID: 0.361
+arm: 0.348
+peripherals: 0.309
+socket: 0.282
+graphic: 0.279
+permissions: 0.274
+kernel: 0.260
+semantic: 0.232
+assembly: 0.227
+debug: 0.226
+files: 0.224
+boot: 0.189
+i386: 0.178
+mistranslation: 0.175
+risc-v: 0.172
+hypervisor: 0.169
+VMM: 0.165
+x86: 0.143
+vnc: 0.131
+ppc: 0.121
+TCG: 0.100
+virtual: 0.097
+user-level: 0.070
+KVM: 0.001
+
+QEMU build system should halt, if glib version is lower than needed
diff --git a/results/classifier/118/device/269 b/results/classifier/118/device/269
new file mode 100644
index 00000000..833658f0
--- /dev/null
+++ b/results/classifier/118/device/269
@@ -0,0 +1,31 @@
+device: 0.868
+architecture: 0.852
+network: 0.830
+performance: 0.761
+peripherals: 0.624
+ppc: 0.620
+hypervisor: 0.568
+permissions: 0.547
+files: 0.546
+graphic: 0.500
+mistranslation: 0.492
+arm: 0.482
+kernel: 0.414
+register: 0.332
+debug: 0.265
+assembly: 0.259
+semantic: 0.247
+socket: 0.245
+vnc: 0.242
+boot: 0.234
+virtual: 0.233
+user-level: 0.225
+x86: 0.133
+risc-v: 0.128
+VMM: 0.126
+TCG: 0.107
+PID: 0.091
+i386: 0.034
+KVM: 0.028
+
+AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu
diff --git a/results/classifier/118/device/2693 b/results/classifier/118/device/2693
new file mode 100644
index 00000000..f9ad477d
--- /dev/null
+++ b/results/classifier/118/device/2693
@@ -0,0 +1,36 @@
+device: 0.846
+graphic: 0.762
+boot: 0.487
+network: 0.480
+VMM: 0.419
+risc-v: 0.349
+debug: 0.332
+files: 0.320
+arm: 0.301
+mistranslation: 0.293
+semantic: 0.270
+register: 0.266
+TCG: 0.249
+vnc: 0.229
+PID: 0.223
+hypervisor: 0.214
+ppc: 0.212
+socket: 0.206
+i386: 0.189
+user-level: 0.160
+x86: 0.158
+kernel: 0.110
+KVM: 0.107
+virtual: 0.076
+performance: 0.073
+peripherals: 0.062
+architecture: 0.061
+assembly: 0.044
+permissions: 0.010
+
+hv-balloon Migration
+Description of problem:
+since QEMU version 8.2, the hv-balloon feature has been officially merged, but migration is still not supported.
+Are there any planned enhancements to the hv-balloon migration in the near future?
+Steps to reproduce:
+
diff --git a/results/classifier/118/device/2695 b/results/classifier/118/device/2695
new file mode 100644
index 00000000..78975b77
--- /dev/null
+++ b/results/classifier/118/device/2695
@@ -0,0 +1,33 @@
+device: 0.982
+semantic: 0.954
+mistranslation: 0.951
+architecture: 0.943
+graphic: 0.912
+virtual: 0.885
+ppc: 0.704
+socket: 0.677
+debug: 0.639
+network: 0.540
+performance: 0.536
+vnc: 0.533
+assembly: 0.504
+arm: 0.480
+register: 0.471
+boot: 0.433
+VMM: 0.406
+i386: 0.334
+risc-v: 0.331
+peripherals: 0.291
+TCG: 0.263
+x86: 0.258
+permissions: 0.206
+user-level: 0.197
+hypervisor: 0.176
+KVM: 0.167
+PID: 0.144
+files: 0.098
+kernel: 0.091
+
+how to onboard fw_cfg to other machines
+Additional information:
+Would it be doable for other machines actually? I didn't dig deeper into this device to understand, but I guess it is connected to the VM somehow and it has some memory mapped to the OS?
diff --git a/results/classifier/118/device/2696 b/results/classifier/118/device/2696
new file mode 100644
index 00000000..3606e32b
--- /dev/null
+++ b/results/classifier/118/device/2696
@@ -0,0 +1,42 @@
+device: 0.919
+graphic: 0.893
+PID: 0.863
+network: 0.832
+debug: 0.786
+ppc: 0.786
+vnc: 0.783
+files: 0.751
+socket: 0.735
+kernel: 0.734
+mistranslation: 0.701
+boot: 0.690
+performance: 0.671
+semantic: 0.660
+arm: 0.630
+TCG: 0.620
+architecture: 0.512
+VMM: 0.502
+permissions: 0.492
+risc-v: 0.411
+i386: 0.378
+register: 0.364
+x86: 0.337
+user-level: 0.294
+virtual: 0.253
+KVM: 0.229
+hypervisor: 0.218
+peripherals: 0.215
+assembly: 0.174
+
+qemu-hexagon 9.2.0-rc1 hits unreachable assertion in decode_insns() on invalid instruction
+Description of problem:
+```
+❯ cat start.s
+.globl _start
+_start: .word 0
+❯ clang start.s -target hexagon-linux -nostdlib -fuse-ld=lld
+❯ qemu-hexagon ./a.out
+**
+ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached
+Bail out! ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached
+```
diff --git a/results/classifier/118/device/2698 b/results/classifier/118/device/2698
new file mode 100644
index 00000000..8fef5cb5
--- /dev/null
+++ b/results/classifier/118/device/2698
@@ -0,0 +1,39 @@
+TCG: 0.993
+device: 0.929
+virtual: 0.859
+graphic: 0.853
+semantic: 0.529
+debug: 0.519
+performance: 0.498
+arm: 0.441
+vnc: 0.367
+boot: 0.344
+mistranslation: 0.329
+risc-v: 0.325
+user-level: 0.230
+hypervisor: 0.218
+PID: 0.196
+register: 0.160
+network: 0.115
+architecture: 0.099
+files: 0.091
+socket: 0.087
+peripherals: 0.069
+VMM: 0.058
+assembly: 0.057
+permissions: 0.046
+ppc: 0.046
+kernel: 0.023
+KVM: 0.015
+i386: 0.010
+x86: 0.004
+
+virtualization not working with TCG mode on macOS
+Description of problem:
+TCG is supposed to work with virtualization=on option but it stops without priting anything.
+if I set it to off, I can get to the prompt.
+Steps to reproduce:
+1. Execute the qemu
+2. Hung.
+Additional information:
+
diff --git a/results/classifier/118/device/2700 b/results/classifier/118/device/2700
new file mode 100644
index 00000000..ba6c9531
--- /dev/null
+++ b/results/classifier/118/device/2700
@@ -0,0 +1,38 @@
+TCG: 0.945
+device: 0.936
+graphic: 0.912
+boot: 0.903
+semantic: 0.742
+architecture: 0.719
+arm: 0.606
+mistranslation: 0.514
+register: 0.397
+risc-v: 0.390
+debug: 0.361
+vnc: 0.352
+performance: 0.260
+hypervisor: 0.250
+PID: 0.235
+files: 0.198
+kernel: 0.175
+permissions: 0.153
+network: 0.120
+socket: 0.117
+user-level: 0.115
+assembly: 0.114
+peripherals: 0.105
+VMM: 0.065
+ppc: 0.060
+virtual: 0.036
+KVM: 0.008
+x86: 0.005
+i386: 0.001
+
+Windows 11 24H2 (x64) fails to boot
+Description of problem:
+When trying to boot Windows 11 24H2 (including the installer), the guest will just restart.
+Steps to reproduce:
+1. Download Windows 11 ISO from: https://www.microsoft.com/en-us/software-download/windows11
+2. Run the command above
+Additional information:
+I tested it on an M4 Pro Mac running TCG. Other users have reported the same issue with M3 running TCG and Intel i9 running HVF.
diff --git a/results/classifier/118/device/2703 b/results/classifier/118/device/2703
new file mode 100644
index 00000000..4b618f0f
--- /dev/null
+++ b/results/classifier/118/device/2703
@@ -0,0 +1,70 @@
+device: 0.874
+x86: 0.867
+virtual: 0.783
+performance: 0.770
+ppc: 0.732
+files: 0.709
+boot: 0.705
+risc-v: 0.701
+kernel: 0.694
+graphic: 0.682
+socket: 0.672
+register: 0.670
+PID: 0.662
+vnc: 0.624
+network: 0.594
+architecture: 0.574
+hypervisor: 0.571
+peripherals: 0.558
+arm: 0.517
+VMM: 0.476
+semantic: 0.457
+debug: 0.436
+TCG: 0.434
+KVM: 0.401
+i386: 0.389
+permissions: 0.352
+mistranslation: 0.318
+assembly: 0.212
+user-level: 0.125
+
+ptimer period sporadically too long
+Description of problem:
+A ptimer in a custom device with a frequency of 10kHz is sporadically called after more than 100,000ns in virtual time have elapsed.
+
+With a icount shift of 4 or 5 this happens almost everytime before the linux guest can even finish booting.
+
+With a shift of 0 this happens very rarely, but it does occur from time to time.
+Steps to reproduce:
+1. setup a ptimer with a frequency of 10kHz and assert that the time passed between callbacks is exactly 100,000ns
+2. run
+3. wait for boom
+Additional information:
+```
+// Timer setup
+ptimer_transaction_begin(state->timer);
+
+ptimer_set_freq(state->timer, 10000);
+ptimer_run(state->timer, 0);
+   
+ptimer_transaction_commit(state->timer);
+```
+```
+// timer callback
+int64_t now  = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+static int64_t last = 0;
+if (last > 0)
+{
+   if (now - last != 100000)
+   {
+       fprintf(stderr, "error tick %ld after %ld is incorrect: %ld\n", now, last, now - last);
+       assert(0);
+   }
+}
+last = now;
+```
+
+```
+error tick 47867503135 after 47867400000 is incorrect: 103135
+qemu-system-x86_64: ../...file.c:119: timer_callback: Assertion `0' failed.
+```
diff --git a/results/classifier/118/device/2707 b/results/classifier/118/device/2707
new file mode 100644
index 00000000..abfce29a
--- /dev/null
+++ b/results/classifier/118/device/2707
@@ -0,0 +1,40 @@
+device: 0.976
+x86: 0.942
+graphic: 0.901
+peripherals: 0.723
+performance: 0.709
+PID: 0.659
+debug: 0.632
+virtual: 0.584
+network: 0.572
+architecture: 0.505
+vnc: 0.455
+semantic: 0.454
+socket: 0.437
+ppc: 0.393
+i386: 0.313
+arm: 0.308
+risc-v: 0.304
+register: 0.269
+boot: 0.234
+VMM: 0.202
+hypervisor: 0.192
+permissions: 0.181
+TCG: 0.152
+kernel: 0.137
+user-level: 0.124
+files: 0.116
+assembly: 0.062
+mistranslation: 0.061
+KVM: 0.008
+
+virtio-balloon crashes in a object assert when querying stats
+Description of problem:
+Fetch virtio-balloon stats will crash a QEMU crash with assert failures
+Steps to reproduce:
+1. ./qemu-system-x86_64 -device virtio-balloon,id=balloon -qmp qmp.sock
+2. Connect to qmp.sock
+3. Issue  'qom-get path=/machine/peripheral/balloon property=guest-stats'
+4. QEMU go boom!
+Additional information:
+This is a regression caused by commit 0d2eeef77a33315187df8519491a900bde4a3d83, which failed to update `balloon_stat_names` with the new stats names, causing code to try to add a QDict entry with a NULL key.
diff --git a/results/classifier/118/device/2711 b/results/classifier/118/device/2711
new file mode 100644
index 00000000..ef189550
--- /dev/null
+++ b/results/classifier/118/device/2711
@@ -0,0 +1,31 @@
+device: 0.811
+performance: 0.754
+network: 0.264
+semantic: 0.188
+graphic: 0.162
+i386: 0.150
+arm: 0.144
+boot: 0.144
+register: 0.131
+kernel: 0.126
+peripherals: 0.126
+architecture: 0.123
+files: 0.112
+debug: 0.107
+x86: 0.107
+ppc: 0.102
+hypervisor: 0.098
+user-level: 0.096
+mistranslation: 0.091
+socket: 0.073
+risc-v: 0.062
+assembly: 0.059
+permissions: 0.057
+vnc: 0.051
+virtual: 0.049
+PID: 0.022
+TCG: 0.015
+VMM: 0.007
+KVM: 0.005
+
+TSTEQ lowering and optimization bug
diff --git a/results/classifier/118/device/2714 b/results/classifier/118/device/2714
new file mode 100644
index 00000000..2373ee91
--- /dev/null
+++ b/results/classifier/118/device/2714
@@ -0,0 +1,37 @@
+device: 0.838
+graphic: 0.790
+network: 0.765
+ppc: 0.731
+TCG: 0.730
+files: 0.700
+vnc: 0.634
+socket: 0.610
+architecture: 0.575
+register: 0.573
+VMM: 0.556
+PID: 0.547
+risc-v: 0.506
+debug: 0.473
+mistranslation: 0.471
+semantic: 0.431
+boot: 0.425
+permissions: 0.405
+i386: 0.400
+x86: 0.364
+arm: 0.350
+kernel: 0.326
+virtual: 0.312
+performance: 0.223
+user-level: 0.203
+hypervisor: 0.189
+assembly: 0.160
+peripherals: 0.121
+KVM: 0.070
+
+Potential memory leak in virtio-crytpto
+Description of problem:
+There is a potential memory leak while using virtio-crypto with vhost-user backend.
+
+The problem is due to misuse of error_setg in [backends/cryptodev-vhost-user.c#L284](https://gitlab.com/qemu-project/qemu/-/blob/master/backends/cryptodev-vhost-user.c#L284). After invoking error_setg(&local_error, ...), current procedure should not return without freeing err object pointed by local_error.
+
+The same problem occured in cryptodev-builtin, which has been discussed in #2283 and fixed in f6abce29cc4afa0445cb3b29a265a114ac9fa744. The same fixes should be applied to cryptodev-vhost-user.
diff --git a/results/classifier/118/device/2716 b/results/classifier/118/device/2716
new file mode 100644
index 00000000..251eb791
--- /dev/null
+++ b/results/classifier/118/device/2716
@@ -0,0 +1,37 @@
+device: 0.864
+performance: 0.757
+network: 0.742
+vnc: 0.728
+VMM: 0.723
+boot: 0.660
+kernel: 0.592
+register: 0.584
+risc-v: 0.583
+arm: 0.576
+files: 0.567
+graphic: 0.500
+PID: 0.466
+KVM: 0.431
+TCG: 0.355
+debug: 0.336
+socket: 0.256
+assembly: 0.251
+semantic: 0.249
+ppc: 0.247
+architecture: 0.217
+permissions: 0.207
+peripherals: 0.203
+mistranslation: 0.174
+i386: 0.174
+hypervisor: 0.173
+x86: 0.139
+user-level: 0.080
+virtual: 0.040
+
+migrate incoming with fd transfer issue
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+#
diff --git a/results/classifier/118/device/2724 b/results/classifier/118/device/2724
new file mode 100644
index 00000000..de7627cf
--- /dev/null
+++ b/results/classifier/118/device/2724
@@ -0,0 +1,38 @@
+device: 0.935
+graphic: 0.856
+socket: 0.777
+peripherals: 0.695
+debug: 0.670
+kernel: 0.651
+arm: 0.647
+vnc: 0.596
+boot: 0.593
+mistranslation: 0.583
+risc-v: 0.568
+semantic: 0.510
+network: 0.504
+architecture: 0.490
+performance: 0.422
+hypervisor: 0.416
+VMM: 0.377
+i386: 0.342
+PID: 0.290
+KVM: 0.267
+TCG: 0.249
+x86: 0.247
+files: 0.231
+ppc: 0.228
+register: 0.215
+user-level: 0.214
+permissions: 0.154
+virtual: 0.112
+assembly: 0.066
+
+Invalid DRM modifier in ScanoutDMABUF call
+Description of problem:
+`modifier` parameter in `ScanoutDMABUF` callback is always `0xffffffffffffff` (`DRM_FORMAT_RESERVED`)
+Steps to reproduce:
+1. Run QEMU with D-Bus display
+2. Connect D-Bus display client and print modifier
+Additional information:
+
diff --git a/results/classifier/118/device/2726 b/results/classifier/118/device/2726
new file mode 100644
index 00000000..9b1956a3
--- /dev/null
+++ b/results/classifier/118/device/2726
@@ -0,0 +1,31 @@
+device: 0.801
+peripherals: 0.698
+performance: 0.694
+graphic: 0.552
+mistranslation: 0.545
+network: 0.514
+permissions: 0.496
+semantic: 0.450
+architecture: 0.271
+virtual: 0.250
+register: 0.238
+assembly: 0.218
+PID: 0.212
+boot: 0.204
+debug: 0.201
+arm: 0.175
+socket: 0.135
+hypervisor: 0.129
+user-level: 0.127
+VMM: 0.116
+ppc: 0.102
+files: 0.092
+i386: 0.056
+x86: 0.050
+vnc: 0.049
+TCG: 0.042
+risc-v: 0.020
+kernel: 0.020
+KVM: 0.004
+
+please make qemu-img capable of using with pipes
diff --git a/results/classifier/118/device/273 b/results/classifier/118/device/273
new file mode 100644
index 00000000..b613d018
--- /dev/null
+++ b/results/classifier/118/device/273
@@ -0,0 +1,31 @@
+device: 0.808
+performance: 0.793
+arm: 0.714
+debug: 0.616
+network: 0.594
+boot: 0.435
+graphic: 0.407
+socket: 0.401
+mistranslation: 0.390
+risc-v: 0.382
+kernel: 0.358
+TCG: 0.329
+vnc: 0.318
+architecture: 0.301
+semantic: 0.300
+VMM: 0.266
+i386: 0.175
+hypervisor: 0.148
+ppc: 0.131
+files: 0.116
+virtual: 0.103
+PID: 0.083
+assembly: 0.068
+register: 0.063
+user-level: 0.055
+peripherals: 0.044
+x86: 0.028
+KVM: 0.025
+permissions: 0.020
+
+xhci_find_stream: Assertion `streamid != 0' failed.
diff --git a/results/classifier/118/device/2733 b/results/classifier/118/device/2733
new file mode 100644
index 00000000..effc2c30
--- /dev/null
+++ b/results/classifier/118/device/2733
@@ -0,0 +1,42 @@
+device: 0.887
+architecture: 0.777
+graphic: 0.612
+semantic: 0.530
+network: 0.519
+performance: 0.505
+vnc: 0.460
+PID: 0.433
+debug: 0.418
+ppc: 0.335
+boot: 0.333
+register: 0.311
+socket: 0.303
+permissions: 0.301
+virtual: 0.296
+hypervisor: 0.283
+mistranslation: 0.274
+files: 0.196
+i386: 0.188
+x86: 0.178
+TCG: 0.178
+user-level: 0.172
+risc-v: 0.120
+peripherals: 0.113
+VMM: 0.113
+assembly: 0.102
+kernel: 0.034
+arm: 0.022
+KVM: 0.010
+
+-machine raspi4b won't dump dtb
+Description of problem:
+the raspi4b machine won't dump tdb
+Steps to reproduce:
+```
+$ qemu-system-aarch64 -machine virt -machine dumpdtb=p.dmp
+qemu-system-aarch64: info: dtb dumped to p.dmp. Exiting.
+$ qemu-system-aarch64 -machine raspi4b -machine dumpdtb=p.dmp
+```
+notice no dtb is dumped for the raspi4b machine
+Additional information:
+see also https://gitlab.com/qemu-project/qemu/-/issues/2729
diff --git a/results/classifier/118/device/2734 b/results/classifier/118/device/2734
new file mode 100644
index 00000000..aa48ccf1
--- /dev/null
+++ b/results/classifier/118/device/2734
@@ -0,0 +1,54 @@
+device: 0.931
+architecture: 0.872
+graphic: 0.835
+socket: 0.799
+performance: 0.784
+network: 0.780
+semantic: 0.670
+ppc: 0.662
+vnc: 0.619
+register: 0.595
+debug: 0.518
+boot: 0.459
+x86: 0.458
+PID: 0.435
+permissions: 0.402
+kernel: 0.377
+assembly: 0.346
+VMM: 0.324
+mistranslation: 0.316
+arm: 0.297
+TCG: 0.276
+risc-v: 0.272
+peripherals: 0.237
+virtual: 0.204
+user-level: 0.191
+files: 0.185
+hypervisor: 0.180
+i386: 0.175
+KVM: 0.062
+
+many aarch64 machines exit with "fatal: Lockup: can't escalate 3 to HardFault"
+Description of problem:
+`-machine netduino2` and `-machine microbit` and many others dump core
+Steps to reproduce:
+```
+qemu-system-aarch64 -machine netduino2
+qemu-system-aarch64 -machine microbit
+...
+$ for x in microbit netduino2 b-l475e-iot01a emcraft-sf2 fby35-bmc lm3s6965evb lm3s811evb musca-a musca-b1 netduinoplus2 olimex-stm32-h405 stm32vldiscovery
+do qemu-system-aarch64 -machine $x
+done
+```
+and all the `mps2-*` machines all result in 
+```
+qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
+
+R00=00000000 R01=00000000 R02=00000000 R03=00000000
+R04=00000000 R05=00000000 R06=00000000 R07=00000000
+R08=00000000 R09=00000000 R10=00000000 R11=00000000
+R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000
+XPSR=40000003 -Z-- A handler
+FPSCR: 00000000
+Aborted (core dumped)
+```
diff --git a/results/classifier/118/device/2735 b/results/classifier/118/device/2735
new file mode 100644
index 00000000..c870597e
--- /dev/null
+++ b/results/classifier/118/device/2735
@@ -0,0 +1,40 @@
+device: 0.888
+graphic: 0.850
+performance: 0.816
+vnc: 0.766
+architecture: 0.747
+register: 0.699
+network: 0.672
+files: 0.653
+PID: 0.621
+debug: 0.610
+VMM: 0.521
+permissions: 0.494
+boot: 0.479
+socket: 0.470
+semantic: 0.467
+ppc: 0.457
+kernel: 0.451
+TCG: 0.377
+hypervisor: 0.368
+arm: 0.351
+user-level: 0.339
+KVM: 0.339
+x86: 0.337
+peripherals: 0.255
+i386: 0.240
+virtual: 0.196
+assembly: 0.167
+mistranslation: 0.143
+risc-v: 0.126
+
+Couldn't find rom image 'canon-a1100-rom1.bin'.
+Description of problem:
+```
+$ qemu-system-aarch64 -machine canon-a1100
+qemu-system-aarch64: Couldn't find rom image 'canon-a1100-rom1.bin'.
+```
+Steps to reproduce:
+```
+qemu-system-aarch64 -machine canon-a1100
+```
diff --git a/results/classifier/118/device/2743 b/results/classifier/118/device/2743
new file mode 100644
index 00000000..b68d26b3
--- /dev/null
+++ b/results/classifier/118/device/2743
@@ -0,0 +1,33 @@
+device: 0.879
+files: 0.776
+arm: 0.687
+debug: 0.567
+network: 0.559
+graphic: 0.487
+performance: 0.424
+virtual: 0.302
+boot: 0.302
+kernel: 0.289
+architecture: 0.255
+i386: 0.244
+peripherals: 0.233
+hypervisor: 0.231
+semantic: 0.227
+socket: 0.217
+VMM: 0.198
+ppc: 0.191
+register: 0.191
+mistranslation: 0.169
+PID: 0.168
+TCG: 0.140
+x86: 0.130
+user-level: 0.117
+assembly: 0.088
+risc-v: 0.056
+vnc: 0.046
+permissions: 0.029
+KVM: 0.002
+
+The command Qemu-img did not work, cannot convert raw file to vhd file
+Description of problem:
+
diff --git a/results/classifier/118/device/2752 b/results/classifier/118/device/2752
new file mode 100644
index 00000000..36361458
--- /dev/null
+++ b/results/classifier/118/device/2752
@@ -0,0 +1,307 @@
+device: 0.939
+risc-v: 0.924
+debug: 0.919
+graphic: 0.917
+register: 0.914
+socket: 0.903
+assembly: 0.903
+semantic: 0.903
+permissions: 0.901
+PID: 0.898
+arm: 0.894
+architecture: 0.889
+network: 0.889
+performance: 0.888
+boot: 0.883
+kernel: 0.879
+virtual: 0.871
+files: 0.825
+user-level: 0.794
+ppc: 0.793
+hypervisor: 0.775
+x86: 0.773
+vnc: 0.772
+TCG: 0.771
+mistranslation: 0.770
+peripherals: 0.765
+i386: 0.748
+VMM: 0.743
+KVM: 0.717
+
+Heap use after free in virtio-crypto with vhost-user backend
+Description of problem:
+An heap-use-after-free happens in virtio-crypto device with vhost-user backend created by a dpdk example program.
+Steps to reproduce:
+1.Build dpdk vhost-user crypto backend. Following instructions here: [DPDK installation](https://doc.dpdk.org/guides/prog_guide/build-sdk-meson.html)
+```
+wget https://fast.dpdk.org/rel/dpdk-24.11.tar.xz
+meson setup -Dexamples=all build
+cd build
+ninja
+meson install
+cd examples
+sudo ./dpdk-vhost_crypto --vdev  'crypto_aesni_mb0' -- --config \(7,0,0\) --socket-file=7,/tmp/my-crypto.sock
+```
+After setting up the backend, should see something like:
+```
+EAL: Detected CPU lcores: 48
+EAL: Detected NUMA nodes: 2
+EAL: Detected static linkage of DPDK
+EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
+EAL: Selected IOVA mode 'PA'
+EAL: VFIO support initialized
+CRYPTODEV: Creating cryptodev crypto_aesni_mb0
+CRYPTODEV: Initialisation parameters - name: crypto_aesni_mb0,socket id: 0, max queue pairs: 8
+IPSEC_MB: ipsec_mb_create() line 168: IPSec Multi-buffer library version used: 2.0.0
+USER1: Processing on Core 7 started
+VHOST_CONFIG: (/tmp/my-crypto.sock) logging feature is disabled in async copy mode
+VHOST_CONFIG: (/tmp/my-crypto.sock) vhost-user server: socket created, fd: 213
+VHOST_CONFIG: (/tmp/my-crypto.sock) binding succeeded
+```
+
+2.Build qemu with ASAN (i.e., --enable-asan) and vhost support (i.e., --enable-vhost-user --enable-vhost-crypto)
+
+3.Ensure that /dev/hugemaps and /tmp/my-crypto.sock can be accessed. You may need to change their permissions by chmod, or run qemu-system as root.
+
+4.Run the command below to reproduce UAF. Here, Setting ASAN_OPTIONS=max_malloc_fill_size=0 avoids capturing another unintialized read in vhost_user_backend_init, which happens ealier than the UAF. 
+
+I can reproduce it 7 times in 10 runs, seems to be racing.
+```
+cat << EOF | ASAN_OPTIONS=max_malloc_fill_size=0 \
+./qemu-system-x86_64 --enable-kvm -m 512M \
+-object \
+memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on \
+-numa node,memdev=mem -smp cpus=4 -machine q35 -chardev \
+socket,id=chardev0,path=/tmp/my-crypto.sock -object \
+cryptodev-vhost-user,id=cryptodev0,chardev=chardev0 -device \
+virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -display none -qtest \
+stdio
+outl 0xcf8 0x80001800
+inw 0xcfc
+outl 0xcf8 0x80001814
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x80001814
+inl 0xcfc
+outl 0xcf8 0x80001814
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x80001820
+outl 0xcfc 0xffffffff
+outl 0xcf8 0x80001820
+inl 0xcfc
+outl 0xcf8 0x80001820
+outl 0xcfc 0xe0004000
+outl 0xcf8 0x80001804
+inw 0xcfc
+outl 0xcf8 0x80001804
+outw 0xcfc 0x7
+outl 0xcf8 0x80001804
+inw 0xcfc
+writeq 0xe0004023 0x5f5f5f5f5f5f0d00
+writeq 0xe0004015 0x10b2d007a210fff
+writeq 0xe0004011 0xb2616007a006425
+writeq 0xe0004011 0x5a5546a2d40b6425
+EOF
+```
+Additional information:
+Here is the information reported by ASAN: 
+```
+==2277232==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+[I 0.000000] OPENED
+qemu-system-x86_64: warning: vhost-user backend supports VHOST_USER_PROTOCOL_F_CONFIG but QEMU does not.
+[R +0.119439] outl 0xcf8 0x80001800
+[S +0.119564] OK
+OK
+[R +0.119607] inw 0xcfc
+[S +0.119667] OK 0x1af4
+OK 0x1af4
+[R +0.119721] outl 0xcf8 0x80001814
+[S +0.119770] OK
+OK
+[R +0.119817] outl 0xcfc 0xffffffff
+[S +0.119889] OK
+OK
+[R +0.119929] outl 0xcf8 0x80001814
+[S +0.119977] OK
+OK
+[R +0.120037] inl 0xcfc
+[S +0.120090] OK 0xfffff000
+OK 0xfffff000
+[R +0.120140] outl 0xcf8 0x80001814
+[S +0.120165] OK
+OK
+[R +0.120193] outl 0xcfc 0xe0000000
+[S +0.120242] OK
+OK
+[R +0.120303] outl 0xcf8 0x80001820
+[S +0.120324] OK
+OK
+[R +0.120343] outl 0xcfc 0xffffffff
+[S +0.120390] OK
+OK
+[R +0.120431] outl 0xcf8 0x80001820
+[S +0.120487] OK
+OK
+[R +0.120541] inl 0xcfc
+[S +0.120578] OK 0xffffc00c
+OK 0xffffc00c
+[R +0.120635] outl 0xcf8 0x80001820
+[S +0.120680] OK
+OK
+[R +0.120747] outl 0xcfc 0xe0004000
+[S +0.120815] OK
+OK
+[R +0.120858] outl 0xcf8 0x80001804
+[S +0.120881] OK
+OK
+[R +0.120930] inw 0xcfc
+[S +0.120975] OK 0x0000
+OK 0x0000
+[R +0.121017] outl 0xcf8 0x80001804
+[S +0.121053] OK
+OK
+[R +0.121081] outw 0xcfc 0x7
+[S +0.132297] OK
+OK
+[R +0.132330] outl 0xcf8 0x80001804
+[S +0.132345] OK
+OK
+[R +0.132357] inw 0xcfc
+[S +0.132373] OK 0x0007
+OK 0x0007
+[R +0.132392] writeq 0xe0004023 0x5f5f5f5f5f5f0d00
+[S +0.132409] OK
+OK
+[R +0.132419] writeq 0xe0004015 0x10b2d007a210fff
+[S +0.132447] OK
+OK
+[R +0.132460] writeq 0xe0004011 0xb2616007a006425
+[S +0.132480] OK
+OK
+[R +0.132489] writeq 0xe0004011 0x5a5546a2d40b6425
+qemu-system-x86_64: Failed initializing vhost-user memory map, consider using -object memory-backend-file share=on
+qemu-system-x86_64: vhost_set_mem_table failed: Invalid argument (22)
+qemu-system-x86_64: Failed to write msg. Wrote -1 instead of 52.
+qemu-system-x86_64: vhost_set_vring_addr failed: Invalid argument (22)
+=================================================================
+==2277232==ERROR: AddressSanitizer: heap-use-after-free on address 0x618000000b28 at pc 0x5570e3541a1b bp 0x7fff627ef550 sp 0x7fff627ef548
+READ of size 8 at 0x618000000b28 thread T0
+    #0 0x5570e3541a1a in vhost_virtqueue_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1359:33
+    #1 0x5570e3562051 in vhost_dev_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:2041:13
+    #2 0x5570e37c10c1 in cryptodev_vhost_start_one /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:96:9
+    #3 0x5570e37c067f in cryptodev_vhost_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:213:13
+    #4 0x5570e34f06ce in virtio_crypto_vhost_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1189:13
+    #5 0x5570e34ce991 in virtio_crypto_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1205:5
+    #6 0x5570e49725e5 in virtio_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio.c:2242:9
+    #7 0x5570e3496356 in virtio_pci_common_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-pci.c:1612:9
+    #8 0x5570e4bbdc93 in memory_region_write_accessor /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:497:5
+    #9 0x5570e4bbd385 in access_with_adjusted_size /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:573:18
+    #10 0x5570e4bbb2f9 in memory_region_dispatch_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:1553:16
+    #11 0x5570e4c64dfe in flatview_write_continue_step /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2786:18
+    #12 0x5570e4c64694 in flatview_write_continue /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2816:19
+    #13 0x5570e4c3b3eb in flatview_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2847:12
+    #14 0x5570e4c3aec8 in address_space_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2967:18
+    #15 0x5570e375da7c in qtest_process_command /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:532:13
+    #16 0x5570e375856d in qtest_process_inbuf /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:776:9
+    #17 0x5570e3767b6e in qtest_read /mnt/Hypervisor/qemu/build/master/fuzz/../system/qtest.c:788:5
+    #18 0x5570e564cafd in qemu_chr_be_write_impl /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:214:9
+    #19 0x5570e564cbb9 in qemu_chr_be_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:226:9
+    #20 0x5570e5658a35 in fd_chr_read /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fd.c:72:9
+    #21 0x5570e500cf6c in qio_channel_fd_source_dispatch /mnt/Hypervisor/qemu/build/master/fuzz/../io/channel-watch.c:84:12
+    #22 0x7f8fc04adf7d in g_main_dispatch /home/lmy/glib-2.68.0/_build/../glib/gmain.c:3337:28
+    #23 0x7f8fc04adf7d in g_main_context_dispatch /home/lmy/glib-2.68.0/_build/../glib/gmain.c:4055:7
+    #24 0x5570e5a014e9 in glib_pollfds_poll /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:287:9
+    #25 0x5570e59ffe23 in os_host_main_loop_wait /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:310:5
+    #26 0x5570e59ff9ec in main_loop_wait /mnt/Hypervisor/qemu/build/master/fuzz/../util/main-loop.c:589:11
+    #27 0x5570e376f217 in qemu_main_loop /mnt/Hypervisor/qemu/build/master/fuzz/../system/runstate.c:835:9
+    #28 0x5570e5679ecc in qemu_default_main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:37:14
+    #29 0x5570e5679f17 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:48:12
+    #30 0x7f8fbe74f082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #31 0x5570e18f189d in _start (/mnt/Hypervisor/qemu/build/master/fuzz/qemu-system-x86_64+0x2c8b89d)
+
+0x618000000b28 is located 680 bytes inside of 800-byte region [0x618000000880,0x618000000ba0)
+freed by thread T0 here:
+    #0 0x5570e196dde2 in __interceptor_free /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:111:3
+    #1 0x5570e37befc1 in cryptodev_vhost_cleanup /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:45:5
+    #2 0x5570e37ce272 in cryptodev_vhost_user_stop /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:86:9
+    #3 0x5570e37cd728 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:171:9
+    #4 0x5570e5655ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5
+    #5 0x5570e564b465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5
+    #6 0x5570e5646076 in tcp_chr_disconnect_locked /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-socket.c:482:9
+    #7 0x5570e5632534 in tcp_chr_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-socket.c:131:17
+    #8 0x5570e564c1f5 in qemu_chr_write_buffer /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:122:15
+    #9 0x5570e564b8a2 in qemu_chr_write /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:186:11
+    #10 0x5570e5615f82 in qemu_chr_fe_write_all /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:52:12
+    #11 0x5570e49ec22c in vhost_user_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:410:11
+    #12 0x5570e4a0e512 in vhost_user_write_sync /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:1141:11
+    #13 0x5570e49f84f9 in vhost_user_set_vring_addr /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost-user.c:1384:12
+    #14 0x5570e3543fcb in vhost_virtqueue_set_addr /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:979:9
+    #15 0x5570e3540a0b in vhost_virtqueue_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1321:9
+    #16 0x5570e3562051 in vhost_dev_start /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:2041:13
+    #17 0x5570e37c10c1 in cryptodev_vhost_start_one /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:96:9
+    #18 0x5570e37c067f in cryptodev_vhost_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost.c:213:13
+    #19 0x5570e34f06ce in virtio_crypto_vhost_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1189:13
+    #20 0x5570e34ce991 in virtio_crypto_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-crypto.c:1205:5
+    #21 0x5570e49725e5 in virtio_set_status /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio.c:2242:9
+    #22 0x5570e3496356 in virtio_pci_common_write /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/virtio-pci.c:1612:9
+    #23 0x5570e4bbdc93 in memory_region_write_accessor /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:497:5
+    #24 0x5570e4bbd385 in access_with_adjusted_size /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:573:18
+    #25 0x5570e4bbb2f9 in memory_region_dispatch_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/memory.c:1553:16
+    #26 0x5570e4c64dfe in flatview_write_continue_step /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2786:18
+    #27 0x5570e4c64694 in flatview_write_continue /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2816:19
+    #28 0x5570e4c3b3eb in flatview_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2847:12
+    #29 0x5570e4c3aec8 in address_space_write /mnt/Hypervisor/qemu/build/master/fuzz/../system/physmem.c:2967:18
+
+previously allocated by thread T0 here:
+    #0 0x5570e196e04d in malloc /home/brian/src/llvm_releases/llvm-project/llvm/utils/release/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
+    #1 0x7f8fc04b3dc8 in g_malloc /home/lmy/glib-2.68.0/_build/../glib/gmem.c:106:13
+    #2 0x5570e37cdca6 in cryptodev_vhost_user_start /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:108:30
+    #3 0x5570e37cd599 in cryptodev_vhost_user_event /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:164:13
+    #4 0x5570e5655ed1 in chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:62:5
+    #5 0x5570e564b465 in qemu_chr_be_event /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char.c:82:5
+    #6 0x5570e5618d42 in qemu_chr_fe_set_handlers_full /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:283:13
+    #7 0x5570e5618674 in qemu_chr_fe_set_handlers /mnt/Hypervisor/qemu/build/master/fuzz/../chardev/char-fe.c:297:5
+    #8 0x5570e37cb960 in cryptodev_vhost_user_init /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev-vhost-user.c:220:5
+    #9 0x5570e37a4e98 in cryptodev_backend_complete /mnt/Hypervisor/qemu/build/master/fuzz/../backends/cryptodev.c:420:9
+    #10 0x5570e4eb0c40 in user_creatable_complete /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:28:9
+    #11 0x5570e4eb16a8 in user_creatable_add_type /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:125:10
+    #12 0x5570e4eb1c74 in user_creatable_add_qapi /mnt/Hypervisor/qemu/build/master/fuzz/../qom/object_interfaces.c:157:11
+    #13 0x5570e378882b in object_option_foreach_add /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:1809:13
+    #14 0x5570e378553c in qemu_create_late_backends /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:2029:5
+    #15 0x5570e3779efe in qemu_init /mnt/Hypervisor/qemu/build/master/fuzz/../system/vl.c:3726:5
+    #16 0x5570e5679f11 in main /mnt/Hypervisor/qemu/build/master/fuzz/../system/main.c:47:5
+    #17 0x7f8fbe74f082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
+
+SUMMARY: AddressSanitizer: heap-use-after-free /mnt/Hypervisor/qemu/build/master/fuzz/../hw/virtio/vhost.c:1359:33 in vhost_virtqueue_start
+Shadow bytes around the buggy address:
+  0x0c307fff8110: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8120: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8130: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8140: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8150: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+=>0x0c307fff8160: fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd
+  0x0c307fff8170: fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c307fff8180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c307fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c307fff81a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+  0x0c307fff81b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+Shadow byte legend (one shadow byte represents 8 application bytes):
+  Addressable:           00
+  Partially addressable: 01 02 03 04 05 06 07
+  Heap left redzone:       fa
+  Freed heap region:       fd
+  Stack left redzone:      f1
+  Stack mid redzone:       f2
+  Stack right redzone:     f3
+  Stack after return:      f5
+  Stack use after scope:   f8
+  Global redzone:          f9
+  Global init order:       f6
+  Poisoned by user:        f7
+  Container overflow:      fc
+  Array cookie:            ac
+  Intra object redzone:    bb
+  ASan internal:           fe
+  Left alloca redzone:     ca
+  Right alloca redzone:    cb
+==2277232==ABORTING
+```
diff --git a/results/classifier/118/device/2765 b/results/classifier/118/device/2765
new file mode 100644
index 00000000..4ac26fea
--- /dev/null
+++ b/results/classifier/118/device/2765
@@ -0,0 +1,31 @@
+device: 0.888
+debug: 0.593
+ppc: 0.559
+risc-v: 0.473
+arm: 0.432
+graphic: 0.429
+socket: 0.410
+performance: 0.401
+semantic: 0.371
+network: 0.305
+vnc: 0.302
+architecture: 0.293
+VMM: 0.271
+register: 0.267
+user-level: 0.257
+peripherals: 0.243
+TCG: 0.241
+files: 0.206
+kernel: 0.204
+mistranslation: 0.195
+PID: 0.194
+boot: 0.111
+hypervisor: 0.097
+virtual: 0.076
+permissions: 0.066
+assembly: 0.041
+KVM: 0.031
+i386: 0.025
+x86: 0.010
+
+InputMethodKit warnings on macOS Sequoia
diff --git a/results/classifier/118/device/2777 b/results/classifier/118/device/2777
new file mode 100644
index 00000000..2f7b84f3
--- /dev/null
+++ b/results/classifier/118/device/2777
@@ -0,0 +1,89 @@
+device: 0.900
+graphic: 0.692
+x86: 0.685
+performance: 0.630
+architecture: 0.503
+hypervisor: 0.378
+kernel: 0.377
+user-level: 0.279
+PID: 0.277
+network: 0.266
+ppc: 0.260
+semantic: 0.246
+permissions: 0.240
+socket: 0.215
+debug: 0.207
+mistranslation: 0.199
+i386: 0.183
+arm: 0.171
+vnc: 0.170
+risc-v: 0.165
+files: 0.165
+VMM: 0.162
+KVM: 0.146
+register: 0.132
+assembly: 0.126
+TCG: 0.111
+boot: 0.104
+peripherals: 0.080
+virtual: 0.078
+
+Assert failure in ahci-hd device
+Description of problem:
+Assert 
+
+```
+qemu-system-x86_64: ../hw/ide/core.c:934: void ide_dma_cb(void *, int): Assertion `prep_size >= 0 && prep_size <= n * 512' failed.
+```
+can be triggered with some qtest commands. This was found by fuzzing.
+Steps to reproduce:
+Command:
+
+```
+cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -machine q35 -nodefaults -drive file=null-co://,if=none,format=raw,id=disk0 -device ide-hd,drive=disk0  -qtest stdio
+outl 0xcf8 0x8000fa24
+outl 0xcfc 0xe0000000
+outl 0xcf8 0x8000fa04
+outw 0xcfc 0x06
+write 0x0 0x1 0x27
+write 0x1 0x1 0x80
+write 0x2 0x1 0x25
+write 0xe00003b8 0x1 0x02
+write 0xe0000398 0x1 0x01
+EOF
+```
+
+Results in 
+
+```
+[I 0.000001] OPENED
+[R +0.076075] outl 0xcf8 0x8000fa24
+[S +0.076165] OK
+OK
+[R +0.076198] outl 0xcfc 0xe0000000
+[S +0.076242] OK
+OK
+[R +0.076320] outl 0xcf8 0x8000fa04
+[S +0.076344] OK
+OK
+[R +0.076379] outw 0xcfc 0x06
+[S +0.077676] OK
+OK
+[R +0.077760] write 0x0 0x1 0x27
+[S +0.079429] OK
+OK
+[R +0.079552] write 0x1 0x1 0x80
+[S +0.079592] OK
+OK
+[R +0.079618] write 0x2 0x1 0x25
+[S +0.079645] OK
+OK
+[R +0.079669] write 0xe00003b8 0x1 0x02
+[S +0.079709] OK
+OK
+[R +0.079733] write 0xe0000398 0x1 0x01
+qemu-system-x86_64: ../hw/ide/core.c:934: void ide_dma_cb(void *, int): Assertion `prep_size >= 0 && prep_size <= n * 512' failed.
+Aborted
+```
+Additional information:
+Maybe we can just `goto eot;` instead of assert?
diff --git a/results/classifier/118/device/2796 b/results/classifier/118/device/2796
new file mode 100644
index 00000000..b0f1ed7d
--- /dev/null
+++ b/results/classifier/118/device/2796
@@ -0,0 +1,37 @@
+device: 0.832
+register: 0.732
+graphic: 0.731
+mistranslation: 0.661
+architecture: 0.568
+performance: 0.485
+semantic: 0.482
+risc-v: 0.454
+kernel: 0.412
+ppc: 0.408
+vnc: 0.357
+arm: 0.312
+PID: 0.285
+permissions: 0.282
+debug: 0.269
+TCG: 0.258
+socket: 0.257
+boot: 0.242
+VMM: 0.204
+user-level: 0.190
+files: 0.183
+network: 0.145
+peripherals: 0.145
+i386: 0.123
+x86: 0.067
+KVM: 0.013
+assembly: 0.012
+hypervisor: 0.006
+virtual: 0.006
+
+Opentitan Timer ignores COMPARE_UPPER0/COMPARE_LOWER0
+Description of problem:
+In a bare metal application, running on an emulated Opentitan board, if you set a timer interrupt threshold by writing to `rv_timer.COMPARE_UPPER0` and `rv_timer.COMPARE_LOWER0` before writing to `rv_timer.CTRL` to start the timer, then the interrupt does not fire. If you write to the `COMPARE_*` registers *after* starting the timer by writing to `CTRL`, then the interrupt fires correctly.
+
+I think the explanation is that [ibex_timer_update_irqs](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/timer/ibex_timer.c?ref_type=heads#L61) has an early return if `rv_timer.CTRL` is not set. As a result, although writes to `COMPARE_*` always call `ibex_timer_update_irqs`, they don't have their intended side-effects before `CTRL` is unset.
+Steps to reproduce:
+Write to `rv_timer.COMPARE_UPPER0` and `rv_timer.COMPARE_LOWER0` before you have set `rv_timer.CTRL`. Observe that no timer interrupt occurs.
diff --git a/results/classifier/118/device/2801 b/results/classifier/118/device/2801
new file mode 100644
index 00000000..80ccb760
--- /dev/null
+++ b/results/classifier/118/device/2801
@@ -0,0 +1,31 @@
+device: 0.987
+peripherals: 0.977
+architecture: 0.955
+assembly: 0.927
+performance: 0.915
+boot: 0.824
+ppc: 0.788
+network: 0.744
+debug: 0.697
+PID: 0.655
+files: 0.654
+arm: 0.633
+risc-v: 0.608
+graphic: 0.545
+permissions: 0.466
+virtual: 0.460
+user-level: 0.456
+register: 0.450
+socket: 0.420
+vnc: 0.289
+semantic: 0.220
+mistranslation: 0.215
+hypervisor: 0.204
+VMM: 0.131
+kernel: 0.114
+TCG: 0.068
+KVM: 0.012
+i386: 0.007
+x86: 0.004
+
+Implement Raspberry PI Zero 2 W.
diff --git a/results/classifier/118/device/2804 b/results/classifier/118/device/2804
new file mode 100644
index 00000000..74e0cc2d
--- /dev/null
+++ b/results/classifier/118/device/2804
@@ -0,0 +1,31 @@
+device: 0.873
+mistranslation: 0.834
+arm: 0.768
+network: 0.583
+debug: 0.580
+risc-v: 0.521
+graphic: 0.468
+semantic: 0.407
+vnc: 0.392
+VMM: 0.385
+performance: 0.356
+register: 0.319
+ppc: 0.299
+socket: 0.297
+TCG: 0.272
+architecture: 0.180
+boot: 0.128
+PID: 0.119
+virtual: 0.092
+peripherals: 0.079
+permissions: 0.073
+files: 0.064
+user-level: 0.048
+i386: 0.043
+hypervisor: 0.022
+assembly: 0.018
+kernel: 0.009
+x86: 0.006
+KVM: 0.003
+
+Unclear meson error when trying to build plugins on macOS
diff --git a/results/classifier/118/device/2805 b/results/classifier/118/device/2805
new file mode 100644
index 00000000..bc0be1f8
--- /dev/null
+++ b/results/classifier/118/device/2805
@@ -0,0 +1,52 @@
+device: 0.940
+socket: 0.913
+files: 0.868
+performance: 0.823
+register: 0.787
+user-level: 0.774
+architecture: 0.772
+graphic: 0.768
+semantic: 0.766
+network: 0.764
+arm: 0.729
+debug: 0.717
+boot: 0.715
+VMM: 0.712
+kernel: 0.671
+vnc: 0.658
+PID: 0.650
+ppc: 0.641
+x86: 0.604
+virtual: 0.601
+peripherals: 0.597
+permissions: 0.595
+hypervisor: 0.580
+risc-v: 0.577
+i386: 0.538
+mistranslation: 0.516
+TCG: 0.511
+assembly: 0.434
+KVM: 0.190
+
+vhost-device-snd does not report correctly the device conf size
+Description of problem:
+The vhost-user-snd frontend is incorrectly reporting the size of the device configuration space, which should be based on the features exposed by the device. For example, the `controls` field in the `virtio_snd_config` structure is optional and should only be included in the configuration size if the `VIRTIO_SND_F_CTLS` feature has been negotiated.  
+
+This issue became apparent after commit `ab0c7fb2`, where `virtio_snd_config` was updated to include the `controls` field. The vhost-user-snd frontend, relying on this structure, started expecting `sizeof(virtio_snd_config)` when communicating with the backend, regardless of whether the `VIRTIO_SND_F_CTLS` feature was negotiated. As a result, any backend reporting a smaller configuration size—for example, one that does not support controls—cannot communicate with the frontend. We observed this problem in the vhost-device-sound rust-vmm device, which we partially fixed [here](https://github.com/rust-vmm/vhost-device/commit/8e7b7109316e1027548bc91cfcbb4b096b032c24).  
+
+This behavior is incorrect because the configuration size should depend on the negotiated features.
+
+I am currently working on patch to fix this.
+Steps to reproduce:
+1. Run vhost-device-sound
+```bash
+ cargo run --bin vhost-device-sound -- --socket=/tmp/vhost-sound.socket --backend=pipewire
+```
+2. Run QEMU with the parameters above
+3. In the guest run:
+```bash
+root@syzkaller:~# aplay /usr/share/sounds/alsa/Front_Left.wav 
+aplay: main:830: audio open error: No such file or directory
+```
+Additional information:
+
diff --git a/results/classifier/118/device/2812 b/results/classifier/118/device/2812
new file mode 100644
index 00000000..dc0c1ffb
--- /dev/null
+++ b/results/classifier/118/device/2812
@@ -0,0 +1,31 @@
+device: 0.920
+boot: 0.762
+ppc: 0.691
+risc-v: 0.637
+performance: 0.618
+graphic: 0.589
+VMM: 0.497
+TCG: 0.473
+debug: 0.411
+register: 0.362
+PID: 0.360
+vnc: 0.325
+i386: 0.281
+user-level: 0.276
+KVM: 0.206
+mistranslation: 0.160
+x86: 0.136
+arm: 0.126
+permissions: 0.117
+peripherals: 0.115
+semantic: 0.084
+assembly: 0.084
+virtual: 0.063
+files: 0.045
+kernel: 0.027
+network: 0.014
+architecture: 0.014
+socket: 0.011
+hypervisor: 0.005
+
+Crash initializing audio device
diff --git a/results/classifier/118/device/283 b/results/classifier/118/device/283
new file mode 100644
index 00000000..95fc284d
--- /dev/null
+++ b/results/classifier/118/device/283
@@ -0,0 +1,31 @@
+TCG: 0.983
+device: 0.921
+graphic: 0.535
+semantic: 0.383
+boot: 0.369
+arm: 0.350
+performance: 0.255
+risc-v: 0.243
+ppc: 0.231
+i386: 0.214
+debug: 0.209
+mistranslation: 0.206
+register: 0.171
+virtual: 0.141
+x86: 0.121
+kernel: 0.113
+user-level: 0.104
+vnc: 0.092
+architecture: 0.088
+permissions: 0.085
+assembly: 0.071
+socket: 0.063
+PID: 0.058
+hypervisor: 0.043
+network: 0.037
+VMM: 0.031
+files: 0.011
+peripherals: 0.007
+KVM: 0.007
+
+TCG memory leak with FreeDOS 'edit'
diff --git a/results/classifier/118/device/2831 b/results/classifier/118/device/2831
new file mode 100644
index 00000000..c94fed46
--- /dev/null
+++ b/results/classifier/118/device/2831
@@ -0,0 +1,50 @@
+device: 0.931
+graphic: 0.884
+risc-v: 0.866
+architecture: 0.783
+PID: 0.770
+debug: 0.740
+performance: 0.725
+vnc: 0.704
+permissions: 0.632
+user-level: 0.627
+mistranslation: 0.625
+ppc: 0.594
+network: 0.592
+peripherals: 0.589
+socket: 0.587
+files: 0.563
+semantic: 0.554
+register: 0.529
+TCG: 0.528
+arm: 0.520
+boot: 0.395
+VMM: 0.356
+kernel: 0.347
+virtual: 0.269
+hypervisor: 0.261
+assembly: 0.123
+x86: 0.113
+KVM: 0.110
+i386: 0.060
+
+unable to build on Sequoia 15.3
+Description of problem:
+
+Steps to reproduce:
+1. git clone https://gitlab.com/qemu-project/qemu.git
+2. ../configure --target-list=riscv32-softmmu --enable-debug
+3. make
+
+Error:
+ld: multiple errors: archive member '/' not a mach-o file in '../qemu/build/subprojects/dtc/libfdt/libfdt.a'; archive member '/' not a mach-o file in '../qemu/build/libqemuutil.a'
+Additional information:
+I tried the more detailed "build for macos" instructions 
+./configure --cc=clang-7 --cxx=clang++-7 --host-cc=clang-7 \
+--extra-cflags=-mavx2 \
+--extra-cxxflags="-I/usr/local/opt/llvm/include" \
+--extra-ldflags="-L/usr/local/opt/llvm/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib" \
+--target-list="<list of machines here>"
+
+but this didn't work for any version of clang I tried, giving me the error in all cases:
+ERROR: C compiler "clang-xxx" either does not exist or does not work.
diff --git a/results/classifier/118/device/2841 b/results/classifier/118/device/2841
new file mode 100644
index 00000000..1110f2e1
--- /dev/null
+++ b/results/classifier/118/device/2841
@@ -0,0 +1,41 @@
+device: 0.922
+graphic: 0.910
+performance: 0.880
+vnc: 0.640
+semantic: 0.622
+boot: 0.576
+risc-v: 0.522
+socket: 0.495
+debug: 0.375
+ppc: 0.369
+PID: 0.366
+hypervisor: 0.311
+network: 0.304
+TCG: 0.301
+x86: 0.264
+user-level: 0.259
+i386: 0.258
+arm: 0.226
+architecture: 0.212
+virtual: 0.199
+mistranslation: 0.188
+files: 0.160
+kernel: 0.157
+peripherals: 0.138
+register: 0.124
+VMM: 0.086
+permissions: 0.048
+assembly: 0.037
+KVM: 0.003
+
+QEMU is increasing memory swap, the only solution is to reboot after a freeze.
+Description of problem:
+Swap starts increasing suddenly and gets to around  60GB before laptop freezes and “dies”.
+Steps to reproduce:
+Seemingly random, didn’t notice any pattern.. it just started happening more often.
+
+![image__2_](/uploads/70d007253835b2dafe17352f8facf0f8/image__2_.png)
+
+![image__4_](/uploads/0cde47d15ec6f988a0aa46dd4af3f799/im
+
+![image__3_](/uploads/f88a567693807d046e048ac6b3deab5a/image__3_.png)age__4_.png)
diff --git a/results/classifier/118/device/2846 b/results/classifier/118/device/2846
new file mode 100644
index 00000000..1a2d0478
--- /dev/null
+++ b/results/classifier/118/device/2846
@@ -0,0 +1,31 @@
+device: 0.830
+user-level: 0.755
+performance: 0.748
+network: 0.624
+architecture: 0.610
+kernel: 0.582
+boot: 0.331
+debug: 0.309
+graphic: 0.280
+arm: 0.220
+PID: 0.218
+peripherals: 0.215
+permissions: 0.205
+TCG: 0.198
+ppc: 0.172
+semantic: 0.121
+VMM: 0.113
+i386: 0.099
+vnc: 0.097
+risc-v: 0.096
+files: 0.073
+register: 0.072
+mistranslation: 0.062
+virtual: 0.060
+socket: 0.050
+assembly: 0.035
+KVM: 0.033
+x86: 0.022
+hypervisor: 0.011
+
+linux-user hangs if fd_trans_lock is held during fork
diff --git a/results/classifier/118/device/2847 b/results/classifier/118/device/2847
new file mode 100644
index 00000000..7dd877bf
--- /dev/null
+++ b/results/classifier/118/device/2847
@@ -0,0 +1,31 @@
+device: 0.846
+architecture: 0.511
+risc-v: 0.454
+performance: 0.433
+graphic: 0.404
+arm: 0.373
+permissions: 0.358
+semantic: 0.354
+boot: 0.345
+vnc: 0.328
+mistranslation: 0.304
+virtual: 0.280
+PID: 0.271
+ppc: 0.246
+register: 0.245
+x86: 0.243
+debug: 0.239
+i386: 0.231
+user-level: 0.222
+socket: 0.221
+TCG: 0.209
+files: 0.199
+network: 0.164
+VMM: 0.162
+assembly: 0.116
+peripherals: 0.035
+KVM: 0.022
+kernel: 0.007
+hypervisor: 0.004
+
+Provide short option for UEFI firmware
diff --git a/results/classifier/118/device/2858 b/results/classifier/118/device/2858
new file mode 100644
index 00000000..49e083dc
--- /dev/null
+++ b/results/classifier/118/device/2858
@@ -0,0 +1,31 @@
+device: 0.925
+debug: 0.691
+performance: 0.645
+mistranslation: 0.346
+user-level: 0.334
+graphic: 0.306
+permissions: 0.268
+hypervisor: 0.254
+register: 0.250
+semantic: 0.249
+arm: 0.220
+boot: 0.188
+network: 0.184
+architecture: 0.126
+virtual: 0.108
+assembly: 0.100
+risc-v: 0.098
+vnc: 0.097
+i386: 0.083
+socket: 0.075
+ppc: 0.052
+peripherals: 0.050
+files: 0.038
+x86: 0.015
+kernel: 0.012
+PID: 0.012
+TCG: 0.008
+VMM: 0.008
+KVM: 0.001
+
+QEMU Command Not Working
diff --git a/results/classifier/118/device/2859 b/results/classifier/118/device/2859
new file mode 100644
index 00000000..49e083dc
--- /dev/null
+++ b/results/classifier/118/device/2859
@@ -0,0 +1,31 @@
+device: 0.925
+debug: 0.691
+performance: 0.645
+mistranslation: 0.346
+user-level: 0.334
+graphic: 0.306
+permissions: 0.268
+hypervisor: 0.254
+register: 0.250
+semantic: 0.249
+arm: 0.220
+boot: 0.188
+network: 0.184
+architecture: 0.126
+virtual: 0.108
+assembly: 0.100
+risc-v: 0.098
+vnc: 0.097
+i386: 0.083
+socket: 0.075
+ppc: 0.052
+peripherals: 0.050
+files: 0.038
+x86: 0.015
+kernel: 0.012
+PID: 0.012
+TCG: 0.008
+VMM: 0.008
+KVM: 0.001
+
+QEMU Command Not Working
diff --git a/results/classifier/118/device/2869 b/results/classifier/118/device/2869
new file mode 100644
index 00000000..ccc2d519
--- /dev/null
+++ b/results/classifier/118/device/2869
@@ -0,0 +1,33 @@
+device: 0.896
+architecture: 0.756
+arm: 0.654
+network: 0.637
+hypervisor: 0.573
+permissions: 0.518
+performance: 0.505
+VMM: 0.501
+mistranslation: 0.491
+register: 0.485
+semantic: 0.381
+boot: 0.373
+graphic: 0.315
+kernel: 0.304
+virtual: 0.301
+peripherals: 0.298
+assembly: 0.262
+risc-v: 0.222
+socket: 0.213
+PID: 0.209
+KVM: 0.187
+TCG: 0.162
+i386: 0.150
+vnc: 0.134
+files: 0.132
+x86: 0.106
+ppc: 0.099
+debug: 0.090
+user-level: 0.085
+
+enable guest mode at amd iommu
+Additional information:
+
diff --git a/results/classifier/118/device/2881 b/results/classifier/118/device/2881
new file mode 100644
index 00000000..3882baff
--- /dev/null
+++ b/results/classifier/118/device/2881
@@ -0,0 +1,40 @@
+device: 0.870
+graphic: 0.666
+semantic: 0.525
+PID: 0.447
+boot: 0.437
+vnc: 0.401
+risc-v: 0.362
+hypervisor: 0.347
+arm: 0.324
+architecture: 0.307
+network: 0.304
+performance: 0.297
+VMM: 0.297
+debug: 0.267
+TCG: 0.254
+register: 0.252
+i386: 0.246
+permissions: 0.221
+ppc: 0.210
+user-level: 0.197
+x86: 0.185
+socket: 0.179
+KVM: 0.178
+mistranslation: 0.150
+virtual: 0.123
+kernel: 0.121
+peripherals: 0.107
+files: 0.076
+assembly: 0.048
+
+segfault on loadvm after migrate_set_capability multifd on
+Description of problem:
+A segfault occurs when running `loadvm` having set `migrate_set_capability multifd on` from the monitor.
+EDIT: also `savevm` segfaults.
+Steps to reproduce:
+1. Take a snapshot with `savevm test`
+2. From the monitor run `migrate_set_capability multifd on`
+3. Try to restore the snapshot with `loadvm test`
+Additional information:
+Sorry for not having triaged this much, I think it is worth reporting anyway.
diff --git a/results/classifier/118/device/2885 b/results/classifier/118/device/2885
new file mode 100644
index 00000000..9bebcb8d
--- /dev/null
+++ b/results/classifier/118/device/2885
@@ -0,0 +1,31 @@
+architecture: 0.976
+device: 0.948
+performance: 0.906
+virtual: 0.847
+risc-v: 0.737
+hypervisor: 0.701
+debug: 0.623
+graphic: 0.568
+semantic: 0.557
+arm: 0.523
+mistranslation: 0.493
+boot: 0.387
+vnc: 0.314
+i386: 0.298
+register: 0.281
+x86: 0.259
+ppc: 0.231
+user-level: 0.229
+VMM: 0.178
+assembly: 0.156
+network: 0.151
+permissions: 0.091
+PID: 0.066
+socket: 0.041
+files: 0.018
+TCG: 0.014
+kernel: 0.013
+KVM: 0.006
+peripherals: 0.004
+
+Unable to increase CPU's for existing RISCV VM
diff --git a/results/classifier/118/device/2886 b/results/classifier/118/device/2886
new file mode 100644
index 00000000..c84c04dc
--- /dev/null
+++ b/results/classifier/118/device/2886
@@ -0,0 +1,45 @@
+device: 0.809
+architecture: 0.707
+graphic: 0.649
+boot: 0.634
+performance: 0.577
+kernel: 0.535
+mistranslation: 0.527
+socket: 0.504
+debug: 0.503
+register: 0.493
+network: 0.453
+i386: 0.425
+vnc: 0.422
+semantic: 0.420
+peripherals: 0.407
+hypervisor: 0.405
+PID: 0.404
+permissions: 0.403
+ppc: 0.364
+x86: 0.334
+arm: 0.298
+assembly: 0.252
+risc-v: 0.242
+files: 0.220
+user-level: 0.201
+VMM: 0.196
+TCG: 0.189
+KVM: 0.161
+virtual: 0.160
+
+ACPI MADT advertises GITS even when disabled
+Description of problem:
+As per the command line given above, QEMU shall emulate a GICv4 without GIC Interrupt Translation Service (GITS).
+
+The following happens:
+- ACPI **incorrectly** lists a GITS (type 0xf) structure in the MADT with GITS MMIO Base = 0x8080000
+- The OS reads that structure and interprets it to mean a GITS is present at the given MMIO address
+- Subsequent access to GITS MMIO causes a data abort (0x25) because QEMU doesn't emulate a GITS (as requested)
+
+The bug is thus that QEMU wrongly advertises GITS as present (via the MADT) when it is in fact absent.
+Steps to reproduce:
+1. Disable GITS emulation by passing `its=off` on the QEMU command line
+2. Check if a GITS structure is listed in the ACPI MADT (must be present in ACPI MADT only if GITS is enabled and absent otherwise)
+Additional information:
+When booting with `its=on` (default), everything works as expected.
diff --git a/results/classifier/118/device/289 b/results/classifier/118/device/289
new file mode 100644
index 00000000..463503af
--- /dev/null
+++ b/results/classifier/118/device/289
@@ -0,0 +1,31 @@
+device: 0.912
+performance: 0.882
+peripherals: 0.668
+graphic: 0.540
+semantic: 0.513
+user-level: 0.492
+architecture: 0.464
+PID: 0.462
+permissions: 0.420
+VMM: 0.394
+risc-v: 0.388
+register: 0.375
+TCG: 0.372
+debug: 0.348
+ppc: 0.321
+network: 0.300
+arm: 0.291
+boot: 0.268
+files: 0.237
+virtual: 0.225
+mistranslation: 0.175
+kernel: 0.139
+vnc: 0.125
+assembly: 0.098
+hypervisor: 0.057
+KVM: 0.040
+socket: 0.018
+i386: 0.009
+x86: 0.003
+
+Guest freezes until there is a keyboard input on Windows version
diff --git a/results/classifier/118/device/2893 b/results/classifier/118/device/2893
new file mode 100644
index 00000000..5cd66119
--- /dev/null
+++ b/results/classifier/118/device/2893
@@ -0,0 +1,42 @@
+device: 0.945
+graphic: 0.927
+arm: 0.832
+boot: 0.783
+peripherals: 0.738
+architecture: 0.712
+performance: 0.694
+semantic: 0.676
+vnc: 0.673
+socket: 0.616
+debug: 0.573
+PID: 0.553
+ppc: 0.509
+network: 0.459
+register: 0.409
+VMM: 0.390
+risc-v: 0.373
+user-level: 0.334
+permissions: 0.331
+mistranslation: 0.330
+TCG: 0.321
+x86: 0.303
+files: 0.276
+kernel: 0.251
+virtual: 0.212
+hypervisor: 0.195
+assembly: 0.116
+i386: 0.100
+KVM: 0.089
+
+with m4 mac mini windows 11 arm 64 iso not booting for installation
+Description of problem:
+Trying to run win11 arm 64 version in m4 mac mini and the ios failed to boot 
+
+i went to the efi shell and tried to boot from there and it just hangs no problem reported 
+
+when i attach the serial to stdio i get the error convertprogress failed to find range errors
+Steps to reproduce:
+1. In m4 mac mini download win11 arm 64 iso from microsoft site
+2. run the above mentioned command and you will see that it does not boot
+
+/label ~"kind::Bug"
diff --git a/results/classifier/118/device/290 b/results/classifier/118/device/290
new file mode 100644
index 00000000..2c6d2604
--- /dev/null
+++ b/results/classifier/118/device/290
@@ -0,0 +1,31 @@
+device: 0.804
+architecture: 0.794
+performance: 0.607
+graphic: 0.600
+network: 0.423
+arm: 0.390
+x86: 0.234
+i386: 0.225
+ppc: 0.223
+VMM: 0.169
+boot: 0.148
+KVM: 0.140
+peripherals: 0.128
+debug: 0.125
+vnc: 0.109
+TCG: 0.105
+risc-v: 0.097
+semantic: 0.073
+hypervisor: 0.063
+mistranslation: 0.060
+user-level: 0.060
+kernel: 0.036
+virtual: 0.027
+assembly: 0.017
+socket: 0.011
+files: 0.011
+PID: 0.010
+permissions: 0.010
+register: 0.006
+
+mmap MAP_NORESERVE of 2^42 bytes consumes 16Gb of actual RAM
diff --git a/results/classifier/118/device/2902 b/results/classifier/118/device/2902
new file mode 100644
index 00000000..f323f2ea
--- /dev/null
+++ b/results/classifier/118/device/2902
@@ -0,0 +1,41 @@
+device: 0.869
+performance: 0.845
+graphic: 0.763
+debug: 0.479
+files: 0.395
+semantic: 0.330
+i386: 0.253
+x86: 0.246
+permissions: 0.191
+vnc: 0.188
+boot: 0.134
+ppc: 0.132
+PID: 0.128
+TCG: 0.123
+risc-v: 0.120
+user-level: 0.092
+architecture: 0.069
+arm: 0.065
+virtual: 0.063
+mistranslation: 0.051
+network: 0.039
+register: 0.035
+peripherals: 0.026
+socket: 0.017
+assembly: 0.017
+hypervisor: 0.012
+VMM: 0.008
+KVM: 0.003
+kernel: 0.002
+
+Data Race with slh_first Field in test-aio-multithread
+Description of problem:
+Potential data races in the `QSLIST_INSERT_HEAD_ATOMIC` macro were identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/test-bdrv-drain
+MALLOC_PERTURB_=102 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-aio-multithread --tap -k
+```
diff --git a/results/classifier/118/device/2904 b/results/classifier/118/device/2904
new file mode 100644
index 00000000..0d37c6ce
--- /dev/null
+++ b/results/classifier/118/device/2904
@@ -0,0 +1,41 @@
+device: 0.880
+performance: 0.880
+graphic: 0.677
+debug: 0.665
+files: 0.606
+boot: 0.479
+network: 0.450
+vnc: 0.409
+i386: 0.383
+x86: 0.373
+semantic: 0.363
+ppc: 0.349
+permissions: 0.326
+arm: 0.326
+PID: 0.287
+TCG: 0.281
+risc-v: 0.206
+socket: 0.169
+architecture: 0.164
+user-level: 0.160
+register: 0.108
+mistranslation: 0.093
+peripherals: 0.077
+virtual: 0.074
+VMM: 0.065
+kernel: 0.059
+assembly: 0.045
+hypervisor: 0.038
+KVM: 0.020
+
+Data Race in data->cb() call and cb assignment in test-aio-multithread
+Description of problem:
+Potential data races between the `data->cb()` call and the assignment of `cb` in `test-aio-multithread` were identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/test-bdrv-drain
+MALLOC_PERTURB_=102 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-aio-multithread --tap -k
+```
diff --git a/results/classifier/118/device/2905 b/results/classifier/118/device/2905
new file mode 100644
index 00000000..9b2b62aa
--- /dev/null
+++ b/results/classifier/118/device/2905
@@ -0,0 +1,54 @@
+device: 0.941
+graphic: 0.933
+architecture: 0.917
+debug: 0.914
+socket: 0.898
+performance: 0.862
+register: 0.852
+x86: 0.839
+ppc: 0.832
+vnc: 0.820
+network: 0.735
+semantic: 0.725
+files: 0.720
+risc-v: 0.668
+permissions: 0.619
+peripherals: 0.607
+TCG: 0.606
+PID: 0.581
+kernel: 0.520
+VMM: 0.500
+arm: 0.470
+assembly: 0.459
+user-level: 0.399
+boot: 0.379
+i386: 0.317
+mistranslation: 0.315
+hypervisor: 0.302
+virtual: 0.301
+KVM: 0.082
+
+Windows Curses Display Infinite Loop
+Description of problem:
+The out-of-the-box `qemu-system-x86_64 -display curses` on Windows loops forever while displaying "VGA Blank Mode" instead of booting like `qemu-system-x86_64` does.
+
+This is caused by an infinite loop in the below simplified code in `curses_refresh` in `ui/curses.c`:
+```
+    int chr;
+    // ...trimmed
+    while (1) {
+        /* while there are any pending key strokes to process */
+        chr = console_getch(&maybe_keycode);
+
+        if (chr == -1) 
+            break;
+    // ...trimmed
+    }
+```
+`console_getch` has return type `wint_t`. However, on Windows, `wint_t` is `unsigned short`. Therefore when `console_getch` returns -1, the -1 value of `unsigned short` will be silently converted into the `int` value 65535. This causes `65535 == -1` to always be false, and the loop will never break. I can send a patch to qemu-devel which retypes `chr` to `wint_t` and replaces occurences of -1 with `WEOF` (an alias for `(wint_t) -1`).
+Steps to reproduce:
+1. Install `qemu-w64-setup-20250326.exe` Windows qemu from https://qemu.weilnetz.de/w64/2025/
+2. Run `./qemu-system-x86_64 -display curses`
+3. "VGA Blank Mode" will appear on the screen forever
+Additional information:
+
diff --git a/results/classifier/118/device/2907 b/results/classifier/118/device/2907
new file mode 100644
index 00000000..240d4980
--- /dev/null
+++ b/results/classifier/118/device/2907
@@ -0,0 +1,31 @@
+device: 0.916
+arm: 0.815
+network: 0.815
+kernel: 0.749
+VMM: 0.709
+vnc: 0.700
+ppc: 0.692
+socket: 0.673
+architecture: 0.663
+debug: 0.663
+performance: 0.620
+TCG: 0.596
+risc-v: 0.592
+boot: 0.488
+permissions: 0.451
+PID: 0.444
+files: 0.408
+register: 0.399
+graphic: 0.386
+assembly: 0.307
+semantic: 0.281
+peripherals: 0.197
+user-level: 0.122
+mistranslation: 0.101
+hypervisor: 0.082
+virtual: 0.050
+i386: 0.018
+KVM: 0.007
+x86: 0.003
+
+replay_mutex_unlock() assertion on macOS
diff --git a/results/classifier/118/device/2912 b/results/classifier/118/device/2912
new file mode 100644
index 00000000..6c4efb25
--- /dev/null
+++ b/results/classifier/118/device/2912
@@ -0,0 +1,43 @@
+device: 0.845
+graphic: 0.817
+virtual: 0.704
+vnc: 0.509
+ppc: 0.448
+risc-v: 0.432
+semantic: 0.423
+boot: 0.309
+register: 0.289
+KVM: 0.275
+PID: 0.268
+i386: 0.237
+hypervisor: 0.207
+debug: 0.204
+network: 0.182
+x86: 0.160
+arm: 0.155
+VMM: 0.150
+TCG: 0.138
+architecture: 0.100
+kernel: 0.097
+performance: 0.094
+files: 0.091
+socket: 0.090
+user-level: 0.090
+mistranslation: 0.071
+permissions: 0.065
+peripherals: 0.060
+assembly: 0.024
+
+qcow2 image corrupted after snapshot+bitmap action
+Description of problem:
+When taking a backup of the VM via snapshot + bitmap, the qcow2 image became corrupt:
+`qcow2: Marking image as corrupt: Preventing invalid write on metadata (overlaps with bitmap directory); further corruption events will be suppressed`
+
+This resulted in a corrupt (unfix-able) image (see #2909).
+
+While this process is something that happens multiple times a day, we never hit any issue.
+The underlying storage didn't report any error, so it seems like something inside qemu broke the image.
+Steps to reproduce:
+Unfortunately, I was unable to reproduce this issue yet.
+Additional information:
+
diff --git a/results/classifier/118/device/2918 b/results/classifier/118/device/2918
new file mode 100644
index 00000000..caf3e93b
--- /dev/null
+++ b/results/classifier/118/device/2918
@@ -0,0 +1,31 @@
+device: 0.811
+performance: 0.764
+architecture: 0.737
+graphic: 0.593
+network: 0.590
+debug: 0.479
+ppc: 0.394
+arm: 0.358
+hypervisor: 0.352
+register: 0.336
+semantic: 0.294
+boot: 0.268
+peripherals: 0.242
+permissions: 0.221
+mistranslation: 0.191
+files: 0.191
+kernel: 0.171
+PID: 0.114
+user-level: 0.104
+socket: 0.097
+virtual: 0.091
+VMM: 0.085
+x86: 0.077
+assembly: 0.072
+TCG: 0.043
+vnc: 0.042
+i386: 0.017
+risc-v: 0.013
+KVM: 0.011
+
+qemu-system-hppa hangs on 64bit installations (machine -C3700)
diff --git a/results/classifier/118/device/2919 b/results/classifier/118/device/2919
new file mode 100644
index 00000000..a23ea1db
--- /dev/null
+++ b/results/classifier/118/device/2919
@@ -0,0 +1,43 @@
+device: 0.848
+graphic: 0.807
+vnc: 0.793
+register: 0.704
+semantic: 0.671
+architecture: 0.649
+network: 0.645
+files: 0.645
+socket: 0.602
+PID: 0.585
+hypervisor: 0.544
+ppc: 0.512
+performance: 0.505
+VMM: 0.498
+risc-v: 0.481
+assembly: 0.466
+boot: 0.456
+kernel: 0.445
+peripherals: 0.436
+permissions: 0.435
+i386: 0.418
+x86: 0.376
+mistranslation: 0.344
+TCG: 0.320
+debug: 0.304
+arm: 0.281
+virtual: 0.267
+user-level: 0.182
+KVM: 0.177
+
+qemu-ga update resetting VssOption Registry key to default
+Description of problem:
+Before I installed the .exe from iso `virtio-win-0.1.271.iso`, I had value 5 in registry key `HKLM:\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider\VssOption`.
+After the driver update by the .exe, the value was set to 1.
+
+This registry key shouldn't change in driver update, as its value was manually set to 5 and it is important to preserve MSSQL backups in Proxmox.
+Source:
+https://blog.datact.ch/backup-mssql-server-with-proxmox
+https://forum.proxmox.com/threads/pbs-breaking-customer-sql-backups-backups-without-fs-freeze.111526/
+Steps to reproduce:
+1. Set a value to `HKLM:\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider\VssOption` other than 1.
+2. Install the .exe from version 0.1.271.
+3. Check the key value.
diff --git a/results/classifier/118/device/2923 b/results/classifier/118/device/2923
new file mode 100644
index 00000000..05d87a35
--- /dev/null
+++ b/results/classifier/118/device/2923
@@ -0,0 +1,43 @@
+device: 0.933
+graphic: 0.920
+peripherals: 0.815
+performance: 0.751
+network: 0.687
+register: 0.667
+PID: 0.645
+files: 0.596
+arm: 0.565
+socket: 0.525
+architecture: 0.517
+permissions: 0.515
+semantic: 0.512
+debug: 0.494
+mistranslation: 0.464
+user-level: 0.441
+boot: 0.380
+ppc: 0.373
+risc-v: 0.365
+assembly: 0.351
+vnc: 0.325
+VMM: 0.283
+TCG: 0.254
+KVM: 0.232
+virtual: 0.202
+i386: 0.194
+x86: 0.174
+kernel: 0.102
+hypervisor: 0.061
+
+Audio crackling issue when USB headset is pass thru via usb-host,hostbus=bus,hostaddr=addr
+Description of problem:
+When we pass thru USB headset via usb port pass-thru, and if the headset supports only 44100 Hz sampling rate, we hear the crackling sound.
+
+The headsets which support 48000Hz works fine.
+Steps to reproduce:
+1. Pass the usb device using hostbus,port.
+2. Connect a usb headset like Logitech H340 which supports only 44100Hz sampling rate.
+3. Play any audio file or youtube video, there is constant crackling sound.
+
+This issue is observed irrespective of the guest OS. Both ubuntu and windows guest, exhibit similar problem.
+Additional information:
+
diff --git a/results/classifier/118/device/2929 b/results/classifier/118/device/2929
new file mode 100644
index 00000000..d3ffd878
--- /dev/null
+++ b/results/classifier/118/device/2929
@@ -0,0 +1,37 @@
+device: 0.936
+mistranslation: 0.711
+network: 0.658
+ppc: 0.606
+graphic: 0.598
+socket: 0.533
+files: 0.513
+virtual: 0.511
+TCG: 0.499
+performance: 0.478
+register: 0.465
+risc-v: 0.462
+semantic: 0.434
+vnc: 0.389
+i386: 0.363
+permissions: 0.357
+boot: 0.353
+architecture: 0.353
+x86: 0.347
+arm: 0.329
+VMM: 0.326
+hypervisor: 0.322
+PID: 0.308
+debug: 0.295
+kernel: 0.286
+assembly: 0.196
+user-level: 0.181
+peripherals: 0.093
+KVM: 0.086
+
+Ask to extend vhost-user protocol to carry implementation defined error contexts
+Additional information:
+I am working on the Google [crosvm](https://chromium.googlesource.com/crosvm/crosvm/) project, which implements some `vhost-user` clients/servers defined by [this QEMU doc](https://qemu-project.gitlab.io/qemu/interop/vhost-user.html). I am wondering if we could add a protocol feature/protocol header flag bit to allow the payload of the reply to carry detailed implementation defined error contexts?
+
+Specifically, I am working on the `vhost-user-gpu` device, which needs to send some memory mapping request to the frontend(the main process where VCPU lives), so that we can map some GPU memory to the guest. We are trying to diagnose a bug where the frontend can sometimes fail to perform the operation. However, we don't have access to the logs on the main process, so we are left with only very limited information on the `vhost-user-gpu` process. It could be helpful if we could send detailed implementation defined error contexts in the payload of the reply.
+
+I am wondering in order for the upstream QEMU to accept such "spec" change to the `vhost-user` protocol, what the process should be like? Thanks.
diff --git a/results/classifier/118/device/293 b/results/classifier/118/device/293
new file mode 100644
index 00000000..c479b27e
--- /dev/null
+++ b/results/classifier/118/device/293
@@ -0,0 +1,31 @@
+device: 0.874
+performance: 0.724
+graphic: 0.642
+network: 0.561
+hypervisor: 0.553
+arm: 0.515
+permissions: 0.409
+kernel: 0.385
+peripherals: 0.339
+boot: 0.331
+files: 0.321
+vnc: 0.320
+register: 0.290
+socket: 0.280
+debug: 0.250
+ppc: 0.242
+risc-v: 0.230
+semantic: 0.224
+architecture: 0.187
+mistranslation: 0.163
+virtual: 0.162
+user-level: 0.103
+VMM: 0.101
+assembly: 0.091
+PID: 0.082
+TCG: 0.052
+x86: 0.008
+i386: 0.005
+KVM: 0.005
+
+Qemu SPARC64 Panics on Sun Solaris 5.8 -  BOP_ALLOC failed
diff --git a/results/classifier/118/device/2930 b/results/classifier/118/device/2930
new file mode 100644
index 00000000..64400da5
--- /dev/null
+++ b/results/classifier/118/device/2930
@@ -0,0 +1,31 @@
+device: 0.846
+architecture: 0.679
+performance: 0.615
+network: 0.600
+hypervisor: 0.513
+graphic: 0.455
+arm: 0.439
+boot: 0.400
+peripherals: 0.355
+semantic: 0.352
+kernel: 0.347
+permissions: 0.344
+socket: 0.317
+mistranslation: 0.258
+virtual: 0.257
+files: 0.242
+user-level: 0.225
+debug: 0.212
+register: 0.206
+VMM: 0.175
+assembly: 0.130
+ppc: 0.127
+vnc: 0.111
+risc-v: 0.107
+PID: 0.099
+TCG: 0.071
+x86: 0.069
+i386: 0.061
+KVM: 0.025
+
+Versions after QEMU9.0 cannot boot vxworks on sifive_u
diff --git a/results/classifier/118/device/2939 b/results/classifier/118/device/2939
new file mode 100644
index 00000000..60fdc702
--- /dev/null
+++ b/results/classifier/118/device/2939
@@ -0,0 +1,31 @@
+device: 0.928
+mistranslation: 0.871
+architecture: 0.835
+assembly: 0.754
+semantic: 0.734
+performance: 0.733
+graphic: 0.729
+peripherals: 0.226
+debug: 0.204
+virtual: 0.183
+user-level: 0.170
+permissions: 0.160
+hypervisor: 0.093
+register: 0.092
+boot: 0.027
+network: 0.022
+files: 0.022
+arm: 0.019
+risc-v: 0.016
+VMM: 0.009
+PID: 0.008
+socket: 0.008
+x86: 0.006
+ppc: 0.006
+kernel: 0.005
+vnc: 0.005
+i386: 0.004
+KVM: 0.004
+TCG: 0.004
+
+Add m68k board name called Macintosh llci
diff --git a/results/classifier/118/device/2940 b/results/classifier/118/device/2940
new file mode 100644
index 00000000..dacf9b89
--- /dev/null
+++ b/results/classifier/118/device/2940
@@ -0,0 +1,31 @@
+device: 0.936
+performance: 0.856
+architecture: 0.713
+kernel: 0.703
+peripherals: 0.631
+arm: 0.600
+graphic: 0.544
+boot: 0.533
+debug: 0.463
+network: 0.420
+hypervisor: 0.345
+user-level: 0.309
+mistranslation: 0.259
+permissions: 0.241
+semantic: 0.231
+assembly: 0.203
+PID: 0.156
+files: 0.137
+register: 0.126
+VMM: 0.118
+virtual: 0.088
+TCG: 0.087
+ppc: 0.077
+socket: 0.073
+risc-v: 0.071
+vnc: 0.056
+i386: 0.023
+x86: 0.018
+KVM: 0.011
+
+Fix i cant boot nextstep os in qemu m68k using next-cube
diff --git a/results/classifier/118/device/2941 b/results/classifier/118/device/2941
new file mode 100644
index 00000000..8fad7e98
--- /dev/null
+++ b/results/classifier/118/device/2941
@@ -0,0 +1,31 @@
+device: 0.902
+mistranslation: 0.702
+performance: 0.663
+graphic: 0.419
+semantic: 0.215
+architecture: 0.179
+assembly: 0.158
+permissions: 0.097
+virtual: 0.054
+user-level: 0.051
+peripherals: 0.037
+vnc: 0.012
+boot: 0.010
+debug: 0.010
+risc-v: 0.009
+ppc: 0.009
+hypervisor: 0.008
+VMM: 0.006
+register: 0.005
+files: 0.004
+arm: 0.004
+TCG: 0.003
+network: 0.003
+PID: 0.003
+KVM: 0.003
+i386: 0.002
+x86: 0.002
+socket: 0.002
+kernel: 0.002
+
+last chance add board called Macintosh llci
diff --git a/results/classifier/118/device/2955 b/results/classifier/118/device/2955
new file mode 100644
index 00000000..73bc59fc
--- /dev/null
+++ b/results/classifier/118/device/2955
@@ -0,0 +1,31 @@
+device: 0.867
+arm: 0.611
+performance: 0.597
+network: 0.575
+semantic: 0.527
+ppc: 0.500
+register: 0.465
+mistranslation: 0.461
+graphic: 0.446
+permissions: 0.370
+boot: 0.351
+risc-v: 0.332
+PID: 0.308
+debug: 0.300
+VMM: 0.297
+architecture: 0.282
+kernel: 0.249
+socket: 0.228
+i386: 0.218
+vnc: 0.215
+x86: 0.162
+assembly: 0.147
+virtual: 0.131
+files: 0.128
+TCG: 0.102
+peripherals: 0.077
+KVM: 0.067
+user-level: 0.061
+hypervisor: 0.017
+
+Mellanox IRQs Still Showing In Host OS After Passthrough
diff --git a/results/classifier/118/device/296 b/results/classifier/118/device/296
new file mode 100644
index 00000000..80e56a9e
--- /dev/null
+++ b/results/classifier/118/device/296
@@ -0,0 +1,31 @@
+device: 0.922
+graphic: 0.586
+performance: 0.498
+user-level: 0.487
+arm: 0.417
+semantic: 0.366
+mistranslation: 0.310
+risc-v: 0.308
+ppc: 0.290
+i386: 0.268
+register: 0.257
+TCG: 0.255
+boot: 0.210
+PID: 0.174
+x86: 0.159
+virtual: 0.135
+VMM: 0.130
+vnc: 0.126
+debug: 0.113
+permissions: 0.108
+network: 0.076
+socket: 0.065
+files: 0.049
+assembly: 0.049
+architecture: 0.049
+peripherals: 0.034
+KVM: 0.026
+hypervisor: 0.004
+kernel: 0.002
+
+Enabling OpenGL for GUI doesn't work on old laptop
diff --git a/results/classifier/118/device/2968 b/results/classifier/118/device/2968
new file mode 100644
index 00000000..4b5aa773
--- /dev/null
+++ b/results/classifier/118/device/2968
@@ -0,0 +1,52 @@
+x86: 0.969
+device: 0.956
+graphic: 0.943
+peripherals: 0.940
+ppc: 0.917
+kernel: 0.871
+architecture: 0.859
+socket: 0.819
+PID: 0.819
+debug: 0.762
+register: 0.738
+hypervisor: 0.736
+permissions: 0.724
+semantic: 0.724
+performance: 0.721
+virtual: 0.701
+files: 0.697
+user-level: 0.697
+vnc: 0.655
+VMM: 0.619
+risc-v: 0.562
+mistranslation: 0.546
+boot: 0.534
+network: 0.474
+arm: 0.458
+assembly: 0.440
+i386: 0.428
+TCG: 0.314
+KVM: 0.294
+
+Regression: x-igd-opregion=off ignored in VFIO IGD quirk handling
+Description of problem:
+A regression in QEMU’s VFIO IGD initialization causes the `x-igd-opregion=off` parameter to be ignored, resulting in an error when passing through an Intel iGPU SR-IOV Virtual Function (VF) at PCI address `00:02.1`: `qemu-system-x86_64: -device vfio-pci,host=0000:00:02.1,...: Device does not supports IGD OpRegion feature: No such device`
+Automatic detection of IGD-OpRegion assumes any Intel iGPU (including GVT-g) will have it but SR-IOV VFs do not.
+Steps to reproduce:
+1. Configure an Intel iGPU with SR-IOV enabled, creating a VF at `00:02.1`.
+2. Bind the VF to the `vfio-pci` driver:
+```
+    echo 0000:00:02.1 > /sys/bus/pci/drivers/i915/unbind
+    either:
+      echo "8086 4680" > /sys/bus/pci/drivers/vfio-pci/new_id
+    or:
+      echo 0000:00:02.1 > /sys/bus/pci/drivers/vfio-pci/bind
+```
+3. Run QEMU with the command line above, including `-device vfio-pci,host=0000:00:02.1,...,x-igd-opregion=off`.
+Additional information:
+- **Hardware details**:
+  - `00:02.1 VGA compatible controller [0300]: Intel Corporation AlderLake-S GT1 [8086:4680] (rev 0c)`
+  - Host motherboard: MSI PRO Z690-A DDR4
+  - CPU: Intel Core i5 12600K
+- **Regression cause**: The issue was introduced by commit 7be29f2f1a3f5b037d27eedbd5df9f441e8c8c16, which changed `vfio_pci_igd_config_quirk` to detect OpRegion automatically, ignoring `vdev->igd_opregion=false`.
+- **Proposed fix**: I have a patch that adds checks for `vdev->igd_opregion` in `vfio_pci_igd_config_quirk` and `vfio_pci_kvmgt_config_quirk`, skipping OpRegion handling when `x-igd-opregion=off`. The patch has been tested, confirming the VM starts without errors. I will submit it to qemu-devel@nongnu.org with a reference to this issue.
diff --git a/results/classifier/118/device/305 b/results/classifier/118/device/305
new file mode 100644
index 00000000..9bee5297
--- /dev/null
+++ b/results/classifier/118/device/305
@@ -0,0 +1,31 @@
+device: 0.851
+performance: 0.754
+graphic: 0.572
+debug: 0.422
+semantic: 0.384
+boot: 0.229
+permissions: 0.204
+architecture: 0.150
+user-level: 0.104
+mistranslation: 0.088
+register: 0.080
+network: 0.071
+virtual: 0.070
+PID: 0.069
+peripherals: 0.047
+arm: 0.047
+socket: 0.039
+x86: 0.028
+VMM: 0.027
+TCG: 0.021
+vnc: 0.011
+assembly: 0.011
+risc-v: 0.010
+files: 0.009
+ppc: 0.009
+KVM: 0.009
+hypervisor: 0.006
+i386: 0.006
+kernel: 0.005
+
+assertion failure in lsi53c810 emulator
diff --git a/results/classifier/118/device/307 b/results/classifier/118/device/307
new file mode 100644
index 00000000..9b58b910
--- /dev/null
+++ b/results/classifier/118/device/307
@@ -0,0 +1,31 @@
+device: 0.886
+performance: 0.745
+network: 0.698
+files: 0.641
+graphic: 0.534
+register: 0.371
+permissions: 0.353
+kernel: 0.346
+architecture: 0.290
+debug: 0.270
+mistranslation: 0.268
+hypervisor: 0.265
+boot: 0.256
+VMM: 0.208
+arm: 0.201
+risc-v: 0.187
+semantic: 0.174
+i386: 0.170
+ppc: 0.152
+peripherals: 0.126
+x86: 0.118
+virtual: 0.110
+PID: 0.085
+vnc: 0.075
+socket: 0.069
+TCG: 0.067
+user-level: 0.066
+assembly: 0.006
+KVM: 0.005
+
+qemu may freeze during drive-mirroring on fragmented FS
diff --git a/results/classifier/118/device/318 b/results/classifier/118/device/318
new file mode 100644
index 00000000..5953f197
--- /dev/null
+++ b/results/classifier/118/device/318
@@ -0,0 +1,31 @@
+device: 0.937
+architecture: 0.850
+graphic: 0.736
+debug: 0.716
+performance: 0.659
+arm: 0.431
+risc-v: 0.204
+boot: 0.173
+register: 0.091
+ppc: 0.090
+semantic: 0.076
+permissions: 0.076
+assembly: 0.069
+virtual: 0.043
+vnc: 0.042
+i386: 0.039
+mistranslation: 0.038
+user-level: 0.035
+PID: 0.025
+peripherals: 0.025
+network: 0.024
+x86: 0.020
+TCG: 0.015
+VMM: 0.009
+files: 0.005
+kernel: 0.004
+socket: 0.004
+hypervisor: 0.003
+KVM: 0.002
+
+QEMU crash after a QuickBASIC program integer overflow
diff --git a/results/classifier/118/device/319 b/results/classifier/118/device/319
new file mode 100644
index 00000000..bdc6b36f
--- /dev/null
+++ b/results/classifier/118/device/319
@@ -0,0 +1,31 @@
+device: 0.955
+architecture: 0.906
+network: 0.627
+performance: 0.615
+graphic: 0.569
+peripherals: 0.528
+boot: 0.471
+register: 0.421
+permissions: 0.392
+debug: 0.356
+socket: 0.331
+user-level: 0.328
+semantic: 0.256
+PID: 0.252
+mistranslation: 0.232
+arm: 0.214
+files: 0.210
+hypervisor: 0.198
+risc-v: 0.131
+assembly: 0.103
+VMM: 0.101
+ppc: 0.097
+virtual: 0.076
+TCG: 0.076
+vnc: 0.067
+x86: 0.034
+i386: 0.011
+KVM: 0.010
+kernel: 0.005
+
+Openjdk11+ fails to install on s390x
diff --git a/results/classifier/118/device/320 b/results/classifier/118/device/320
new file mode 100644
index 00000000..2938997f
--- /dev/null
+++ b/results/classifier/118/device/320
@@ -0,0 +1,31 @@
+device: 0.916
+virtual: 0.864
+hypervisor: 0.810
+performance: 0.699
+semantic: 0.667
+architecture: 0.651
+VMM: 0.578
+debug: 0.557
+mistranslation: 0.547
+network: 0.491
+vnc: 0.467
+graphic: 0.465
+arm: 0.458
+boot: 0.385
+ppc: 0.362
+permissions: 0.315
+PID: 0.305
+register: 0.301
+risc-v: 0.251
+assembly: 0.227
+user-level: 0.207
+peripherals: 0.123
+files: 0.122
+x86: 0.097
+i386: 0.073
+TCG: 0.071
+socket: 0.064
+kernel: 0.038
+KVM: 0.029
+
+Corsair iCUE Install Fails, qemu VM Reboots
diff --git a/results/classifier/118/device/322 b/results/classifier/118/device/322
new file mode 100644
index 00000000..68b872e1
--- /dev/null
+++ b/results/classifier/118/device/322
@@ -0,0 +1,31 @@
+device: 0.919
+peripherals: 0.750
+files: 0.724
+architecture: 0.671
+performance: 0.606
+arm: 0.585
+mistranslation: 0.558
+debug: 0.516
+graphic: 0.432
+PID: 0.428
+assembly: 0.422
+semantic: 0.414
+ppc: 0.408
+kernel: 0.389
+permissions: 0.387
+VMM: 0.368
+risc-v: 0.361
+user-level: 0.314
+boot: 0.306
+vnc: 0.289
+TCG: 0.259
+register: 0.176
+virtual: 0.173
+network: 0.127
+hypervisor: 0.055
+i386: 0.035
+x86: 0.030
+socket: 0.008
+KVM: 0.007
+
+Can't(?) disable default floppy drive any more in qemu 6.0
diff --git a/results/classifier/118/device/325 b/results/classifier/118/device/325
new file mode 100644
index 00000000..f23058ef
--- /dev/null
+++ b/results/classifier/118/device/325
@@ -0,0 +1,31 @@
+device: 0.949
+performance: 0.889
+architecture: 0.683
+graphic: 0.643
+network: 0.560
+arm: 0.388
+hypervisor: 0.302
+peripherals: 0.299
+debug: 0.299
+register: 0.244
+ppc: 0.238
+risc-v: 0.205
+boot: 0.186
+mistranslation: 0.185
+user-level: 0.181
+files: 0.091
+virtual: 0.090
+vnc: 0.087
+permissions: 0.082
+semantic: 0.077
+socket: 0.069
+assembly: 0.063
+i386: 0.047
+PID: 0.046
+x86: 0.028
+TCG: 0.026
+VMM: 0.011
+kernel: 0.008
+KVM: 0.001
+
+Latest QEMU crashes when switching color depth of ReactOS
diff --git a/results/classifier/118/device/328 b/results/classifier/118/device/328
new file mode 100644
index 00000000..6af2e72d
--- /dev/null
+++ b/results/classifier/118/device/328
@@ -0,0 +1,31 @@
+device: 0.881
+hypervisor: 0.546
+KVM: 0.544
+register: 0.542
+ppc: 0.525
+VMM: 0.507
+network: 0.500
+TCG: 0.490
+risc-v: 0.472
+vnc: 0.459
+boot: 0.457
+performance: 0.449
+arm: 0.445
+PID: 0.431
+kernel: 0.417
+i386: 0.369
+user-level: 0.351
+architecture: 0.324
+virtual: 0.292
+x86: 0.289
+debug: 0.267
+graphic: 0.163
+assembly: 0.146
+permissions: 0.146
+semantic: 0.139
+mistranslation: 0.097
+socket: 0.068
+peripherals: 0.066
+files: 0.029
+
+numerical keypad disabled by default in the guest
diff --git a/results/classifier/118/device/329 b/results/classifier/118/device/329
new file mode 100644
index 00000000..95f0c871
--- /dev/null
+++ b/results/classifier/118/device/329
@@ -0,0 +1,31 @@
+device: 0.876
+network: 0.803
+architecture: 0.694
+arm: 0.571
+performance: 0.538
+socket: 0.514
+files: 0.514
+debug: 0.472
+kernel: 0.446
+peripherals: 0.434
+register: 0.434
+hypervisor: 0.432
+boot: 0.427
+graphic: 0.426
+permissions: 0.385
+semantic: 0.354
+VMM: 0.314
+PID: 0.291
+vnc: 0.265
+ppc: 0.219
+virtual: 0.201
+TCG: 0.196
+i386: 0.180
+x86: 0.168
+user-level: 0.160
+risc-v: 0.126
+mistranslation: 0.097
+assembly: 0.066
+KVM: 0.020
+
+qemu 6.0.0 fails to build with clang-11 and --enable-debug
diff --git a/results/classifier/118/device/331 b/results/classifier/118/device/331
new file mode 100644
index 00000000..089e25df
--- /dev/null
+++ b/results/classifier/118/device/331
@@ -0,0 +1,31 @@
+mistranslation: 0.962
+device: 0.955
+network: 0.894
+debug: 0.601
+graphic: 0.466
+architecture: 0.462
+performance: 0.420
+virtual: 0.295
+semantic: 0.229
+arm: 0.207
+assembly: 0.180
+permissions: 0.178
+ppc: 0.156
+hypervisor: 0.141
+register: 0.137
+user-level: 0.116
+boot: 0.100
+peripherals: 0.089
+TCG: 0.089
+VMM: 0.079
+i386: 0.074
+PID: 0.073
+vnc: 0.070
+socket: 0.042
+x86: 0.032
+files: 0.026
+risc-v: 0.025
+KVM: 0.014
+kernel: 0.013
+
+Incorrect feature negotiation for vhost-vdpa netdevice
diff --git a/results/classifier/118/device/334 b/results/classifier/118/device/334
new file mode 100644
index 00000000..c97753e8
--- /dev/null
+++ b/results/classifier/118/device/334
@@ -0,0 +1,31 @@
+device: 0.872
+performance: 0.807
+register: 0.420
+semantic: 0.416
+arm: 0.388
+hypervisor: 0.351
+risc-v: 0.341
+network: 0.329
+PID: 0.323
+ppc: 0.319
+mistranslation: 0.299
+architecture: 0.298
+permissions: 0.282
+graphic: 0.254
+boot: 0.249
+socket: 0.158
+files: 0.155
+user-level: 0.155
+vnc: 0.152
+assembly: 0.142
+debug: 0.123
+TCG: 0.118
+peripherals: 0.107
+VMM: 0.087
+kernel: 0.083
+virtual: 0.059
+i386: 0.031
+x86: 0.005
+KVM: 0.005
+
+macOS App Nap feature gradually freezes QEMU process
diff --git a/results/classifier/118/device/338 b/results/classifier/118/device/338
new file mode 100644
index 00000000..299ee60c
--- /dev/null
+++ b/results/classifier/118/device/338
@@ -0,0 +1,31 @@
+device: 0.806
+performance: 0.713
+architecture: 0.706
+debug: 0.548
+graphic: 0.366
+network: 0.282
+kernel: 0.237
+semantic: 0.235
+socket: 0.163
+hypervisor: 0.162
+peripherals: 0.151
+i386: 0.151
+vnc: 0.138
+register: 0.116
+permissions: 0.113
+PID: 0.105
+mistranslation: 0.096
+arm: 0.095
+x86: 0.092
+VMM: 0.091
+risc-v: 0.086
+TCG: 0.085
+virtual: 0.077
+assembly: 0.072
+boot: 0.063
+files: 0.062
+user-level: 0.058
+ppc: 0.055
+KVM: 0.003
+
+QEMU: Null Pointer Failure in fdctrl_read() in hw/block/fdc.c
diff --git a/results/classifier/118/device/340 b/results/classifier/118/device/340
new file mode 100644
index 00000000..899252ce
--- /dev/null
+++ b/results/classifier/118/device/340
@@ -0,0 +1,31 @@
+device: 0.915
+arm: 0.895
+performance: 0.791
+architecture: 0.678
+network: 0.644
+graphic: 0.600
+debug: 0.408
+register: 0.313
+risc-v: 0.280
+peripherals: 0.276
+ppc: 0.249
+kernel: 0.244
+semantic: 0.238
+boot: 0.231
+vnc: 0.203
+files: 0.178
+mistranslation: 0.168
+permissions: 0.158
+PID: 0.157
+hypervisor: 0.154
+TCG: 0.152
+VMM: 0.134
+virtual: 0.067
+socket: 0.064
+assembly: 0.044
+user-level: 0.032
+x86: 0.010
+i386: 0.007
+KVM: 0.005
+
+qemu: uncaught target signal 6 (Aborted) - core dumped on Apple Silicon M1 arm64
diff --git a/results/classifier/118/device/346 b/results/classifier/118/device/346
new file mode 100644
index 00000000..d76d184d
--- /dev/null
+++ b/results/classifier/118/device/346
@@ -0,0 +1,31 @@
+device: 0.938
+performance: 0.788
+peripherals: 0.754
+graphic: 0.548
+network: 0.499
+architecture: 0.491
+permissions: 0.472
+user-level: 0.446
+hypervisor: 0.411
+risc-v: 0.383
+semantic: 0.333
+register: 0.316
+ppc: 0.314
+boot: 0.301
+debug: 0.293
+mistranslation: 0.269
+i386: 0.242
+arm: 0.179
+x86: 0.176
+virtual: 0.167
+files: 0.153
+kernel: 0.138
+socket: 0.135
+assembly: 0.097
+vnc: 0.092
+PID: 0.086
+TCG: 0.079
+VMM: 0.053
+KVM: 0.024
+
+Guest refuses to accept keyboard input when accelerated with WHPX
diff --git a/results/classifier/118/device/349 b/results/classifier/118/device/349
new file mode 100644
index 00000000..94dbb700
--- /dev/null
+++ b/results/classifier/118/device/349
@@ -0,0 +1,31 @@
+device: 0.840
+files: 0.807
+peripherals: 0.578
+risc-v: 0.490
+performance: 0.431
+network: 0.391
+debug: 0.368
+ppc: 0.328
+graphic: 0.323
+arm: 0.280
+TCG: 0.256
+VMM: 0.236
+semantic: 0.149
+boot: 0.141
+PID: 0.120
+mistranslation: 0.105
+permissions: 0.098
+socket: 0.079
+register: 0.068
+user-level: 0.062
+i386: 0.062
+assembly: 0.060
+vnc: 0.059
+virtual: 0.046
+x86: 0.037
+KVM: 0.034
+architecture: 0.032
+hypervisor: 0.005
+kernel: 0.003
+
+USB folder sharing causing segment fault
diff --git a/results/classifier/118/device/357 b/results/classifier/118/device/357
new file mode 100644
index 00000000..07139c2e
--- /dev/null
+++ b/results/classifier/118/device/357
@@ -0,0 +1,31 @@
+device: 0.864
+performance: 0.688
+debug: 0.577
+network: 0.536
+ppc: 0.535
+risc-v: 0.535
+arm: 0.522
+architecture: 0.485
+graphic: 0.465
+peripherals: 0.411
+VMM: 0.407
+PID: 0.346
+boot: 0.328
+TCG: 0.315
+i386: 0.235
+hypervisor: 0.183
+mistranslation: 0.178
+assembly: 0.170
+register: 0.164
+x86: 0.144
+semantic: 0.141
+KVM: 0.120
+virtual: 0.088
+socket: 0.085
+vnc: 0.084
+permissions: 0.078
+user-level: 0.073
+kernel: 0.068
+files: 0.047
+
+race condition in hw/input/pckbd.c causes wrong data to be read on interrupts
diff --git a/results/classifier/118/device/380 b/results/classifier/118/device/380
new file mode 100644
index 00000000..04932cc5
--- /dev/null
+++ b/results/classifier/118/device/380
@@ -0,0 +1,31 @@
+device: 0.853
+performance: 0.807
+arm: 0.523
+graphic: 0.471
+network: 0.394
+user-level: 0.368
+mistranslation: 0.363
+semantic: 0.361
+peripherals: 0.357
+risc-v: 0.336
+permissions: 0.314
+kernel: 0.293
+register: 0.293
+ppc: 0.283
+socket: 0.282
+PID: 0.278
+VMM: 0.219
+TCG: 0.218
+virtual: 0.198
+architecture: 0.180
+files: 0.178
+debug: 0.172
+vnc: 0.164
+hypervisor: 0.152
+assembly: 0.084
+boot: 0.044
+i386: 0.041
+x86: 0.015
+KVM: 0.013
+
+Windows 7 fails to boot
diff --git a/results/classifier/118/device/383 b/results/classifier/118/device/383
new file mode 100644
index 00000000..3f4f4a35
--- /dev/null
+++ b/results/classifier/118/device/383
@@ -0,0 +1,31 @@
+device: 0.920
+virtual: 0.791
+performance: 0.738
+debug: 0.637
+graphic: 0.514
+architecture: 0.342
+boot: 0.311
+vnc: 0.243
+TCG: 0.204
+network: 0.203
+arm: 0.148
+x86: 0.136
+semantic: 0.128
+mistranslation: 0.128
+i386: 0.122
+PID: 0.107
+VMM: 0.066
+user-level: 0.057
+ppc: 0.057
+register: 0.048
+KVM: 0.027
+hypervisor: 0.017
+risc-v: 0.012
+assembly: 0.009
+permissions: 0.007
+peripherals: 0.005
+files: 0.003
+socket: 0.002
+kernel: 0.001
+
+virtio-gpu: heap-buffer-overflow in virtio_gpu_disable_scanout
diff --git a/results/classifier/118/device/386 b/results/classifier/118/device/386
new file mode 100644
index 00000000..1acacd97
--- /dev/null
+++ b/results/classifier/118/device/386
@@ -0,0 +1,31 @@
+device: 0.858
+mistranslation: 0.758
+peripherals: 0.666
+network: 0.636
+files: 0.626
+register: 0.621
+performance: 0.600
+VMM: 0.580
+TCG: 0.537
+debug: 0.536
+graphic: 0.497
+PID: 0.487
+vnc: 0.485
+architecture: 0.471
+boot: 0.464
+kernel: 0.450
+virtual: 0.369
+permissions: 0.362
+socket: 0.346
+arm: 0.326
+hypervisor: 0.323
+ppc: 0.294
+x86: 0.260
+semantic: 0.232
+risc-v: 0.213
+user-level: 0.131
+i386: 0.117
+KVM: 0.105
+assembly: 0.103
+
+raspi0 machine has incorrect memory mapping for devices
diff --git a/results/classifier/118/device/399 b/results/classifier/118/device/399
new file mode 100644
index 00000000..f9867d76
--- /dev/null
+++ b/results/classifier/118/device/399
@@ -0,0 +1,31 @@
+device: 0.880
+semantic: 0.844
+files: 0.839
+performance: 0.677
+VMM: 0.626
+vnc: 0.603
+TCG: 0.602
+kernel: 0.590
+risc-v: 0.574
+PID: 0.556
+boot: 0.542
+KVM: 0.535
+debug: 0.513
+ppc: 0.475
+i386: 0.390
+x86: 0.334
+graphic: 0.308
+network: 0.285
+arm: 0.230
+user-level: 0.219
+register: 0.216
+permissions: 0.205
+virtual: 0.203
+mistranslation: 0.153
+socket: 0.122
+peripherals: 0.116
+architecture: 0.114
+hypervisor: 0.044
+assembly: 0.010
+
+drive-backup job hangs in a 'paused' state after unsuccessful first attempt
diff --git a/results/classifier/118/device/402 b/results/classifier/118/device/402
new file mode 100644
index 00000000..681f3dad
--- /dev/null
+++ b/results/classifier/118/device/402
@@ -0,0 +1,31 @@
+device: 0.919
+network: 0.856
+performance: 0.802
+virtual: 0.789
+mistranslation: 0.609
+architecture: 0.598
+graphic: 0.576
+debug: 0.565
+hypervisor: 0.489
+peripherals: 0.477
+arm: 0.350
+vnc: 0.342
+semantic: 0.333
+boot: 0.310
+socket: 0.283
+register: 0.280
+VMM: 0.272
+permissions: 0.224
+user-level: 0.214
+ppc: 0.192
+KVM: 0.120
+kernel: 0.117
+x86: 0.117
+risc-v: 0.096
+files: 0.087
+TCG: 0.073
+i386: 0.066
+PID: 0.049
+assembly: 0.041
+
+e1000 / e1000e randomly stop sending packets to VM with DPDK app in VM
diff --git a/results/classifier/118/device/405 b/results/classifier/118/device/405
new file mode 100644
index 00000000..c1c46ec7
--- /dev/null
+++ b/results/classifier/118/device/405
@@ -0,0 +1,31 @@
+device: 0.935
+performance: 0.758
+network: 0.524
+graphic: 0.507
+debug: 0.453
+architecture: 0.445
+assembly: 0.202
+hypervisor: 0.183
+boot: 0.173
+user-level: 0.131
+semantic: 0.128
+mistranslation: 0.099
+register: 0.088
+ppc: 0.083
+arm: 0.074
+VMM: 0.067
+peripherals: 0.063
+TCG: 0.057
+kernel: 0.054
+risc-v: 0.051
+vnc: 0.048
+virtual: 0.045
+x86: 0.038
+KVM: 0.031
+PID: 0.022
+socket: 0.021
+permissions: 0.009
+files: 0.009
+i386: 0.006
+
+Assertion failure in e1000e_intrmgr_on_throttling_timer
diff --git a/results/classifier/118/device/406 b/results/classifier/118/device/406
new file mode 100644
index 00000000..4b307a00
--- /dev/null
+++ b/results/classifier/118/device/406
@@ -0,0 +1,31 @@
+device: 0.986
+permissions: 0.968
+network: 0.968
+virtual: 0.792
+user-level: 0.692
+architecture: 0.646
+PID: 0.610
+TCG: 0.595
+performance: 0.583
+arm: 0.553
+VMM: 0.478
+semantic: 0.469
+register: 0.449
+KVM: 0.437
+vnc: 0.415
+ppc: 0.408
+graphic: 0.407
+debug: 0.382
+risc-v: 0.368
+socket: 0.326
+boot: 0.306
+i386: 0.213
+files: 0.211
+peripherals: 0.208
+mistranslation: 0.195
+kernel: 0.179
+hypervisor: 0.146
+x86: 0.115
+assembly: 0.041
+
+vhost-user net device sends SET_VRING_ENABLE before feature negotiation
diff --git a/results/classifier/118/device/410 b/results/classifier/118/device/410
new file mode 100644
index 00000000..81d7d640
--- /dev/null
+++ b/results/classifier/118/device/410
@@ -0,0 +1,31 @@
+device: 0.897
+performance: 0.735
+debug: 0.450
+graphic: 0.253
+network: 0.174
+arm: 0.133
+ppc: 0.118
+mistranslation: 0.092
+user-level: 0.072
+hypervisor: 0.054
+semantic: 0.047
+architecture: 0.042
+VMM: 0.029
+register: 0.029
+socket: 0.026
+files: 0.026
+boot: 0.025
+risc-v: 0.022
+TCG: 0.021
+peripherals: 0.020
+assembly: 0.019
+PID: 0.018
+virtual: 0.013
+vnc: 0.011
+x86: 0.010
+permissions: 0.009
+KVM: 0.008
+kernel: 0.006
+i386: 0.005
+
+Abort in audio_bug triggered in sb16/pl041
diff --git a/results/classifier/118/device/422 b/results/classifier/118/device/422
new file mode 100644
index 00000000..f852bc34
--- /dev/null
+++ b/results/classifier/118/device/422
@@ -0,0 +1,31 @@
+device: 0.927
+performance: 0.748
+arm: 0.664
+network: 0.579
+architecture: 0.575
+debug: 0.494
+risc-v: 0.486
+graphic: 0.331
+boot: 0.313
+assembly: 0.303
+register: 0.282
+kernel: 0.276
+semantic: 0.274
+permissions: 0.269
+vnc: 0.201
+ppc: 0.191
+socket: 0.175
+hypervisor: 0.168
+virtual: 0.112
+files: 0.110
+mistranslation: 0.096
+user-level: 0.081
+i386: 0.067
+VMM: 0.066
+TCG: 0.061
+peripherals: 0.047
+PID: 0.034
+KVM: 0.009
+x86: 0.008
+
+Unable to execute MIPS MSA code due to illegal instruction
diff --git a/results/classifier/118/device/423 b/results/classifier/118/device/423
new file mode 100644
index 00000000..a3b39cd2
--- /dev/null
+++ b/results/classifier/118/device/423
@@ -0,0 +1,31 @@
+device: 0.855
+architecture: 0.712
+performance: 0.684
+VMM: 0.607
+virtual: 0.591
+files: 0.587
+graphic: 0.434
+mistranslation: 0.408
+semantic: 0.405
+boot: 0.403
+risc-v: 0.389
+arm: 0.383
+debug: 0.377
+permissions: 0.370
+PID: 0.347
+register: 0.313
+user-level: 0.271
+network: 0.210
+i386: 0.209
+vnc: 0.196
+peripherals: 0.154
+socket: 0.152
+ppc: 0.139
+assembly: 0.134
+TCG: 0.096
+hypervisor: 0.091
+kernel: 0.066
+x86: 0.045
+KVM: 0.014
+
+NVME disk cannot be hotplugged after removal
diff --git a/results/classifier/118/device/429 b/results/classifier/118/device/429
new file mode 100644
index 00000000..7b990ecf
--- /dev/null
+++ b/results/classifier/118/device/429
@@ -0,0 +1,31 @@
+device: 0.897
+graphic: 0.648
+semantic: 0.509
+debug: 0.496
+files: 0.462
+performance: 0.406
+PID: 0.405
+register: 0.405
+arm: 0.393
+ppc: 0.361
+architecture: 0.359
+risc-v: 0.332
+assembly: 0.332
+user-level: 0.272
+network: 0.259
+permissions: 0.250
+mistranslation: 0.204
+vnc: 0.202
+socket: 0.184
+kernel: 0.123
+peripherals: 0.104
+VMM: 0.092
+virtual: 0.073
+TCG: 0.071
+hypervisor: 0.034
+boot: 0.012
+i386: 0.002
+KVM: 0.002
+x86: 0.001
+
+Build failure on MacOS with Homebrew after upgrade
diff --git a/results/classifier/118/device/431 b/results/classifier/118/device/431
new file mode 100644
index 00000000..dd01d7f2
--- /dev/null
+++ b/results/classifier/118/device/431
@@ -0,0 +1,31 @@
+device: 0.920
+peripherals: 0.833
+architecture: 0.718
+debug: 0.659
+ppc: 0.650
+performance: 0.631
+arm: 0.549
+socket: 0.519
+risc-v: 0.518
+mistranslation: 0.515
+graphic: 0.495
+semantic: 0.406
+network: 0.374
+vnc: 0.274
+boot: 0.262
+user-level: 0.232
+VMM: 0.199
+PID: 0.195
+TCG: 0.157
+virtual: 0.080
+permissions: 0.056
+assembly: 0.052
+register: 0.044
+files: 0.041
+i386: 0.030
+hypervisor: 0.012
+x86: 0.004
+KVM: 0.004
+kernel: 0.002
+
+USB passthrough in Windows Host non functional
diff --git a/results/classifier/118/device/437 b/results/classifier/118/device/437
new file mode 100644
index 00000000..e06f032e
--- /dev/null
+++ b/results/classifier/118/device/437
@@ -0,0 +1,31 @@
+device: 0.811
+architecture: 0.772
+performance: 0.683
+graphic: 0.602
+arm: 0.588
+mistranslation: 0.357
+debug: 0.333
+semantic: 0.314
+hypervisor: 0.288
+network: 0.227
+virtual: 0.227
+risc-v: 0.224
+register: 0.180
+peripherals: 0.178
+x86: 0.175
+i386: 0.154
+permissions: 0.153
+ppc: 0.130
+vnc: 0.122
+files: 0.098
+boot: 0.093
+socket: 0.066
+user-level: 0.066
+assembly: 0.062
+PID: 0.050
+TCG: 0.021
+VMM: 0.020
+kernel: 0.018
+KVM: 0.004
+
+[AHCI] crash when running a GNU/Hurd guest
diff --git a/results/classifier/118/device/441 b/results/classifier/118/device/441
new file mode 100644
index 00000000..968e973a
--- /dev/null
+++ b/results/classifier/118/device/441
@@ -0,0 +1,31 @@
+device: 0.843
+performance: 0.712
+network: 0.672
+graphic: 0.502
+semantic: 0.414
+debug: 0.411
+arm: 0.397
+architecture: 0.393
+VMM: 0.383
+boot: 0.372
+kernel: 0.354
+hypervisor: 0.349
+i386: 0.328
+PID: 0.323
+register: 0.263
+permissions: 0.262
+TCG: 0.234
+ppc: 0.200
+mistranslation: 0.192
+files: 0.191
+peripherals: 0.186
+virtual: 0.183
+x86: 0.169
+user-level: 0.112
+socket: 0.102
+vnc: 0.089
+assembly: 0.085
+risc-v: 0.038
+KVM: 0.004
+
+qemu-img: "Could not open backing image to determine size" when backing image is encrypted
diff --git a/results/classifier/118/device/448 b/results/classifier/118/device/448
new file mode 100644
index 00000000..2b00be56
--- /dev/null
+++ b/results/classifier/118/device/448
@@ -0,0 +1,31 @@
+device: 0.970
+kernel: 0.879
+architecture: 0.829
+debug: 0.748
+graphic: 0.745
+network: 0.655
+PID: 0.600
+register: 0.580
+files: 0.474
+boot: 0.444
+TCG: 0.421
+performance: 0.384
+ppc: 0.342
+vnc: 0.290
+semantic: 0.270
+permissions: 0.216
+VMM: 0.205
+mistranslation: 0.175
+peripherals: 0.107
+arm: 0.101
+risc-v: 0.098
+socket: 0.072
+user-level: 0.066
+assembly: 0.054
+virtual: 0.048
+i386: 0.032
+hypervisor: 0.018
+x86: 0.003
+KVM: 0.001
+
+raspi0 machine leads to kernel panic of latest raspberry pi os kernel
diff --git a/results/classifier/118/device/46 b/results/classifier/118/device/46
new file mode 100644
index 00000000..d3e74947
--- /dev/null
+++ b/results/classifier/118/device/46
@@ -0,0 +1,31 @@
+device: 0.863
+performance: 0.599
+debug: 0.435
+network: 0.430
+hypervisor: 0.346
+register: 0.338
+boot: 0.292
+semantic: 0.216
+risc-v: 0.213
+user-level: 0.208
+arm: 0.198
+architecture: 0.195
+PID: 0.170
+graphic: 0.168
+vnc: 0.146
+ppc: 0.138
+mistranslation: 0.131
+socket: 0.115
+TCG: 0.111
+permissions: 0.103
+assembly: 0.087
+virtual: 0.081
+files: 0.066
+VMM: 0.060
+peripherals: 0.047
+kernel: 0.045
+x86: 0.028
+i386: 0.024
+KVM: 0.004
+
+Investigate suitibility of GitLab Issue Tracker for QEMU
diff --git a/results/classifier/118/device/461 b/results/classifier/118/device/461
new file mode 100644
index 00000000..20c81dcb
--- /dev/null
+++ b/results/classifier/118/device/461
@@ -0,0 +1,31 @@
+device: 0.888
+performance: 0.761
+graphic: 0.748
+arm: 0.588
+semantic: 0.542
+boot: 0.513
+assembly: 0.504
+peripherals: 0.496
+risc-v: 0.466
+network: 0.463
+architecture: 0.456
+mistranslation: 0.438
+user-level: 0.369
+register: 0.353
+debug: 0.312
+virtual: 0.260
+vnc: 0.232
+hypervisor: 0.202
+socket: 0.188
+VMM: 0.186
+ppc: 0.172
+PID: 0.166
+files: 0.165
+TCG: 0.122
+permissions: 0.119
+kernel: 0.111
+KVM: 0.037
+i386: 0.015
+x86: 0.011
+
+What's your plan of Raspberry 3/3B/4B
diff --git a/results/classifier/118/device/464 b/results/classifier/118/device/464
new file mode 100644
index 00000000..5668f091
--- /dev/null
+++ b/results/classifier/118/device/464
@@ -0,0 +1,31 @@
+device: 0.838
+virtual: 0.689
+hypervisor: 0.605
+performance: 0.548
+graphic: 0.401
+architecture: 0.314
+debug: 0.285
+arm: 0.268
+permissions: 0.186
+register: 0.186
+risc-v: 0.164
+user-level: 0.141
+mistranslation: 0.133
+VMM: 0.132
+semantic: 0.130
+boot: 0.122
+network: 0.104
+PID: 0.089
+vnc: 0.074
+peripherals: 0.066
+TCG: 0.063
+x86: 0.054
+ppc: 0.052
+i386: 0.045
+files: 0.030
+socket: 0.015
+assembly: 0.011
+KVM: 0.009
+kernel: 0.005
+
+The virtio disk shows offline when try to install windows version v6.0.5
diff --git a/results/classifier/118/device/468 b/results/classifier/118/device/468
new file mode 100644
index 00000000..72883b2b
--- /dev/null
+++ b/results/classifier/118/device/468
@@ -0,0 +1,31 @@
+device: 0.963
+architecture: 0.875
+performance: 0.679
+boot: 0.576
+arm: 0.454
+graphic: 0.454
+network: 0.444
+assembly: 0.441
+mistranslation: 0.314
+semantic: 0.216
+kernel: 0.183
+user-level: 0.165
+peripherals: 0.148
+x86: 0.146
+debug: 0.144
+hypervisor: 0.138
+virtual: 0.106
+permissions: 0.095
+register: 0.089
+PID: 0.077
+socket: 0.070
+VMM: 0.049
+risc-v: 0.041
+vnc: 0.030
+KVM: 0.028
+ppc: 0.027
+files: 0.025
+TCG: 0.016
+i386: 0.014
+
+Zynq7000 UART clock reset initialization
diff --git a/results/classifier/118/device/469 b/results/classifier/118/device/469
new file mode 100644
index 00000000..af18e188
--- /dev/null
+++ b/results/classifier/118/device/469
@@ -0,0 +1,31 @@
+device: 0.859
+performance: 0.785
+network: 0.494
+graphic: 0.478
+arm: 0.436
+risc-v: 0.378
+architecture: 0.361
+ppc: 0.341
+virtual: 0.331
+socket: 0.308
+semantic: 0.290
+vnc: 0.278
+user-level: 0.262
+VMM: 0.256
+PID: 0.255
+register: 0.253
+files: 0.226
+peripherals: 0.215
+debug: 0.198
+TCG: 0.196
+permissions: 0.181
+hypervisor: 0.145
+boot: 0.139
+kernel: 0.110
+mistranslation: 0.108
+assembly: 0.051
+KVM: 0.025
+i386: 0.008
+x86: 0.007
+
+SB16 audio playback freezes emulation in Windows 95 guest
diff --git a/results/classifier/118/device/479 b/results/classifier/118/device/479
new file mode 100644
index 00000000..10de6bdb
--- /dev/null
+++ b/results/classifier/118/device/479
@@ -0,0 +1,42 @@
+device: 0.854
+architecture: 0.772
+files: 0.737
+graphic: 0.711
+arm: 0.691
+ppc: 0.691
+network: 0.686
+socket: 0.639
+performance: 0.550
+permissions: 0.502
+debug: 0.491
+semantic: 0.481
+vnc: 0.473
+boot: 0.448
+PID: 0.433
+register: 0.417
+peripherals: 0.412
+kernel: 0.390
+mistranslation: 0.295
+user-level: 0.265
+hypervisor: 0.196
+x86: 0.181
+TCG: 0.179
+VMM: 0.156
+virtual: 0.139
+KVM: 0.128
+risc-v: 0.083
+i386: 0.079
+assembly: 0.057
+
+qemu-6.0.0:  Assertion 'p_rcu_reader->depth != 0' failed
+Description of problem:
+assertion failure:
+```
+qemu-system-aarch64: /home/aileen/Downloads/qemu-6.0.0/include/qemu/rcu.h:93: rcu_read_unlock: Assertion `p_rcu_reader->depth != 0' failed.
+```
+Steps to reproduce:
+1. You cannot
+2.   unless I give
+3.   you the ELF file.
+Additional information:
+
diff --git a/results/classifier/118/device/48 b/results/classifier/118/device/48
new file mode 100644
index 00000000..24433550
--- /dev/null
+++ b/results/classifier/118/device/48
@@ -0,0 +1,31 @@
+device: 0.907
+graphic: 0.629
+performance: 0.497
+VMM: 0.486
+i386: 0.475
+KVM: 0.435
+TCG: 0.415
+risc-v: 0.395
+network: 0.389
+x86: 0.379
+ppc: 0.374
+vnc: 0.334
+PID: 0.288
+hypervisor: 0.281
+architecture: 0.274
+arm: 0.264
+user-level: 0.242
+boot: 0.234
+semantic: 0.209
+mistranslation: 0.192
+peripherals: 0.171
+kernel: 0.155
+files: 0.096
+virtual: 0.092
+register: 0.064
+permissions: 0.054
+debug: 0.053
+socket: 0.044
+assembly: 0.032
+
+Hover effect color for "Full list of releases" button is low contrast
diff --git a/results/classifier/118/device/481 b/results/classifier/118/device/481
new file mode 100644
index 00000000..2c70dc88
--- /dev/null
+++ b/results/classifier/118/device/481
@@ -0,0 +1,31 @@
+device: 0.920
+network: 0.681
+performance: 0.670
+mistranslation: 0.564
+architecture: 0.548
+assembly: 0.427
+debug: 0.383
+graphic: 0.352
+hypervisor: 0.274
+permissions: 0.254
+semantic: 0.205
+user-level: 0.173
+peripherals: 0.129
+virtual: 0.123
+register: 0.115
+arm: 0.069
+files: 0.059
+boot: 0.040
+ppc: 0.024
+risc-v: 0.018
+x86: 0.018
+socket: 0.016
+vnc: 0.015
+i386: 0.008
+TCG: 0.007
+PID: 0.005
+kernel: 0.005
+VMM: 0.004
+KVM: 0.003
+
+Implement I2C for BCM2835 (raspi)
diff --git a/results/classifier/118/device/482 b/results/classifier/118/device/482
new file mode 100644
index 00000000..6e17c23b
--- /dev/null
+++ b/results/classifier/118/device/482
@@ -0,0 +1,31 @@
+device: 0.878
+network: 0.707
+performance: 0.669
+register: 0.621
+architecture: 0.588
+kernel: 0.587
+socket: 0.571
+graphic: 0.506
+arm: 0.482
+debug: 0.397
+virtual: 0.339
+files: 0.338
+vnc: 0.324
+TCG: 0.321
+hypervisor: 0.309
+risc-v: 0.283
+boot: 0.270
+ppc: 0.252
+semantic: 0.216
+KVM: 0.214
+x86: 0.210
+PID: 0.205
+permissions: 0.203
+peripherals: 0.180
+user-level: 0.110
+VMM: 0.085
+mistranslation: 0.071
+assembly: 0.061
+i386: 0.059
+
+Unable to set SVE VL to 1024 bits or above since 7b6a2198
diff --git a/results/classifier/118/device/487 b/results/classifier/118/device/487
new file mode 100644
index 00000000..4faf10ce
--- /dev/null
+++ b/results/classifier/118/device/487
@@ -0,0 +1,31 @@
+device: 0.927
+performance: 0.803
+permissions: 0.757
+mistranslation: 0.751
+semantic: 0.539
+architecture: 0.531
+network: 0.518
+graphic: 0.493
+peripherals: 0.399
+debug: 0.353
+virtual: 0.331
+files: 0.274
+hypervisor: 0.256
+assembly: 0.220
+arm: 0.200
+register: 0.184
+user-level: 0.177
+i386: 0.161
+x86: 0.150
+VMM: 0.141
+TCG: 0.111
+KVM: 0.104
+boot: 0.104
+socket: 0.078
+ppc: 0.073
+risc-v: 0.050
+kernel: 0.044
+PID: 0.040
+vnc: 0.020
+
+sdhci: out of bounds read on sd->sd_status
diff --git a/results/classifier/118/device/49 b/results/classifier/118/device/49
new file mode 100644
index 00000000..569f2ad8
--- /dev/null
+++ b/results/classifier/118/device/49
@@ -0,0 +1,31 @@
+device: 0.833
+performance: 0.759
+mistranslation: 0.700
+architecture: 0.630
+graphic: 0.594
+semantic: 0.542
+user-level: 0.285
+virtual: 0.179
+boot: 0.169
+permissions: 0.158
+network: 0.144
+risc-v: 0.128
+debug: 0.118
+assembly: 0.090
+arm: 0.071
+register: 0.070
+vnc: 0.056
+ppc: 0.049
+peripherals: 0.025
+socket: 0.025
+PID: 0.019
+i386: 0.018
+hypervisor: 0.015
+files: 0.014
+x86: 0.011
+TCG: 0.008
+VMM: 0.007
+KVM: 0.002
+kernel: 0.002
+
+[Feature request] MDIO bus
diff --git a/results/classifier/118/device/501 b/results/classifier/118/device/501
new file mode 100644
index 00000000..690a5cac
--- /dev/null
+++ b/results/classifier/118/device/501
@@ -0,0 +1,31 @@
+device: 0.832
+kernel: 0.717
+performance: 0.716
+network: 0.494
+debug: 0.477
+hypervisor: 0.462
+TCG: 0.444
+architecture: 0.436
+VMM: 0.433
+files: 0.412
+virtual: 0.409
+arm: 0.402
+vnc: 0.400
+permissions: 0.393
+register: 0.382
+graphic: 0.367
+peripherals: 0.349
+KVM: 0.329
+socket: 0.310
+ppc: 0.308
+x86: 0.294
+PID: 0.292
+semantic: 0.278
+mistranslation: 0.274
+assembly: 0.252
+user-level: 0.240
+boot: 0.224
+i386: 0.223
+risc-v: 0.218
+
+6.1.0-rc0 Regression: No keyboard input possible
diff --git a/results/classifier/118/device/502 b/results/classifier/118/device/502
new file mode 100644
index 00000000..5d3988b9
--- /dev/null
+++ b/results/classifier/118/device/502
@@ -0,0 +1,31 @@
+device: 0.815
+performance: 0.747
+kernel: 0.639
+network: 0.520
+vnc: 0.485
+debug: 0.459
+TCG: 0.456
+files: 0.450
+hypervisor: 0.434
+peripherals: 0.427
+graphic: 0.425
+arm: 0.424
+virtual: 0.404
+VMM: 0.398
+architecture: 0.397
+register: 0.366
+permissions: 0.358
+KVM: 0.352
+mistranslation: 0.342
+ppc: 0.321
+semantic: 0.317
+socket: 0.299
+PID: 0.295
+boot: 0.239
+x86: 0.227
+user-level: 0.225
+risc-v: 0.208
+assembly: 0.200
+i386: 0.198
+
+6.1.0-rc0 Regression: No mouse input possible
diff --git a/results/classifier/118/device/503 b/results/classifier/118/device/503
new file mode 100644
index 00000000..9b59f635
--- /dev/null
+++ b/results/classifier/118/device/503
@@ -0,0 +1,31 @@
+architecture: 0.987
+device: 0.941
+debug: 0.665
+graphic: 0.584
+performance: 0.481
+hypervisor: 0.369
+arm: 0.359
+files: 0.287
+boot: 0.237
+register: 0.229
+peripherals: 0.207
+network: 0.183
+semantic: 0.146
+mistranslation: 0.117
+virtual: 0.095
+permissions: 0.092
+user-level: 0.080
+vnc: 0.048
+risc-v: 0.047
+assembly: 0.042
+ppc: 0.041
+PID: 0.030
+socket: 0.030
+kernel: 0.019
+TCG: 0.016
+VMM: 0.015
+x86: 0.003
+i386: 0.001
+KVM: 0.001
+
+QEMU aarch64 Segmentation fault on Mac OSX, machine raspi3
diff --git a/results/classifier/118/device/506 b/results/classifier/118/device/506
new file mode 100644
index 00000000..3d574806
--- /dev/null
+++ b/results/classifier/118/device/506
@@ -0,0 +1,31 @@
+device: 0.808
+network: 0.701
+performance: 0.597
+graphic: 0.541
+VMM: 0.539
+virtual: 0.487
+arm: 0.480
+TCG: 0.453
+hypervisor: 0.412
+peripherals: 0.389
+architecture: 0.348
+risc-v: 0.313
+kernel: 0.261
+register: 0.252
+semantic: 0.234
+boot: 0.219
+vnc: 0.216
+PID: 0.202
+files: 0.188
+debug: 0.172
+mistranslation: 0.125
+KVM: 0.112
+x86: 0.098
+i386: 0.078
+permissions: 0.052
+ppc: 0.031
+assembly: 0.011
+socket: 0.011
+user-level: 0.006
+
+ga: auto-discover virtio port using sysfs
diff --git a/results/classifier/118/device/51 b/results/classifier/118/device/51
new file mode 100644
index 00000000..916a26f2
--- /dev/null
+++ b/results/classifier/118/device/51
@@ -0,0 +1,31 @@
+device: 0.976
+kernel: 0.972
+architecture: 0.918
+performance: 0.748
+graphic: 0.729
+peripherals: 0.726
+mistranslation: 0.640
+debug: 0.494
+VMM: 0.415
+network: 0.414
+boot: 0.401
+arm: 0.336
+permissions: 0.277
+virtual: 0.221
+semantic: 0.195
+risc-v: 0.139
+i386: 0.134
+ppc: 0.117
+x86: 0.117
+TCG: 0.101
+user-level: 0.097
+PID: 0.088
+register: 0.052
+vnc: 0.035
+files: 0.030
+hypervisor: 0.025
+assembly: 0.016
+KVM: 0.012
+socket: 0.012
+
+Linux kernel oops on Malta board while accessing pflash
diff --git a/results/classifier/118/device/511 b/results/classifier/118/device/511
new file mode 100644
index 00000000..4e4bd0d4
--- /dev/null
+++ b/results/classifier/118/device/511
@@ -0,0 +1,31 @@
+device: 0.857
+performance: 0.623
+debug: 0.535
+network: 0.498
+arm: 0.424
+graphic: 0.386
+peripherals: 0.354
+files: 0.341
+boot: 0.296
+semantic: 0.262
+ppc: 0.247
+mistranslation: 0.237
+register: 0.193
+architecture: 0.162
+risc-v: 0.152
+PID: 0.134
+permissions: 0.107
+socket: 0.103
+VMM: 0.091
+virtual: 0.078
+vnc: 0.073
+i386: 0.071
+TCG: 0.056
+user-level: 0.056
+kernel: 0.055
+x86: 0.053
+hypervisor: 0.035
+KVM: 0.028
+assembly: 0.011
+
+usbredirparser: bulk transfer length exceeds limits (can't use any USB storage)
diff --git a/results/classifier/118/device/513 b/results/classifier/118/device/513
new file mode 100644
index 00000000..e8907e4b
--- /dev/null
+++ b/results/classifier/118/device/513
@@ -0,0 +1,31 @@
+device: 0.977
+architecture: 0.851
+performance: 0.721
+network: 0.659
+graphic: 0.574
+arm: 0.472
+debug: 0.400
+user-level: 0.345
+boot: 0.311
+register: 0.296
+ppc: 0.221
+semantic: 0.219
+files: 0.214
+permissions: 0.191
+risc-v: 0.177
+i386: 0.145
+x86: 0.119
+virtual: 0.103
+peripherals: 0.091
+socket: 0.082
+mistranslation: 0.071
+PID: 0.063
+vnc: 0.058
+kernel: 0.028
+assembly: 0.018
+hypervisor: 0.008
+VMM: 0.004
+TCG: 0.004
+KVM: 0.001
+
+Qemu/WHPX fails on applying UEFI firmware with -pflash
diff --git a/results/classifier/118/device/518 b/results/classifier/118/device/518
new file mode 100644
index 00000000..6b40d326
--- /dev/null
+++ b/results/classifier/118/device/518
@@ -0,0 +1,31 @@
+device: 0.972
+arm: 0.970
+mistranslation: 0.868
+peripherals: 0.863
+performance: 0.790
+virtual: 0.779
+semantic: 0.769
+user-level: 0.720
+ppc: 0.718
+permissions: 0.682
+PID: 0.660
+assembly: 0.526
+risc-v: 0.526
+VMM: 0.421
+vnc: 0.413
+graphic: 0.402
+register: 0.361
+TCG: 0.353
+debug: 0.281
+boot: 0.247
+network: 0.193
+files: 0.129
+architecture: 0.090
+socket: 0.053
+KVM: 0.046
+hypervisor: 0.034
+i386: 0.019
+kernel: 0.014
+x86: 0.007
+
+Android for arm guest
diff --git a/results/classifier/118/device/529 b/results/classifier/118/device/529
new file mode 100644
index 00000000..9b8793e3
--- /dev/null
+++ b/results/classifier/118/device/529
@@ -0,0 +1,34 @@
+device: 0.926
+graphic: 0.905
+peripherals: 0.761
+socket: 0.727
+mistranslation: 0.665
+semantic: 0.654
+performance: 0.540
+files: 0.500
+architecture: 0.460
+boot: 0.390
+register: 0.340
+network: 0.270
+TCG: 0.221
+PID: 0.193
+debug: 0.164
+vnc: 0.132
+ppc: 0.129
+permissions: 0.064
+user-level: 0.051
+VMM: 0.043
+virtual: 0.042
+arm: 0.031
+x86: 0.028
+hypervisor: 0.027
+i386: 0.025
+risc-v: 0.025
+kernel: 0.008
+assembly: 0.003
+KVM: 0.001
+
+qemu-system-riscv64 hard lockup on non-stdio serial output
+Additional information:
+u-boot pre-compiled firmware: (directory contains all git revisions, build flags, etc)
+https://github.com/haiku/firmware/tree/master/u-boot/riscv64/qemu
diff --git a/results/classifier/118/device/535 b/results/classifier/118/device/535
new file mode 100644
index 00000000..269287e3
--- /dev/null
+++ b/results/classifier/118/device/535
@@ -0,0 +1,31 @@
+device: 0.877
+performance: 0.779
+graphic: 0.648
+debug: 0.619
+architecture: 0.528
+network: 0.442
+mistranslation: 0.394
+boot: 0.208
+semantic: 0.208
+assembly: 0.190
+arm: 0.172
+kernel: 0.139
+KVM: 0.136
+hypervisor: 0.120
+VMM: 0.115
+TCG: 0.110
+vnc: 0.084
+ppc: 0.083
+user-level: 0.056
+PID: 0.052
+risc-v: 0.050
+virtual: 0.037
+register: 0.036
+x86: 0.035
+peripherals: 0.031
+files: 0.031
+socket: 0.030
+i386: 0.025
+permissions: 0.021
+
+Assertion failure in iov_from_buf_full through the e1000e
diff --git a/results/classifier/118/device/537 b/results/classifier/118/device/537
new file mode 100644
index 00000000..9d73d75f
--- /dev/null
+++ b/results/classifier/118/device/537
@@ -0,0 +1,31 @@
+device: 0.821
+performance: 0.764
+debug: 0.632
+graphic: 0.542
+architecture: 0.327
+network: 0.324
+ppc: 0.273
+boot: 0.222
+arm: 0.214
+semantic: 0.203
+risc-v: 0.171
+assembly: 0.147
+vnc: 0.132
+peripherals: 0.128
+VMM: 0.125
+mistranslation: 0.122
+TCG: 0.120
+hypervisor: 0.119
+kernel: 0.106
+KVM: 0.090
+user-level: 0.081
+x86: 0.081
+virtual: 0.056
+socket: 0.049
+PID: 0.049
+register: 0.037
+i386: 0.027
+files: 0.020
+permissions: 0.011
+
+Assertion failure in e1000e_write_to_rx_buffers
diff --git a/results/classifier/118/device/538 b/results/classifier/118/device/538
new file mode 100644
index 00000000..d812d127
--- /dev/null
+++ b/results/classifier/118/device/538
@@ -0,0 +1,31 @@
+device: 0.857
+performance: 0.624
+hypervisor: 0.612
+x86: 0.381
+i386: 0.373
+graphic: 0.336
+architecture: 0.155
+debug: 0.152
+semantic: 0.138
+arm: 0.101
+ppc: 0.088
+boot: 0.076
+virtual: 0.052
+user-level: 0.046
+KVM: 0.031
+assembly: 0.025
+mistranslation: 0.022
+PID: 0.020
+TCG: 0.017
+VMM: 0.016
+permissions: 0.015
+network: 0.012
+vnc: 0.008
+register: 0.007
+peripherals: 0.006
+risc-v: 0.006
+socket: 0.003
+kernel: 0.002
+files: 0.001
+
+Memory Leak in hpet_timer results in unusable machine
diff --git a/results/classifier/118/device/54 b/results/classifier/118/device/54
new file mode 100644
index 00000000..ae8dc296
--- /dev/null
+++ b/results/classifier/118/device/54
@@ -0,0 +1,31 @@
+device: 0.956
+arm: 0.907
+network: 0.774
+performance: 0.646
+architecture: 0.618
+peripherals: 0.593
+graphic: 0.553
+boot: 0.482
+debug: 0.368
+assembly: 0.281
+permissions: 0.268
+semantic: 0.184
+mistranslation: 0.147
+risc-v: 0.115
+register: 0.102
+socket: 0.082
+vnc: 0.081
+user-level: 0.071
+files: 0.064
+ppc: 0.064
+virtual: 0.050
+i386: 0.041
+PID: 0.021
+hypervisor: 0.017
+x86: 0.014
+TCG: 0.010
+VMM: 0.009
+kernel: 0.005
+KVM: 0.005
+
+Attaching SD-Card to specific SD-Bus Sabrelite (ARM)
diff --git a/results/classifier/118/device/540 b/results/classifier/118/device/540
new file mode 100644
index 00000000..7af5162e
--- /dev/null
+++ b/results/classifier/118/device/540
@@ -0,0 +1,31 @@
+device: 0.911
+network: 0.641
+performance: 0.599
+graphic: 0.586
+peripherals: 0.500
+arm: 0.367
+mistranslation: 0.336
+ppc: 0.312
+semantic: 0.301
+architecture: 0.210
+boot: 0.191
+debug: 0.173
+user-level: 0.083
+VMM: 0.082
+assembly: 0.065
+virtual: 0.045
+socket: 0.040
+vnc: 0.038
+i386: 0.037
+risc-v: 0.033
+hypervisor: 0.033
+TCG: 0.029
+PID: 0.029
+files: 0.022
+permissions: 0.014
+register: 0.011
+kernel: 0.011
+x86: 0.010
+KVM: 0.005
+
+Heap-use-after-free in usb_packet_unmap through xhci
diff --git a/results/classifier/118/device/542 b/results/classifier/118/device/542
new file mode 100644
index 00000000..562fc3e6
--- /dev/null
+++ b/results/classifier/118/device/542
@@ -0,0 +1,31 @@
+device: 0.855
+graphic: 0.560
+network: 0.243
+architecture: 0.131
+boot: 0.099
+i386: 0.091
+arm: 0.085
+x86: 0.085
+ppc: 0.078
+debug: 0.062
+vnc: 0.048
+VMM: 0.040
+hypervisor: 0.029
+virtual: 0.027
+user-level: 0.023
+TCG: 0.017
+semantic: 0.013
+performance: 0.012
+register: 0.009
+KVM: 0.009
+files: 0.008
+mistranslation: 0.007
+PID: 0.007
+peripherals: 0.007
+kernel: 0.007
+risc-v: 0.006
+assembly: 0.006
+permissions: 0.005
+socket: 0.004
+
+Stack-overflow in ldl_le_dma through intel-hda (CVE-2021-3611)
diff --git a/results/classifier/118/device/55 b/results/classifier/118/device/55
new file mode 100644
index 00000000..86b06c00
--- /dev/null
+++ b/results/classifier/118/device/55
@@ -0,0 +1,31 @@
+device: 0.922
+network: 0.681
+performance: 0.507
+graphic: 0.482
+peripherals: 0.480
+architecture: 0.438
+debug: 0.406
+permissions: 0.331
+mistranslation: 0.284
+arm: 0.274
+files: 0.270
+boot: 0.237
+semantic: 0.236
+user-level: 0.219
+hypervisor: 0.090
+virtual: 0.085
+assembly: 0.079
+register: 0.078
+risc-v: 0.049
+ppc: 0.048
+PID: 0.048
+socket: 0.031
+TCG: 0.029
+VMM: 0.021
+x86: 0.014
+vnc: 0.013
+kernel: 0.013
+KVM: 0.008
+i386: 0.006
+
+Can't install Windows 7 with q35 (SATA)
diff --git a/results/classifier/118/device/554 b/results/classifier/118/device/554
new file mode 100644
index 00000000..af328742
--- /dev/null
+++ b/results/classifier/118/device/554
@@ -0,0 +1,31 @@
+device: 0.922
+peripherals: 0.587
+performance: 0.563
+graphic: 0.516
+virtual: 0.308
+architecture: 0.283
+permissions: 0.248
+mistranslation: 0.231
+TCG: 0.164
+files: 0.164
+semantic: 0.161
+boot: 0.149
+VMM: 0.137
+PID: 0.116
+debug: 0.109
+risc-v: 0.103
+KVM: 0.083
+network: 0.073
+ppc: 0.073
+vnc: 0.052
+x86: 0.041
+hypervisor: 0.037
+arm: 0.036
+kernel: 0.029
+register: 0.026
+user-level: 0.010
+i386: 0.006
+assembly: 0.003
+socket: 0.001
+
+q35 machine type cdrom device not discovered by freedos
diff --git a/results/classifier/118/device/558 b/results/classifier/118/device/558
new file mode 100644
index 00000000..2793054f
--- /dev/null
+++ b/results/classifier/118/device/558
@@ -0,0 +1,87 @@
+device: 0.987
+mistranslation: 0.975
+graphic: 0.949
+performance: 0.910
+user-level: 0.840
+VMM: 0.740
+semantic: 0.720
+vnc: 0.667
+risc-v: 0.629
+KVM: 0.626
+hypervisor: 0.623
+architecture: 0.619
+network: 0.613
+boot: 0.587
+socket: 0.585
+PID: 0.578
+kernel: 0.572
+permissions: 0.546
+virtual: 0.514
+ppc: 0.440
+x86: 0.386
+arm: 0.385
+i386: 0.354
+debug: 0.328
+peripherals: 0.280
+assembly: 0.265
+TCG: 0.252
+files: 0.230
+register: 0.145
+
+gtk UI interprets double/triple click as button release
+Description of problem:
+When using the GTK interface clicking rapidly in a down-up-down pattern, the final "down" event is erroneously followed by an immediate "up" event and the mouse device in the guest reports the pressed button as no longer being held.
+Steps to reproduce:
+1. Start a VM using the GTK interface.
+2. Open a tool to examine guest mouse input events, such as `xev` or `yutani-test`
+3. Click twice with any button, without releasing on the second click.
+4. Observe erroneous 'up' event in guest.
+5. Move the mouse while keeping the button pressed.
+6. Observe the guest reports the button is not held.
+Additional information:
+GTK 3 sends an additional `GDK_2BUTTON_PRESS` event after the initial `GDK_BUTTON_PRESS` event, which QEMU is misinterpreting as a release event. I confirmed this with the addition of some logging of `button->type` in `gd_button_event`:
+
+```
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4 # = PRESS
+button = 1, type = 5 # = 2BUTTON_PRESS
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 5
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 7
+button = 1, type = 4
+button = 1, type = 5
+button = 1, type = 7
+```
+
+```diff
+diff --git a/ui/gtk.c b/ui/gtk.c
+index cfb0728d1f..b9979f0e11 100644
+--- a/ui/gtk.c
++++ b/ui/gtk.c
+@@ -925,6 +925,13 @@ static gboolean gd_button_event(GtkWidget *widget, GdkEventButton *button,
+         return TRUE;
+     }
+ 
++    /* ignore additional events for double- and triple- press, as they are
++     * sent to us after a regular press event; otherwise we will misinterpret
++     * these as release events and eat the button! */
++    if (button->type == GDK_2BUTTON_PRESS || button->type == GDK_3BUTTON_PRESS) {
++        return TRUE;
++    }
++
+     qemu_input_queue_btn(vc->gfx.dcl.con, btn,
+                          button->type == GDK_BUTTON_PRESS);
+     qemu_input_event_sync();
+```
diff --git a/results/classifier/118/device/560 b/results/classifier/118/device/560
new file mode 100644
index 00000000..fa8b2596
--- /dev/null
+++ b/results/classifier/118/device/560
@@ -0,0 +1,31 @@
+device: 0.817
+user-level: 0.774
+performance: 0.658
+mistranslation: 0.640
+semantic: 0.500
+network: 0.393
+virtual: 0.352
+architecture: 0.315
+arm: 0.277
+graphic: 0.262
+boot: 0.210
+PID: 0.202
+i386: 0.195
+register: 0.186
+risc-v: 0.135
+ppc: 0.131
+files: 0.129
+debug: 0.097
+TCG: 0.075
+hypervisor: 0.070
+vnc: 0.057
+permissions: 0.048
+peripherals: 0.036
+x86: 0.034
+assembly: 0.028
+VMM: 0.024
+socket: 0.021
+kernel: 0.008
+KVM: 0.003
+
+User-emu documentation mentions inexistent "runtime" downloads
diff --git a/results/classifier/118/device/565 b/results/classifier/118/device/565
new file mode 100644
index 00000000..b446a6ea
--- /dev/null
+++ b/results/classifier/118/device/565
@@ -0,0 +1,31 @@
+device: 0.843
+permissions: 0.759
+network: 0.756
+ppc: 0.658
+vnc: 0.657
+debug: 0.573
+socket: 0.553
+risc-v: 0.552
+arm: 0.544
+architecture: 0.529
+performance: 0.405
+VMM: 0.398
+graphic: 0.332
+register: 0.317
+PID: 0.303
+boot: 0.263
+TCG: 0.216
+semantic: 0.205
+kernel: 0.202
+peripherals: 0.165
+files: 0.140
+hypervisor: 0.117
+mistranslation: 0.115
+i386: 0.110
+virtual: 0.089
+user-level: 0.065
+assembly: 0.059
+x86: 0.002
+KVM: 0.001
+
+maybe-uninitialized warning in Xtensa flush_window_regs()
diff --git a/results/classifier/118/device/567 b/results/classifier/118/device/567
new file mode 100644
index 00000000..7ff46eb1
--- /dev/null
+++ b/results/classifier/118/device/567
@@ -0,0 +1,31 @@
+device: 0.821
+architecture: 0.737
+performance: 0.594
+arm: 0.514
+graphic: 0.488
+network: 0.443
+hypervisor: 0.432
+debug: 0.415
+permissions: 0.351
+semantic: 0.341
+boot: 0.318
+files: 0.317
+virtual: 0.310
+peripherals: 0.278
+vnc: 0.267
+mistranslation: 0.265
+VMM: 0.252
+user-level: 0.231
+register: 0.228
+PID: 0.197
+assembly: 0.143
+ppc: 0.134
+risc-v: 0.112
+socket: 0.098
+TCG: 0.098
+kernel: 0.086
+i386: 0.030
+x86: 0.022
+KVM: 0.012
+
+qemu 6.1.0 build fail on alpine linux
diff --git a/results/classifier/118/device/57 b/results/classifier/118/device/57
new file mode 100644
index 00000000..bb9981c7
--- /dev/null
+++ b/results/classifier/118/device/57
@@ -0,0 +1,31 @@
+device: 0.928
+mistranslation: 0.877
+performance: 0.758
+graphic: 0.752
+semantic: 0.592
+peripherals: 0.532
+virtual: 0.507
+boot: 0.489
+ppc: 0.405
+debug: 0.390
+risc-v: 0.382
+user-level: 0.356
+vnc: 0.279
+i386: 0.195
+architecture: 0.173
+files: 0.172
+hypervisor: 0.152
+arm: 0.144
+permissions: 0.140
+network: 0.138
+register: 0.105
+x86: 0.101
+socket: 0.046
+kernel: 0.029
+PID: 0.028
+assembly: 0.028
+VMM: 0.026
+KVM: 0.013
+TCG: 0.013
+
+IDE short PRDT abort
diff --git a/results/classifier/118/device/571 b/results/classifier/118/device/571
new file mode 100644
index 00000000..701a9839
--- /dev/null
+++ b/results/classifier/118/device/571
@@ -0,0 +1,31 @@
+device: 0.834
+peripherals: 0.720
+performance: 0.636
+debug: 0.615
+assembly: 0.603
+architecture: 0.498
+graphic: 0.431
+semantic: 0.167
+boot: 0.090
+user-level: 0.082
+arm: 0.079
+mistranslation: 0.071
+risc-v: 0.060
+network: 0.059
+ppc: 0.053
+TCG: 0.049
+virtual: 0.044
+VMM: 0.034
+vnc: 0.023
+register: 0.018
+permissions: 0.014
+socket: 0.009
+PID: 0.008
+hypervisor: 0.006
+kernel: 0.003
+i386: 0.003
+x86: 0.002
+files: 0.002
+KVM: 0.002
+
+maybe-uninitialized warning in mips cpu_loop()
diff --git a/results/classifier/118/device/573 b/results/classifier/118/device/573
new file mode 100644
index 00000000..9bd9d089
--- /dev/null
+++ b/results/classifier/118/device/573
@@ -0,0 +1,31 @@
+device: 0.910
+mistranslation: 0.774
+network: 0.724
+assembly: 0.698
+vnc: 0.568
+architecture: 0.522
+performance: 0.492
+debug: 0.477
+boot: 0.386
+arm: 0.305
+graphic: 0.291
+risc-v: 0.231
+ppc: 0.213
+peripherals: 0.171
+socket: 0.143
+hypervisor: 0.141
+user-level: 0.116
+VMM: 0.106
+semantic: 0.097
+kernel: 0.094
+files: 0.091
+virtual: 0.088
+TCG: 0.066
+register: 0.065
+PID: 0.063
+x86: 0.061
+i386: 0.034
+permissions: 0.017
+KVM: 0.008
+
+maybe-uninitialized warning in pnv_phb3_translate_iommu()
diff --git a/results/classifier/118/device/586 b/results/classifier/118/device/586
new file mode 100644
index 00000000..591c3174
--- /dev/null
+++ b/results/classifier/118/device/586
@@ -0,0 +1,31 @@
+device: 0.831
+network: 0.719
+virtual: 0.682
+architecture: 0.640
+performance: 0.602
+kernel: 0.521
+graphic: 0.480
+hypervisor: 0.407
+arm: 0.398
+permissions: 0.396
+semantic: 0.390
+files: 0.365
+mistranslation: 0.298
+VMM: 0.296
+peripherals: 0.260
+boot: 0.253
+x86: 0.247
+i386: 0.211
+PID: 0.204
+debug: 0.194
+TCG: 0.190
+register: 0.166
+user-level: 0.166
+ppc: 0.130
+assembly: 0.097
+vnc: 0.096
+KVM: 0.047
+risc-v: 0.022
+socket: 0.015
+
+virtio-gpu: qemu 6.1.0 no longer enables virgl when using '-vga virtio'
diff --git a/results/classifier/118/device/588693 b/results/classifier/118/device/588693
new file mode 100644
index 00000000..2c6b3241
--- /dev/null
+++ b/results/classifier/118/device/588693
@@ -0,0 +1,41 @@
+device: 0.838
+ppc: 0.549
+network: 0.544
+performance: 0.535
+mistranslation: 0.525
+boot: 0.501
+graphic: 0.497
+socket: 0.496
+register: 0.458
+risc-v: 0.444
+vnc: 0.428
+architecture: 0.406
+semantic: 0.376
+files: 0.361
+VMM: 0.305
+TCG: 0.296
+permissions: 0.295
+PID: 0.280
+debug: 0.279
+peripherals: 0.272
+kernel: 0.261
+x86: 0.212
+i386: 0.209
+hypervisor: 0.195
+arm: 0.153
+assembly: 0.145
+user-level: 0.143
+virtual: 0.114
+KVM: 0.099
+
+CD-ROM devices always return a one session, one track TOC
+
+CD-ROM devices always return a one session, one track TOC, no matter if it is using ioctl's with the host or DMG images (both able of having multi track, multi session discs).
+
+(P.S.: This bug prevents BeOS boot)
+
+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/118/device/590 b/results/classifier/118/device/590
new file mode 100644
index 00000000..b1d76e59
--- /dev/null
+++ b/results/classifier/118/device/590
@@ -0,0 +1,31 @@
+device: 0.823
+arm: 0.592
+network: 0.487
+register: 0.466
+architecture: 0.465
+graphic: 0.437
+semantic: 0.424
+boot: 0.332
+debug: 0.303
+socket: 0.297
+performance: 0.262
+risc-v: 0.261
+assembly: 0.233
+permissions: 0.216
+ppc: 0.203
+vnc: 0.197
+PID: 0.157
+mistranslation: 0.142
+files: 0.089
+VMM: 0.059
+TCG: 0.053
+user-level: 0.051
+virtual: 0.050
+peripherals: 0.041
+i386: 0.038
+hypervisor: 0.032
+kernel: 0.023
+x86: 0.006
+KVM: 0.006
+
+NSIS Windows installer generator warnings when cross-building on MinGW
diff --git a/results/classifier/118/device/604 b/results/classifier/118/device/604
new file mode 100644
index 00000000..95f0401c
--- /dev/null
+++ b/results/classifier/118/device/604
@@ -0,0 +1,31 @@
+device: 0.866
+graphic: 0.861
+mistranslation: 0.846
+performance: 0.811
+semantic: 0.386
+architecture: 0.373
+network: 0.359
+debug: 0.266
+register: 0.128
+arm: 0.121
+boot: 0.102
+virtual: 0.083
+i386: 0.081
+permissions: 0.077
+vnc: 0.076
+user-level: 0.075
+ppc: 0.067
+peripherals: 0.066
+hypervisor: 0.064
+socket: 0.048
+files: 0.046
+TCG: 0.033
+VMM: 0.032
+assembly: 0.031
+PID: 0.024
+risc-v: 0.016
+kernel: 0.015
+x86: 0.012
+KVM: 0.002
+
+QEMU crashes with "-global driver=isa-fdc"
diff --git a/results/classifier/118/device/608 b/results/classifier/118/device/608
new file mode 100644
index 00000000..4cbe55ac
--- /dev/null
+++ b/results/classifier/118/device/608
@@ -0,0 +1,31 @@
+device: 0.812
+debug: 0.601
+kernel: 0.541
+network: 0.532
+graphic: 0.428
+arm: 0.423
+PID: 0.411
+performance: 0.381
+architecture: 0.373
+TCG: 0.364
+ppc: 0.361
+files: 0.335
+VMM: 0.328
+i386: 0.291
+risc-v: 0.286
+hypervisor: 0.268
+KVM: 0.253
+boot: 0.247
+vnc: 0.219
+x86: 0.207
+peripherals: 0.148
+mistranslation: 0.146
+semantic: 0.141
+socket: 0.124
+virtual: 0.087
+register: 0.075
+user-level: 0.074
+assembly: 0.068
+permissions: 0.042
+
+incremental_live_backup:  Error prompt info when do incremental backup with an invalid "bitmap-mode"
diff --git a/results/classifier/118/device/617 b/results/classifier/118/device/617
new file mode 100644
index 00000000..405f0c7d
--- /dev/null
+++ b/results/classifier/118/device/617
@@ -0,0 +1,56 @@
+device: 0.935
+graphic: 0.913
+performance: 0.903
+peripherals: 0.882
+socket: 0.818
+user-level: 0.815
+semantic: 0.804
+vnc: 0.797
+virtual: 0.769
+arm: 0.727
+architecture: 0.727
+boot: 0.707
+network: 0.702
+PID: 0.692
+ppc: 0.663
+mistranslation: 0.661
+kernel: 0.660
+debug: 0.643
+permissions: 0.630
+register: 0.629
+risc-v: 0.580
+hypervisor: 0.544
+assembly: 0.533
+VMM: 0.458
+TCG: 0.364
+files: 0.345
+KVM: 0.323
+i386: 0.205
+x86: 0.204
+
+USB passthrough with Conbee 2 failing after upgrade to Fedora 34 / Libvirt 7.0.0
+Description of problem:
+Hi,
+
+I upgraded recently from Fedora 32 to 34.
+
+For a little under a year, I've been running reliably a Home Assistant instance with Deconz add-on in a VM, with a Conbee 2 zigbee gateway in USB passthrough, controlling about 15 devices (door/window sensors, thermometers, leak sensors and push buttons).
+
+It has worked flawlessly but stopped working after upgrading Fedora. The Conbee shows up on the Linux guest but the serial can't be read by the Deconz application and it just does not work, the app can't get past the device connection screen.
+
+This is the state of what works and what doesn't:
+
+- Home Assistant Linux VM: NOK
+- Ubuntu Linux 20.04 VM: NOK
+- Windows 10 VM: NOK
+- Windows 10 physical machine: OK, can connect and pair a door sensor
+
+All running the latest Deconz app.
+
+The fact that the physical Windows machine works excludes a bricked device. I used the physical Windows to upgrade the Conbee 2 firmware with no improvement. 
+
+This does not seem to be an isolated issue: https://old.reddit.com/r/homeassistant/comments/o04sgw/conbee_ii_usb_passthrough_with_libvirt_660/
+
+Apologies if this has already been reported. Let me know what kind of logs you might want.
+
+Thanks!
diff --git a/results/classifier/118/device/623852 b/results/classifier/118/device/623852
new file mode 100644
index 00000000..cd3f3e66
--- /dev/null
+++ b/results/classifier/118/device/623852
@@ -0,0 +1,353 @@
+device: 0.865
+assembly: 0.863
+boot: 0.863
+user-level: 0.858
+permissions: 0.858
+kernel: 0.854
+debug: 0.853
+socket: 0.848
+performance: 0.847
+register: 0.845
+mistranslation: 0.844
+semantic: 0.843
+PID: 0.838
+architecture: 0.829
+graphic: 0.824
+virtual: 0.822
+risc-v: 0.821
+files: 0.816
+arm: 0.815
+network: 0.802
+hypervisor: 0.773
+ppc: 0.768
+vnc: 0.767
+peripherals: 0.759
+KVM: 0.740
+TCG: 0.721
+VMM: 0.671
+i386: 0.626
+x86: 0.619
+
+PPC emulation loops on booting a FreeBSD kernel
+
+Has anyone tried booting FreeBSD8.1-ppc under QEMU (Linux x86_64 host; PPC guest)?  I can get Linux/PPC to run fine, and FreeBSD8.1-i386 as well; but there seems to be a problem with whatever the FreeBSD8.1 kernel does, that QEMU's PPC emulation can't handle.
+
+I am using the latest version of QEMU from GIT as of 25/8/10.  I don't know how to get a "git commit hash", so I can't quote it.
+
+The kernel starts OK then loops after "Kernel entry at 0x100100 ...".
+
+The command I am running is
+
+qemu-system-ppc -cdrom FreeBSD-8.1-RELEASE-powerpc-disc1.iso -hda freebsd8.1-ppc -m 94 -boot d"
+
+I obtained the kernel from ftp://ftp.freebsd.org/pub/FreeBSD/releases/powerpc/ISO-IMAGES/8.1/FreeBSD-8.1-RELEASE-powerpc-disc1.iso.
+
+I did a "git log" command, and the first line is "2446333cd5b5c985f6517dee7004e542ecacd21c".  Is that what you mean by a git hash?  If so, I hope it helps.
+
+It looks like a firmware issue. Please report this to <email address hidden>. You get the output below by using the -nographic option.
+
+
+>> =============================================================
+>> OpenBIOS 1.0 [Aug 17 2010 14:41]
+>> Configuration device id QEMU version 1 machine id 2
+>> CPUs: 1
+>> Memory: 512M
+>> UUID: 00000000-0000-0000-0000-000000000000
+>> CPU type PowerPC,750
+Welcome to OpenBIOS v1.0 built on Aug 17 2010 14:41
+Trying cd:,\\:tbxi...
+Consoles: Open Firmware console  
+
+FreeBSD/powerpc Open Firmware loader, Revision 0.1
+(<email address hidden>, Sun Jul 18 04:50:11 UTC 2010)
+Memory: 524288KB
+Booted from: cd
+
+Loading /boot/defaults/loader.conf 
+/boot/kernel/kernel data=0x72c6b8+0x3e280 syms=[0x4+0x5ac10+0x4+0x7d8ad]
+/
+Hit [Enter] to boot immediately, or any other key for command prompt.
+Booting [/boot/kernel/kernel]...               
+Kernel entry at 0x100100 ...
+panic: OFW translations above 32-bit boundary!
+Uptime: 1s
+
+
+I have been asked to forward this to you - could you help, please?
+
+Thanks!
+
+-Nigel
+
+
+-------- Original Message --------
+
+It looks like a firmware issue. Please report this to
+<email address hidden>. You get the output below by using the -nographic
+option.
+
+
+>>  =============================================================
+>>  OpenBIOS 1.0 [Aug 17 2010 14:41]
+>>  Configuration device id QEMU version 1 machine id 2
+>>  CPUs: 1
+>>  Memory: 512M
+>>  UUID: 00000000-0000-0000-0000-000000000000
+>>  CPU type PowerPC,750
+Welcome to OpenBIOS v1.0 built on Aug 17 2010 14:41
+Trying cd:,\\:tbxi...
+Consoles: Open Firmware console
+
+FreeBSD/powerpc Open Firmware loader, Revision 0.1
+(<email address hidden>, Sun Jul 18 04:50:11 UTC 2010)
+Memory: 524288KB
+Booted from: cd
+
+Loading /boot/defaults/loader.conf
+/boot/kernel/kernel data=0x72c6b8+0x3e280 syms=[0x4+0x5ac10+0x4+0x7d8ad]
+/
+Hit [Enter] to boot immediately, or any other key for command prompt.
+Booting [/boot/kernel/kernel]...
+Kernel entry at 0x100100 ...
+panic: OFW translations above 32-bit boundary!
+Uptime: 1s
+
+-- 
+PPC emulation loops on booting a FreeBSD kernel
+https://bugs.launchpad.net/bugs/623852
+You received this bug notification because you are a direct subscriber
+of the bug.
+
+Status in QEMU: New
+
+Bug description:
+Has anyone tried booting FreeBSD8.1-ppc under QEMU (Linux x86_64 host; PPC guest)?  I can get Linux/PPC to run fine, and FreeBSD8.1-i386 as well; but there seems to be a problem with whatever the FreeBSD8.1 kernel does, that QEMU's PPC emulation can't handle.
+
+I am using the latest version of QEMU from GIT as of 25/8/10.  I don't know how to get a "git commit hash", so I can't quote it.
+
+The kernel starts OK then loops after "Kernel entry at 0x100100 ...".
+
+The command I am running is
+
+qemu-system-ppc -cdrom FreeBSD-8.1-RELEASE-powerpc-disc1.iso -hda freebsd8.1-ppc -m 94 -boot d"
+
+I obtained the kernel from ftp://ftp.freebsd.org/pub/FreeBSD/releases/powerpc/ISO-IMAGES/8.1/FreeBSD-8.1-RELEASE-powerpc-disc1.iso.
+
+To unsubscribe from this bug, go to:
+https://bugs.launchpad.net/qemu/+bug/623852/+subscribe
+
+
+On 25/08/10 10:08, agraf wrote:
+> It looks like a firmware issue. Please report this to
+> <email address hidden>. You get the output below by using the -nographic
+> option.
+>    
+I have done so, though to be honest I don't see that panic even if I use 
+-nographic, QEMU still silently loops for me.
+>>> =============================================================
+>>> OpenBIOS 1.0 [Aug 17 2010 14:41]
+>>> Configuration device id QEMU version 1 machine id 2
+>>> CPUs: 1
+>>> Memory: 512M
+>>> UUID: 00000000-0000-0000-0000-000000000000
+>>> CPU type PowerPC,750
+>>>        
+> Welcome to OpenBIOS v1.0 built on Aug 17 2010 14:41
+> Trying cd:,\\:tbxi...
+> Consoles: Open Firmware console
+>
+> FreeBSD/powerpc Open Firmware loader, Revision 0.1
+> (<email address hidden>, Sun Jul 18 04:50:11 UTC 2010)
+> Memory: 524288KB
+> Booted from: cd
+>
+> Loading /boot/defaults/loader.conf
+> /boot/kernel/kernel data=0x72c6b8+0x3e280 syms=[0x4+0x5ac10+0x4+0x7d8ad]
+> /
+> Hit [Enter] to boot immediately, or any other key for command prompt.
+> Booting [/boot/kernel/kernel]...
+> Kernel entry at 0x100100 ...
+> panic: OFW translations above 32-bit boundary!
+> Uptime: 1s
+>
+>    
+-Nigel
+
+-- 
+Nigel Horne. Arranger, Adjudicator, Band Trainer, Composer, Tutor, Typesetter.
+NJH Music, ICQ#20252325, twitter: @nigelhorne
+<email address hidden> http://www.bandsman.co.uk
+
+
+Please confirm that you tested with qemu-system-ppc, not qemu-system-ppc64.
+
+I got the "above 32-bit boundary" message with ppc64 - but that's to be expected.  And given that I didn't see your message running 32-bit PPC I want to ensure that you did try with the 32-bit emulator.
+
+Also I can confirm that I have this problem on QEMU.
+I had tried booting FreeBSD8.1-ppc under QEMU (Linux x86_64 host; PPC guest) but there seems to be a problem with whatever the FreeBSD8.1 kernel does, that QEMU's PPC emulation can't handle.
+
+I am using the latest version of QEMU from GIT as of 11/9/10.
+The kernel starts OK then loops after "Kernel entry at 0x100100 ...".
+
+Hi.
+
+The same issue from here.
+
+---------------------------------------------
+me@host:~$ qemu-system-ppc -cdrom FreeBSD-8.2-RELEASE-powerpc-disc1.iso \
+-hda freebsd8.2-ppc.img -m 94 -boot d -bios /usr/share/openbios/openbios-ppc -nographic
+qemu: warning: could not load VGA bios 'video.x'
+
+>> =============================================================
+>> OpenBIOS 1.0 [Feb 19 2011 11:37]
+>> Configuration device id QEMU version 1 machine id 2
+>> CPUs: 1
+>> Memory: 94M
+>> UUID: 00000000-0000-0000-0000-000000000000
+>> CPU type PowerPC,750
+Welcome to OpenBIOS v1.0 built on Feb 19 2011 11:37
+Trying cd:,\\:tbxi...
+Consoles: Open Firmware console  
+
+FreeBSD/powerpc Open Firmware loader, Revision 0.1
+(<email address hidden>, Fri Feb 18 18:49:01 UTC 2011)
+Memory: 96256KB
+Booted from: cd
+
+Loading /boot/defaults/loader.conf 
+/boot/kernel/kernel data=0x7417ac+0x3e3dc syms=[0x4+0x5c110+0x4+0x7f9c7]
+|
+Hit [Enter] to boot immediately, or any other key for command prompt.
+Booting [/boot/kernel/kernel]...               
+Kernel entry at 0x100100 ...
+invalid/unsupported opcode: 1f - 12 - 05 (7d200164) 005a6ae0 0
+---------------------------------------------------
+
+My host machine is a Debian "squeeze".
+I'm using the openbios-ppc from "wheeze" package.
+
+QEMU version: 0.12.5+dfsg-3squeeze1
+openbios-ppc version: 1.0+svn1018-1_all
+freebsd version: FreeBSD-8.2-RELEASE-powerpc-disc1.iso
+
+
+The only diference from previos posts is the last line.
+
+------------------------
+invalid/unsupported opcode: 1f - 12 - 05 (7d200164) 005a6ae0 0
+------------------------
+
+Thanks.
+
+On 732c66ce641c69702a7e7fdb73b68f0c1b583ab5, I instead get:
+
+
+Welcome to OpenBIOS v1.1 built on Oct 2 2013 22:57
+Trying cd:,\\:tbxi...
+Consoles: Open Firmware console  
+
+FreeBSD/powerpc Open Firmware loader, Revision 0.1
+(<email address hidden>, Sun Jul 18 04:50:11 UTC 2010)
+Memory: 96256KB
+Booted from: /pci@80000000/mac-io@3/ata-2@21000/cdrom@0
+
+panic: free: guard1 fail @ 0x5d80418 from /usr/src/sys/boot/powerpc/ofw/../../common/interp_parse.c:184
+--> Press a key on the console to reboot <--
+
+
+Latest version from git, using FreeBSD10.0:
+
+qemu-system-ppc64 -cdrom FreeBSD-10.0-RELEASE-powerpc-disc1.iso -hda freebsd10.0-ppc -m 256 -boot d -k en-us:
+
+
+
+SLOF **********************************************************************
+QEMU Starting
+ Build Date = Mar 13 2015 22:37:28
+ FW Version = git-c89b0df661c0a6bf
+ Press "s" to enter Open Firmware.
+
+Populating /vdevice methods
+Populating /vdevice/vty@71000000
+Populating /vdevice/nvram@71000001
+Populating /vdevice/l-lan@71000002
+Populating /vdevice/v-scsi@71000003
+       SCSI: Looking for devices
+          8000000000000000 DISK     : "QEMU     QEMU HARDDISK    2.3."
+          8200000000000000 CD-ROM   : "QEMU     QEMU CD-ROM      2.3."
+Populating /pci@800000020000000
+ Adapters on 0800000020000000
+                     00 0000 (D) : 1234 1111    qemu vga
+                     00 0800 (D) : 106b 003f    serial bus [ usb-ohci ]
+No NVRAM common partition, re-initializing...
+Installing QEMU fb
+
+
+
+Scanning USB 
+  OHCI: initializing
+    USB Keyboard 
+    USB mouse 
+No console specified using screen & keyboard
+     
+
+
+  Welcome to Open Firmware
+
+  Copyright (c) 2004, 2011 IBM Corporation All rights reserved.
+  This program and the accompanying materials are made available
+  under the terms of the BSD License available at
+  http://www.opensource.org/licenses/bsd-license.php
+
+
+Trying to load:  from: cdrom ...   Successfully loaded
+Trying to write invalid spr 540 (0x21c) at 0000000000731954
+ 
+
+( 700 ) Program Exception [ 7319dc ]
+
+
+    R0 .. R7           R8 .. R15         R16 .. R23         R24 .. R31
+0000000000000000   0000000000000000   0000000000000000   000000000048099c   
+00000000009d9e50   0000000000000000   0000000000000000   00000000009d9ef4   
+0000000000a5e160   000000000000bf30   0000000000000000   00000000007319dc   
+00000000009d9f2c   0000000000000000   0000000000000000   000000000048099c   
+000000000048099c   0000000000000000   0000000000c0a000   0000000000000000   
+00000000007319dc   0000000000000000   0000000000000004   0000000000000000   
+000000000048099c   0000000000000000   0000000000000000   0000000000002000   
+00000000009d9ef4   0000000000000000   0000000000000000   00000000009d9e50   
+
+    CR / XER           LR / CTR          SRR0 / SRR1        DAR / DSISR
+        84000022   0000000000731a14   0000000000731954   0000000000000000   
+0000000000000000   00000000007319dc   0000000000082000           00000000  
+
+I used the -nographic option as well, but lost it in the copy and paste.
+
+Nigel, looking at https://www.freebsd.org/platforms/ppc.html it seems like FreeBSD does not support the pseries machines yet, only some flavours of PowerMac machines. So you should either use the "qemu-system-ppc" binary (without the "64" suffix), or you've got to specify one of the Mac machines, i.e. either "-M g3beige" or "-M mac99".
+
+Hi, Nigel.
+
+Support for powerpc64 is available since FreeBSD 9.0-RELEASE, I think.
+FreeBSD 11.2-RC2 boots fine in QEMU (at commit 46012db666990ff2eed1d3dc)
+running on an x86 host with accel=tcg.  Below are the steps I have
+followed to boot it.
+
+Build QEMU:
+
+$ mkdir build && cd build
+$ ../configure --target-list=ppc64-softmmu
+$ make -j$(nproc)
+
+Boot FreeBSD:
+
+$ wget http://ftp.freebsd.org/pub/FreeBSD/releases/powerpc/powerpc64/ISO-IMAGES/11.2/FreeBSD-11.2-RC2-powerpc-powerpc64-disc1.iso
+$ ./qemu-img create -f qcow2 freebsd.qcow2 10G
+$ ./ppc64-softmmu/qemu-system-ppc64 -name freebsd -machine pseries,accel=tcg,usb=off -m 1024 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -nographic -no-user-config -nodefaults -rtc base=utc -no-shutdown -boot strict=on -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x1 -device pci-ohci,id=usb,bus=pci.0,addr=0x2 -device spapr-vscsi,id=scsi0,reg=0x2000 -drive file=freebsd.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=FreeBSD-11.2-RC2-powerpc-powerpc64-disc1.iso,format=raw,if=none,id=drive-scsi0-0-1-0,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0,bootindex=2 -netdev user,id=hostnet0 -device spapr-vlan,netdev=hostnet0,id=net0,mac=4c:45:42:45:01:18,reg=0x1000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on -serial mon:stdio
+
+Since this bug is almost 8 years old and FreeBSD powerpc64 seems to be
+working just fine, I will close it.  Feel free to submit a new one if
+needed.
+
+Cheers
+Murilo
+
diff --git a/results/classifier/118/device/628082 b/results/classifier/118/device/628082
new file mode 100644
index 00000000..ddff46e7
--- /dev/null
+++ b/results/classifier/118/device/628082
@@ -0,0 +1,46 @@
+device: 0.820
+architecture: 0.727
+graphic: 0.686
+network: 0.655
+mistranslation: 0.602
+kernel: 0.592
+debug: 0.577
+socket: 0.554
+virtual: 0.538
+hypervisor: 0.529
+permissions: 0.523
+register: 0.511
+vnc: 0.486
+semantic: 0.443
+ppc: 0.440
+peripherals: 0.438
+x86: 0.423
+arm: 0.406
+files: 0.393
+PID: 0.377
+i386: 0.377
+VMM: 0.355
+assembly: 0.320
+boot: 0.317
+TCG: 0.309
+performance: 0.307
+user-level: 0.263
+risc-v: 0.240
+KVM: 0.203
+
+nl-be keymap is wrong
+
+As mentioned on https://bugs.launchpad.net/ubuntu/+source/kvm/+bug/429965 as well as the kvm mailinglist (http://thread.gmane.org/gmane.comp.emulators.kvm.devel/14413), the nl-be keymap does not work. The number keys above the regular keys (non-numeric keypad numbers) as well as vital keys such as slash, backslash, dash, ... are not working.
+
+The nl-be keymap that is presented in the above URLs (and also attached to this bug) does work properly.
+
+Would it be possible to include this keymap rather than the current one?
+
+
+
+Hi, is this still a problem with the latest version of QEMU? If yes, please submit your keymap as a patch to the qemu-devel mailing list (see http://qemu-project.org/Contribute/SubmitAPatch for details). Thanks!
+
+There have been quite a lot of changes with regards to keyboard mapping in QEMU recently, could you please try again with QEMU 2.12 to see whether this has been fixed now?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/63 b/results/classifier/118/device/63
new file mode 100644
index 00000000..7856c27b
--- /dev/null
+++ b/results/classifier/118/device/63
@@ -0,0 +1,31 @@
+device: 0.948
+performance: 0.870
+peripherals: 0.673
+architecture: 0.598
+graphic: 0.528
+network: 0.464
+debug: 0.300
+assembly: 0.293
+socket: 0.208
+arm: 0.194
+register: 0.147
+PID: 0.131
+semantic: 0.125
+hypervisor: 0.096
+TCG: 0.084
+risc-v: 0.070
+permissions: 0.065
+VMM: 0.063
+ppc: 0.061
+virtual: 0.059
+boot: 0.056
+files: 0.040
+mistranslation: 0.030
+vnc: 0.026
+user-level: 0.025
+kernel: 0.013
+KVM: 0.007
+i386: 0.004
+x86: 0.003
+
+Illegal delay slot code causes abort on mips64
diff --git a/results/classifier/118/device/635 b/results/classifier/118/device/635
new file mode 100644
index 00000000..7b2322c2
--- /dev/null
+++ b/results/classifier/118/device/635
@@ -0,0 +1,58 @@
+device: 0.830
+kernel: 0.826
+ppc: 0.790
+graphic: 0.716
+PID: 0.711
+performance: 0.700
+socket: 0.601
+semantic: 0.531
+debug: 0.510
+arm: 0.510
+user-level: 0.509
+register: 0.497
+risc-v: 0.470
+architecture: 0.455
+vnc: 0.430
+mistranslation: 0.415
+VMM: 0.383
+i386: 0.363
+boot: 0.361
+hypervisor: 0.341
+peripherals: 0.333
+TCG: 0.328
+permissions: 0.292
+network: 0.282
+virtual: 0.273
+files: 0.256
+x86: 0.225
+KVM: 0.155
+assembly: 0.153
+
+HPPA Error on Raspberry PI - deposit64: Assertion `start >= 0 && length > 0 && length <= 64 - start' failed
+Description of problem:
+The emulator starts normally but during the Guest OS installation (HP-UX 10.20) it crash with below error:
+(qemu) qemu-system-hppa: /root/qemu/include/qemu/bitops.h:496: deposit64: Assertion `start >= 0 && length > 0 && length <= 64 - start' failed.
+Steps to reproduce:
+1. Run qemu-system-hppa with the command listed above
+2. Start HP-UX 10.20 installation and finish the install wizard
+Additional information:
+It crashes after the installation step bolow:
+
+Executing user specified script:
+=========================================
+
+  [[ ! -a /dev/lan0 ]] && mknod /dev/lan0 c 52 0x000000
+
+=========================================
+       * Will use the cold-install media for swinstall as well.
+       * Starting swinstall:
+WARNING: The software specified contains a kernel fileset.  It will be
+         necessary to reconfigure and reboot the system to make the
+         kernel software functional.
+
+       * Beginning Analysis Phase.
+       * Source:           localhost:/SD_CDROM
+       * Target:           loopback:/
+       * Target logfile:   loopback:/var/adm/sw/swagent.log
+       * Reading source for product information.
+       * Reading source for file information.
diff --git a/results/classifier/118/device/63565653 b/results/classifier/118/device/63565653
new file mode 100644
index 00000000..94f98a2d
--- /dev/null
+++ b/results/classifier/118/device/63565653
@@ -0,0 +1,74 @@
+device: 0.889
+boot: 0.889
+PID: 0.887
+architecture: 0.864
+network: 0.861
+debug: 0.855
+ppc: 0.855
+performance: 0.834
+KVM: 0.827
+semantic: 0.825
+peripherals: 0.824
+i386: 0.792
+virtual: 0.787
+x86: 0.765
+register: 0.755
+kernel: 0.746
+socket: 0.745
+permissions: 0.739
+arm: 0.737
+graphic: 0.734
+files: 0.705
+VMM: 0.695
+risc-v: 0.657
+hypervisor: 0.624
+user-level: 0.607
+vnc: 0.588
+assembly: 0.571
+TCG: 0.567
+mistranslation: 0.462
+
+[Qemu-devel] [BUG]pcibus_reset assertion failure on guest reboot
+
+Qemu-2.6.2
+
+Start a vm with vhost-net , do reboot and hot-unplug viritio-net nic in short 
+time, we touch 
+pcibus_reset assertion failure.
+
+Here is qemu log:
+22:29:46.359386+08:00  acpi_pm1_cnt_write -> guest do soft power off
+22:29:46.785310+08:00  qemu_devices_reset
+22:29:46.788093+08:00  virtio_pci_device_unplugged -> virtio net unpluged
+22:29:46.803427+08:00  pcibus_reset: Assertion `bus->irq_count[i] == 0' failed.
+
+Here is stack info: 
+(gdb) bt
+#0  0x00007f9a336795d7 in raise () from /usr/lib64/libc.so.6
+#1  0x00007f9a3367acc8 in abort () from /usr/lib64/libc.so.6
+#2  0x00007f9a33672546 in __assert_fail_base () from /usr/lib64/libc.so.6
+#3  0x00007f9a336725f2 in __assert_fail () from /usr/lib64/libc.so.6
+#4  0x0000000000641884 in pcibus_reset (qbus=0x29eee60) at hw/pci/pci.c:283
+#5  0x00000000005bfc30 in qbus_reset_one (bus=0x29eee60, opaque=<optimized 
+out>) at hw/core/qdev.c:319
+#6  0x00000000005c1b19 in qdev_walk_children (dev=0x29ed2b0, pre_devfn=0x0, 
+pre_busfn=0x0, post_devfn=0x5c2440 ...
+#7  0x00000000005c1c59 in qbus_walk_children (bus=0x2736f80, pre_devfn=0x0, 
+pre_busfn=0x0, post_devfn=0x5c2440 ...
+#8  0x00000000005513f5 in qemu_devices_reset () at vl.c:1998
+#9  0x00000000004cab9d in pc_machine_reset () at 
+/home/abuild/rpmbuild/BUILD/qemu-kvm-2.6.0/hw/i386/pc.c:1976
+#10 0x000000000055148b in qemu_system_reset (address@hidden) at vl.c:2011
+#11 0x000000000055164f in main_loop_should_exit () at vl.c:2169
+#12 0x0000000000551719 in main_loop () at vl.c:2212
+#13 0x000000000041c9a8 in main (argc=<optimized out>, argv=<optimized out>, 
+envp=<optimized out>) at vl.c:5130
+(gdb) f 4
+...
+(gdb) p bus->irq_count[0]
+$6 = 1
+
+Seems pci_update_irq_disabled doesn't work well
+
+can anyone help?
+
diff --git a/results/classifier/118/device/637 b/results/classifier/118/device/637
new file mode 100644
index 00000000..0fdde3d6
--- /dev/null
+++ b/results/classifier/118/device/637
@@ -0,0 +1,34 @@
+device: 0.847
+mistranslation: 0.725
+semantic: 0.662
+vnc: 0.557
+ppc: 0.548
+network: 0.547
+graphic: 0.539
+files: 0.527
+PID: 0.511
+register: 0.444
+architecture: 0.405
+boot: 0.402
+arm: 0.387
+performance: 0.318
+socket: 0.304
+virtual: 0.260
+VMM: 0.190
+risc-v: 0.165
+debug: 0.146
+x86: 0.143
+TCG: 0.136
+i386: 0.133
+kernel: 0.101
+permissions: 0.083
+hypervisor: 0.081
+peripherals: 0.067
+assembly: 0.043
+user-level: 0.005
+KVM: 0.003
+
+qemu drive-mirror live migration sparse copy
+Additional information:
+Please reference this Proxmox post where the developers mention this feature not being available:
+https://forum.proxmox.com/threads/migration-on-lvm-thin.50429/
diff --git a/results/classifier/118/device/64 b/results/classifier/118/device/64
new file mode 100644
index 00000000..f90c5d8e
--- /dev/null
+++ b/results/classifier/118/device/64
@@ -0,0 +1,31 @@
+device: 0.822
+performance: 0.748
+graphic: 0.502
+architecture: 0.486
+peripherals: 0.388
+files: 0.360
+mistranslation: 0.342
+hypervisor: 0.342
+semantic: 0.316
+network: 0.305
+permissions: 0.241
+TCG: 0.202
+vnc: 0.201
+user-level: 0.198
+debug: 0.195
+register: 0.193
+PID: 0.192
+virtual: 0.184
+ppc: 0.176
+VMM: 0.169
+arm: 0.150
+boot: 0.120
+x86: 0.097
+kernel: 0.087
+risc-v: 0.084
+assembly: 0.077
+KVM: 0.065
+i386: 0.045
+socket: 0.029
+
+raspi3 machine can not shutdown
diff --git a/results/classifier/118/device/644 b/results/classifier/118/device/644
new file mode 100644
index 00000000..1ac93a88
--- /dev/null
+++ b/results/classifier/118/device/644
@@ -0,0 +1,39 @@
+device: 0.849
+mistranslation: 0.731
+files: 0.722
+architecture: 0.717
+graphic: 0.587
+virtual: 0.546
+kernel: 0.539
+ppc: 0.446
+performance: 0.373
+boot: 0.341
+vnc: 0.326
+semantic: 0.314
+register: 0.285
+debug: 0.284
+VMM: 0.264
+peripherals: 0.253
+network: 0.210
+risc-v: 0.206
+permissions: 0.154
+i386: 0.107
+user-level: 0.106
+TCG: 0.100
+assembly: 0.077
+hypervisor: 0.077
+arm: 0.071
+socket: 0.063
+PID: 0.062
+x86: 0.042
+KVM: 0.004
+
+generic loader does not do virtual to physical address translation when loading MIPS ELF
+Description of problem:
+
+Steps to reproduce:
+1.build two ELFs, whose virtual address is at kseg0<p>
+2.load one ELF with generic loader "-device loader,file=test1.elf", the other ELF with "-kernel test2.elf"<p>
+3.generic loader loads test1.elf without doing address translation, while mipssim load_kernel will do that with cpu_mips_kseg0_to_phys<p>
+Additional information:
+generic_loader_realize calls load_elf_as with the argument translate_fn=NULL. Maybe, we can set translate_fn when elf_machine is EM_MIPS.
diff --git a/results/classifier/118/device/646 b/results/classifier/118/device/646
new file mode 100644
index 00000000..367bfd58
--- /dev/null
+++ b/results/classifier/118/device/646
@@ -0,0 +1,48 @@
+device: 0.832
+files: 0.826
+architecture: 0.742
+permissions: 0.727
+graphic: 0.723
+ppc: 0.722
+network: 0.717
+socket: 0.713
+vnc: 0.701
+PID: 0.680
+risc-v: 0.634
+VMM: 0.577
+register: 0.564
+boot: 0.543
+semantic: 0.541
+peripherals: 0.539
+TCG: 0.514
+debug: 0.507
+kernel: 0.506
+x86: 0.495
+arm: 0.486
+i386: 0.458
+performance: 0.449
+hypervisor: 0.440
+KVM: 0.334
+virtual: 0.312
+assembly: 0.243
+user-level: 0.237
+mistranslation: 0.230
+
+Infinite loop in xhci_ring_chain_length() in hw/usb/hcd-xhci.c (CVE-2020-14394)
+Description of problem:
+An infinite loop issue was found in the USB xHCI controller emulation of QEMU. Specifically, function `xhci_ring_chain_length()` in hw/usb/hcd-xhci.c may get stuck while fetching empty TRBs from guest memory, since the exit conditions of the loop depend on values that are fully controlled by guest. A privileged guest user may exploit this issue to hang the QEMU process on the host, resulting in a denial of service.
+Steps to reproduce:
+Build and load `xhci.ko` from within the guest:
+
+1) make
+2) insmod xhci.ko
+
+[Makefile](/uploads/98dbf7b4facc9b100817b3c8f63b5cb2/Makefile)
+
+[usb-xhci.h](/uploads/f225524b1553d8cf6c1dfa89369b6edc/usb-xhci.h)
+
+[xhci.c](/uploads/c635f742d12a2bba6ea472ddfe006d56/xhci.c)
+Additional information:
+This issue was reported by Gaoning Pan (Zhejiang University) and Xingwei Li (Ant Security Light-Year Lab).
+
+RH bug: https://bugzilla.redhat.com/show_bug.cgi?id=1908004.
diff --git a/results/classifier/118/device/648 b/results/classifier/118/device/648
new file mode 100644
index 00000000..7c981cec
--- /dev/null
+++ b/results/classifier/118/device/648
@@ -0,0 +1,31 @@
+device: 0.877
+vnc: 0.703
+network: 0.700
+mistranslation: 0.664
+architecture: 0.611
+arm: 0.571
+virtual: 0.530
+socket: 0.472
+debug: 0.454
+ppc: 0.431
+VMM: 0.394
+TCG: 0.339
+performance: 0.333
+graphic: 0.299
+i386: 0.281
+files: 0.247
+PID: 0.237
+boot: 0.230
+register: 0.226
+risc-v: 0.223
+x86: 0.212
+peripherals: 0.163
+kernel: 0.117
+semantic: 0.092
+assembly: 0.049
+user-level: 0.031
+hypervisor: 0.029
+KVM: 0.027
+permissions: 0.024
+
+util/vfio-helpers: misaligned address for struct vfio_iova_range, which requires 8 byte alignment
diff --git a/results/classifier/118/device/650 b/results/classifier/118/device/650
new file mode 100644
index 00000000..17747978
--- /dev/null
+++ b/results/classifier/118/device/650
@@ -0,0 +1,54 @@
+device: 0.828
+performance: 0.733
+graphic: 0.706
+hypervisor: 0.705
+peripherals: 0.690
+PID: 0.636
+socket: 0.629
+kernel: 0.609
+architecture: 0.606
+network: 0.580
+ppc: 0.557
+user-level: 0.532
+vnc: 0.529
+VMM: 0.510
+x86: 0.508
+permissions: 0.459
+semantic: 0.444
+arm: 0.443
+risc-v: 0.436
+i386: 0.411
+debug: 0.365
+register: 0.346
+files: 0.318
+boot: 0.308
+virtual: 0.301
+TCG: 0.277
+mistranslation: 0.263
+KVM: 0.221
+assembly: 0.148
+
+Monitor device_add triggers deadlock when calling drain_call_rcu on QEMU >= 6.0.0
+Description of problem:
+It hangs
+Steps to reproduce:
+1. Run the QEMU:
+   ```
+   ./qemu-system-mips64 -nographic
+   ```
+2. Enter into the QEMU monitor: press ctrl-a c
+3. Execute command `device_add` without arguments:
+```
+(qemu) device_add
+```
+4. It hangs so bad that only `kill -9` helps
+Additional information:
+I didn't test versions between 4.2.0 and 6.0.0, but I can confirm that 6.0.0, 6.1.0 and the latest master pull have this bug, while version 4.2.0 doesn't have it.
+
+I've tracked the problem and found this.
+
+1. Command `device_add` calls function `drain_call_rcu`. `drain_call_rcu` waits indefinitely for drain_complete_event.
+2. Function `cpu_exec` in accel/tcg/cpu-exec.c calls `rcu_read_lock` but does not call `rcu_read_unlock()`. `cpu_exec` just spins in its inner loop.
+3. Function `call_rcu_thread` hanged in calling the `synchronize_rcu` which calls `wait_for_readers`.
+
+If I execute `stop` command in QEMU monitor before calling `device_add` command, no hang happen.
diff --git a/results/classifier/118/device/66 b/results/classifier/118/device/66
new file mode 100644
index 00000000..8bb8a8a7
--- /dev/null
+++ b/results/classifier/118/device/66
@@ -0,0 +1,31 @@
+device: 0.873
+files: 0.819
+performance: 0.667
+semantic: 0.663
+network: 0.650
+graphic: 0.601
+mistranslation: 0.573
+boot: 0.511
+register: 0.495
+architecture: 0.396
+assembly: 0.335
+debug: 0.286
+vnc: 0.275
+risc-v: 0.267
+arm: 0.220
+kernel: 0.208
+peripherals: 0.160
+permissions: 0.159
+hypervisor: 0.158
+TCG: 0.158
+virtual: 0.156
+user-level: 0.155
+VMM: 0.136
+ppc: 0.136
+socket: 0.120
+i386: 0.119
+PID: 0.115
+x86: 0.087
+KVM: 0.084
+
+-hda FAT:. limited to 504MBytes
diff --git a/results/classifier/118/device/663 b/results/classifier/118/device/663
new file mode 100644
index 00000000..52c787e8
--- /dev/null
+++ b/results/classifier/118/device/663
@@ -0,0 +1,41 @@
+i386: 0.971
+device: 0.927
+graphic: 0.842
+files: 0.830
+peripherals: 0.814
+socket: 0.811
+architecture: 0.768
+register: 0.687
+debug: 0.660
+vnc: 0.657
+network: 0.576
+PID: 0.477
+permissions: 0.452
+boot: 0.443
+arm: 0.432
+semantic: 0.427
+ppc: 0.391
+VMM: 0.380
+hypervisor: 0.367
+risc-v: 0.358
+performance: 0.348
+mistranslation: 0.269
+kernel: 0.252
+virtual: 0.221
+TCG: 0.177
+assembly: 0.132
+x86: 0.109
+user-level: 0.097
+KVM: 0.019
+
+Assertion `r->req.aiocb == NULL' in am53c974 emulator
+Description of problem:
+
+Steps to reproduce:
+```
+1../configure --target-list=i386-softmmu --disable-werror --enable-sanitizers
+2.make -j12
+3.qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img
+```
+Additional information:
+#
diff --git a/results/classifier/118/device/666 b/results/classifier/118/device/666
new file mode 100644
index 00000000..e15ca6e8
--- /dev/null
+++ b/results/classifier/118/device/666
@@ -0,0 +1,37 @@
+device: 0.814
+network: 0.719
+mistranslation: 0.665
+kernel: 0.575
+PID: 0.528
+graphic: 0.508
+virtual: 0.434
+semantic: 0.398
+socket: 0.388
+register: 0.388
+VMM: 0.368
+architecture: 0.345
+arm: 0.340
+files: 0.332
+ppc: 0.325
+vnc: 0.306
+permissions: 0.303
+boot: 0.260
+user-level: 0.244
+performance: 0.225
+debug: 0.220
+TCG: 0.209
+peripherals: 0.183
+i386: 0.157
+risc-v: 0.133
+KVM: 0.112
+x86: 0.101
+hypervisor: 0.073
+assembly: 0.041
+
+ivshmem-plain cannot be used on non-Linux hosts
+Additional information:
+I would like to propose this patch as-is on the mailing list (the trivial one?) as soon as I figure patch submission out fully:
+
+https://github.com/fredldotme/qemu/commit/e929b8db8078aede6df7b02d8c0b71d1e2d6afcb
+
+It's just `#ifdef`ing out doorbell support on non-Linux builds which seems to be enough for basic functionality.
diff --git a/results/classifier/118/device/667 b/results/classifier/118/device/667
new file mode 100644
index 00000000..9f8c3e3e
--- /dev/null
+++ b/results/classifier/118/device/667
@@ -0,0 +1,31 @@
+device: 0.983
+performance: 0.776
+ppc: 0.487
+graphic: 0.402
+semantic: 0.384
+files: 0.354
+user-level: 0.353
+permissions: 0.308
+peripherals: 0.243
+boot: 0.229
+mistranslation: 0.219
+architecture: 0.195
+virtual: 0.185
+assembly: 0.164
+register: 0.160
+debug: 0.156
+network: 0.149
+risc-v: 0.092
+vnc: 0.082
+i386: 0.080
+PID: 0.076
+VMM: 0.023
+kernel: 0.022
+arm: 0.022
+TCG: 0.007
+x86: 0.006
+hypervisor: 0.005
+socket: 0.003
+KVM: 0.002
+
+Wacom EMR pen pressure support
diff --git a/results/classifier/118/device/667791 b/results/classifier/118/device/667791
new file mode 100644
index 00000000..af346bea
--- /dev/null
+++ b/results/classifier/118/device/667791
@@ -0,0 +1,74 @@
+device: 0.868
+vnc: 0.862
+architecture: 0.819
+permissions: 0.816
+peripherals: 0.806
+network: 0.801
+ppc: 0.795
+socket: 0.764
+performance: 0.762
+kernel: 0.759
+mistranslation: 0.742
+files: 0.728
+boot: 0.704
+i386: 0.703
+semantic: 0.703
+VMM: 0.694
+KVM: 0.668
+arm: 0.666
+hypervisor: 0.663
+risc-v: 0.661
+register: 0.640
+PID: 0.638
+TCG: 0.604
+graphic: 0.594
+user-level: 0.560
+x86: 0.505
+debug: 0.445
+virtual: 0.355
+assembly: 0.307
+
+Cygwin build fails due to ui/vnc-etc-tight.c
+
+Configure:
+./configure \
+--prefix="./install/bin/" \
+--interp-prefix="./install/bin-%M/" \
+--cc="gcc -mno-cygwin" \
+--host-cc="gcc" \
+--disable-sdl \
+--enable-system \
+--disable-user \
+--disable-linux-user \
+--disable-darwin-user \
+--disable-bsd-user \
+--disable-xen \
+--disable-brlapi \
+--disable-vnc-tls \
+--disable-vnc-sasl \
+--disable-vnc-jpeg \
+--disable-vnc-png \
+--disable-vnc-thread \
+--disable-curses \
+--disable-curl \
+--disable-bluez \
+--disable-kvm \
+--disable-nptl \
+--disable-vde \
+--disable-vhost-net
+
+Versions of software
+Cygwin 1.7
+GNU Make 3.81
+GCC 3.4.4 (/usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a)
+QEMU 0.13.0
+
+Result:
+Function tight_detect_smooth_image24(...) uses "uint" type, that appears to be not defined in this scope. Prepending this function with
+typedef unsigned int uint;
+fixes build.
+
+Seems like this problem has been fixed here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=249cdb420a3b68cf6
+... so we can close this bug ticket now.
+
diff --git a/results/classifier/118/device/678 b/results/classifier/118/device/678
new file mode 100644
index 00000000..c02f8118
--- /dev/null
+++ b/results/classifier/118/device/678
@@ -0,0 +1,77 @@
+device: 0.972
+socket: 0.928
+performance: 0.924
+vnc: 0.883
+VMM: 0.874
+peripherals: 0.872
+boot: 0.857
+kernel: 0.851
+network: 0.847
+PID: 0.842
+ppc: 0.838
+TCG: 0.817
+risc-v: 0.813
+KVM: 0.803
+debug: 0.792
+hypervisor: 0.771
+graphic: 0.760
+register: 0.751
+files: 0.720
+permissions: 0.713
+arm: 0.685
+architecture: 0.677
+x86: 0.668
+user-level: 0.660
+semantic: 0.623
+i386: 0.599
+mistranslation: 0.569
+virtual: 0.539
+assembly: 0.524
+
+eject (monitor command) not work for blockdev cdrom
+Description of problem:
+cdrom1 device work fine, all files reads, but when i whant to eject CD-ROM disk from device by telnet monitor, it not work.
+Steps to reproduce:
+1. Connect to monitor with
+```
+telnet 127.0.0.1 9100
+(QEMU 5.2.0 monitor - type 'help' for more information)
+```
+
+2. Show block devices
+```
+info block
+cdrom1-format: /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only)
+    Attached to:      cdrom1
+    Removable device: not locked, tray closed
+    Cache mode:       writeback
+```
+
+3. Send eject commands
+```
+eject cdrom1
+Error: Device 'cdrom1' not found
+eject cdrom1-format
+Error: Device 'cdrom1-format' not found
+eject cdrom1-storage
+Error: Device 'cdrom1-storage' not found
+```
+Additional information:
+When i run qemu with next lines (replace -blockdev to -drive):
+```
+-device ide-cd,bus=ide.1,drive=cdrom1,id=idecd1,bootindex=2
+-drive if=none,id=cdrom1,media=cdrom,readonly=on,file="/mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso"
+```
+
+eject cdrom1 command work fine
+
+```
+info block
+cdrom1 (#block133): /mnt/soft/QEMU/Windows VirtIO Drivers/virtio-win-0.1.208-1.iso (raw, read-only)
+    Attached to:      idecd1
+    Removable device: not locked, tray closed
+    Cache mode:       writeback
+eject cdrom1
+```
+
+Also i found a similar bug description on this link https://bugs.launchpad.net/qemu/+bug/1799766
diff --git a/results/classifier/118/device/68 b/results/classifier/118/device/68
new file mode 100644
index 00000000..701ce4df
--- /dev/null
+++ b/results/classifier/118/device/68
@@ -0,0 +1,31 @@
+device: 0.978
+architecture: 0.850
+performance: 0.614
+graphic: 0.495
+mistranslation: 0.465
+semantic: 0.440
+permissions: 0.438
+register: 0.397
+user-level: 0.357
+hypervisor: 0.330
+ppc: 0.310
+debug: 0.260
+virtual: 0.221
+boot: 0.208
+arm: 0.190
+risc-v: 0.125
+assembly: 0.116
+TCG: 0.090
+PID: 0.086
+network: 0.075
+peripherals: 0.073
+vnc: 0.038
+VMM: 0.032
+files: 0.025
+i386: 0.019
+socket: 0.013
+x86: 0.006
+kernel: 0.005
+KVM: 0.001
+
+Solaris can't be powered off with ACPI shutdown/poweroff
diff --git a/results/classifier/118/device/684 b/results/classifier/118/device/684
new file mode 100644
index 00000000..1083fab1
--- /dev/null
+++ b/results/classifier/118/device/684
@@ -0,0 +1,31 @@
+device: 0.821
+performance: 0.704
+network: 0.608
+architecture: 0.595
+graphic: 0.537
+arm: 0.468
+register: 0.465
+hypervisor: 0.417
+mistranslation: 0.385
+ppc: 0.361
+debug: 0.359
+risc-v: 0.334
+boot: 0.301
+kernel: 0.289
+semantic: 0.266
+VMM: 0.229
+files: 0.173
+vnc: 0.163
+permissions: 0.119
+TCG: 0.114
+user-level: 0.104
+socket: 0.071
+assembly: 0.069
+peripherals: 0.062
+PID: 0.046
+virtual: 0.044
+KVM: 0.023
+i386: 0.014
+x86: 0.012
+
+xHCI Port Status Change Event at port powered
diff --git a/results/classifier/118/device/69 b/results/classifier/118/device/69
new file mode 100644
index 00000000..be3b9d77
--- /dev/null
+++ b/results/classifier/118/device/69
@@ -0,0 +1,31 @@
+device: 0.902
+performance: 0.880
+arm: 0.691
+network: 0.602
+graphic: 0.385
+register: 0.277
+debug: 0.269
+architecture: 0.246
+boot: 0.233
+hypervisor: 0.186
+semantic: 0.157
+ppc: 0.121
+user-level: 0.096
+risc-v: 0.094
+files: 0.083
+permissions: 0.079
+vnc: 0.073
+mistranslation: 0.064
+virtual: 0.063
+socket: 0.047
+assembly: 0.040
+i386: 0.039
+peripherals: 0.020
+kernel: 0.009
+PID: 0.008
+VMM: 0.006
+TCG: 0.004
+x86: 0.004
+KVM: 0.001
+
+ALSA underruns occurr when using QEMU
diff --git a/results/classifier/118/device/699 b/results/classifier/118/device/699
new file mode 100644
index 00000000..2d77e232
--- /dev/null
+++ b/results/classifier/118/device/699
@@ -0,0 +1,31 @@
+device: 0.889
+architecture: 0.799
+performance: 0.743
+hypervisor: 0.579
+virtual: 0.538
+network: 0.528
+graphic: 0.507
+permissions: 0.359
+user-level: 0.328
+register: 0.326
+boot: 0.321
+semantic: 0.320
+arm: 0.303
+assembly: 0.286
+files: 0.263
+peripherals: 0.247
+mistranslation: 0.234
+debug: 0.205
+socket: 0.192
+vnc: 0.142
+risc-v: 0.140
+ppc: 0.105
+i386: 0.067
+PID: 0.039
+x86: 0.038
+VMM: 0.030
+kernel: 0.024
+TCG: 0.018
+KVM: 0.003
+
+SGX QEMU release
diff --git a/results/classifier/118/device/700 b/results/classifier/118/device/700
new file mode 100644
index 00000000..c4406558
--- /dev/null
+++ b/results/classifier/118/device/700
@@ -0,0 +1,31 @@
+device: 0.916
+performance: 0.910
+graphic: 0.651
+risc-v: 0.506
+arm: 0.504
+architecture: 0.492
+boot: 0.449
+register: 0.431
+semantic: 0.389
+permissions: 0.352
+files: 0.349
+i386: 0.328
+user-level: 0.315
+vnc: 0.288
+ppc: 0.273
+virtual: 0.265
+kernel: 0.233
+mistranslation: 0.216
+socket: 0.209
+debug: 0.183
+VMM: 0.149
+x86: 0.144
+network: 0.098
+PID: 0.089
+hypervisor: 0.082
+assembly: 0.067
+TCG: 0.028
+peripherals: 0.020
+KVM: 0.003
+
+GTK display refresh rate is throttled
diff --git a/results/classifier/118/device/71 b/results/classifier/118/device/71
new file mode 100644
index 00000000..f019d308
--- /dev/null
+++ b/results/classifier/118/device/71
@@ -0,0 +1,31 @@
+architecture: 0.991
+device: 0.936
+performance: 0.856
+arm: 0.770
+network: 0.579
+assembly: 0.578
+risc-v: 0.576
+graphic: 0.556
+hypervisor: 0.503
+PID: 0.500
+boot: 0.487
+kernel: 0.479
+permissions: 0.468
+vnc: 0.445
+register: 0.424
+virtual: 0.419
+debug: 0.405
+VMM: 0.368
+semantic: 0.358
+files: 0.348
+TCG: 0.333
+ppc: 0.256
+user-level: 0.249
+mistranslation: 0.222
+socket: 0.195
+peripherals: 0.152
+x86: 0.141
+KVM: 0.136
+i386: 0.035
+
+AC97 can allocate ~500MB of host RAM
diff --git a/results/classifier/118/device/723460 b/results/classifier/118/device/723460
new file mode 100644
index 00000000..ef1e6b3a
--- /dev/null
+++ b/results/classifier/118/device/723460
@@ -0,0 +1,85 @@
+user-level: 0.948
+device: 0.933
+mistranslation: 0.919
+virtual: 0.889
+boot: 0.820
+performance: 0.808
+permissions: 0.798
+semantic: 0.796
+register: 0.794
+files: 0.787
+PID: 0.782
+graphic: 0.781
+architecture: 0.761
+peripherals: 0.759
+socket: 0.749
+x86: 0.747
+network: 0.678
+VMM: 0.675
+ppc: 0.675
+risc-v: 0.660
+hypervisor: 0.641
+vnc: 0.616
+arm: 0.611
+i386: 0.607
+TCG: 0.580
+KVM: 0.565
+assembly: 0.558
+debug: 0.522
+kernel: 0.519
+
+qemu on linux doesn't boot for winxp install via usb
+
+hi guys,
+I try to install windows xp via qemu. I can only boot from usb and somehow it is my problem.
+I run a Winxp/xubuntu10.04 Dualboot-system with some virtual drives in windows ( till letter f:? ).
+at qemu I created an image from 30Gigabytes and entered this command from the imagefile's directory :
+
+"sudo qemu-system-x86_64 -localtime -usbdevice -hda /dev/sdb -m 384 -boot d winxp.img"
+
+the answer is :
+
+"qemu-system-x86_64: -boot d: drive with bus=0, unit=0 (index=0) exists"
+
+I had to set the usb-stick in the fstab file with this command :
+
+"UUID=X	/media/usb	vfat	rw,users,noauto,umask=000	0	0"
+
+anybody experienced the same problem?
+
+I would appreciate any kind of help
+
+greetz
+
+On Tue, Feb 22, 2011 at 11:49 PM, dankoe <email address hidden> wrote:
+> Public bug reported:
+>
+> hi guys,
+> I try to install windows xp via qemu. I can only boot from usb and somehow it is my problem.
+> I run a Winxp/xubuntu10.04 Dualboot-system with some virtual drives in windows ( till letter f:? ).
+> at qemu I created an image from 30Gigabytes and entered this command from the imagefile's directory :
+>
+> "sudo qemu-system-x86_64 -localtime -usbdevice -hda /dev/sdb -m 384
+> -boot d winxp.img"
+>
+> the answer is :
+>
+> "qemu-system-x86_64: -boot d: drive with bus=0, unit=0 (index=0) exists"
+
+Why are you using "-boot d"?  'd' is the first CD-ROM and you have not
+given any -cdrom ISO image.
+
+Stefan
+
+
+hey stefan,
+
+I didn't find any manual for installing via usb,
+but I tried various letters till "g".
+what letter would you suggest?
+
+on my usb drive I have a linux bootable xp partition.
+or should I try to boot from a virtual drive via .iso image?
+
+thank you
+
diff --git a/results/classifier/118/device/74 b/results/classifier/118/device/74
new file mode 100644
index 00000000..2207bbdc
--- /dev/null
+++ b/results/classifier/118/device/74
@@ -0,0 +1,31 @@
+device: 0.912
+mistranslation: 0.686
+semantic: 0.653
+network: 0.607
+arm: 0.444
+performance: 0.440
+boot: 0.360
+architecture: 0.296
+graphic: 0.244
+peripherals: 0.223
+ppc: 0.220
+assembly: 0.216
+hypervisor: 0.184
+i386: 0.160
+debug: 0.151
+risc-v: 0.148
+socket: 0.141
+user-level: 0.130
+virtual: 0.129
+kernel: 0.106
+x86: 0.079
+vnc: 0.070
+VMM: 0.038
+TCG: 0.025
+register: 0.019
+files: 0.016
+permissions: 0.015
+KVM: 0.008
+PID: 0.005
+
+AUD_set_volume_out takes SWVoiceOut as parameter, but controls HWVoiceOut
diff --git a/results/classifier/118/device/743 b/results/classifier/118/device/743
new file mode 100644
index 00000000..4638b0b2
--- /dev/null
+++ b/results/classifier/118/device/743
@@ -0,0 +1,41 @@
+architecture: 0.949
+device: 0.944
+performance: 0.893
+graphic: 0.835
+semantic: 0.813
+arm: 0.781
+boot: 0.701
+register: 0.633
+debug: 0.599
+PID: 0.565
+vnc: 0.564
+socket: 0.559
+permissions: 0.555
+network: 0.546
+files: 0.522
+ppc: 0.503
+x86: 0.428
+risc-v: 0.415
+user-level: 0.408
+hypervisor: 0.396
+i386: 0.321
+virtual: 0.318
+mistranslation: 0.313
+kernel: 0.307
+assembly: 0.287
+VMM: 0.221
+TCG: 0.201
+peripherals: 0.174
+KVM: 0.024
+
+aarch64: Number of SMP CPUS exceeds max CPUs supported by machine (10 > 8) for M1 Pro/Max
+Description of problem:
+Trying to launch QEMU with more than 8 cores gives the following error:
+
+`qemu-system-aarch64: Number of SMP CPUs requested (10) exceeds max CPUs supported by machine 'mach-virt' (8)`
+
+Apple M1 Pro can have up to 10 cores while M1 Max only has 10 cores.
+Steps to reproduce:
+1. Install QEMU via homebrew (or MacPorts or from source)
+2. Run `qemu-system-aarch64 -machine virt,highmem=off -accel hvf -cpu cortex-a72 -smp 10`
+3. Get error, QEMU doesn't start
diff --git a/results/classifier/118/device/749 b/results/classifier/118/device/749
new file mode 100644
index 00000000..9be0f235
--- /dev/null
+++ b/results/classifier/118/device/749
@@ -0,0 +1,31 @@
+device: 0.806
+performance: 0.714
+network: 0.567
+architecture: 0.392
+hypervisor: 0.382
+arm: 0.310
+boot: 0.302
+graphic: 0.228
+user-level: 0.196
+socket: 0.190
+semantic: 0.185
+i386: 0.179
+x86: 0.174
+register: 0.172
+vnc: 0.158
+mistranslation: 0.156
+permissions: 0.138
+risc-v: 0.134
+ppc: 0.122
+PID: 0.111
+kernel: 0.105
+assembly: 0.064
+files: 0.041
+peripherals: 0.040
+debug: 0.036
+virtual: 0.027
+TCG: 0.016
+VMM: 0.016
+KVM: 0.002
+
+Enhance QEMU live patching
diff --git a/results/classifier/118/device/75 b/results/classifier/118/device/75
new file mode 100644
index 00000000..1ea96241
--- /dev/null
+++ b/results/classifier/118/device/75
@@ -0,0 +1,31 @@
+device: 0.873
+performance: 0.722
+graphic: 0.683
+mistranslation: 0.619
+semantic: 0.608
+arm: 0.593
+network: 0.576
+architecture: 0.538
+peripherals: 0.486
+risc-v: 0.461
+files: 0.440
+ppc: 0.428
+PID: 0.366
+hypervisor: 0.344
+user-level: 0.314
+vnc: 0.296
+x86: 0.287
+i386: 0.262
+debug: 0.250
+TCG: 0.248
+boot: 0.242
+virtual: 0.229
+kernel: 0.217
+permissions: 0.174
+VMM: 0.168
+assembly: 0.162
+KVM: 0.136
+register: 0.107
+socket: 0.072
+
+Add -display SDL grab-on-hover option
diff --git a/results/classifier/118/device/757 b/results/classifier/118/device/757
new file mode 100644
index 00000000..e3b33b32
--- /dev/null
+++ b/results/classifier/118/device/757
@@ -0,0 +1,31 @@
+device: 0.820
+performance: 0.787
+mistranslation: 0.766
+network: 0.599
+kernel: 0.572
+debug: 0.468
+architecture: 0.428
+hypervisor: 0.424
+VMM: 0.416
+graphic: 0.412
+semantic: 0.348
+peripherals: 0.301
+boot: 0.301
+PID: 0.297
+arm: 0.291
+register: 0.237
+socket: 0.226
+vnc: 0.217
+TCG: 0.206
+permissions: 0.192
+KVM: 0.182
+risc-v: 0.168
+i386: 0.159
+virtual: 0.143
+ppc: 0.125
+user-level: 0.116
+files: 0.109
+assembly: 0.107
+x86: 0.025
+
+intel-hda: stream reset bits are broken
diff --git a/results/classifier/118/device/76 b/results/classifier/118/device/76
new file mode 100644
index 00000000..515e0cee
--- /dev/null
+++ b/results/classifier/118/device/76
@@ -0,0 +1,31 @@
+device: 0.829
+performance: 0.798
+graphic: 0.621
+VMM: 0.617
+peripherals: 0.576
+network: 0.471
+i386: 0.459
+TCG: 0.441
+risc-v: 0.421
+debug: 0.403
+KVM: 0.351
+user-level: 0.310
+PID: 0.309
+kernel: 0.284
+register: 0.279
+boot: 0.267
+arm: 0.256
+ppc: 0.252
+files: 0.240
+x86: 0.219
+semantic: 0.215
+hypervisor: 0.209
+vnc: 0.175
+architecture: 0.161
+assembly: 0.157
+virtual: 0.099
+mistranslation: 0.074
+permissions: 0.072
+socket: 0.037
+
+Mouse cursor sometimes can't pass the invisible border on the right side of the screen
diff --git a/results/classifier/118/device/767 b/results/classifier/118/device/767
new file mode 100644
index 00000000..dc714b62
--- /dev/null
+++ b/results/classifier/118/device/767
@@ -0,0 +1,33 @@
+device: 0.908
+network: 0.852
+performance: 0.767
+ppc: 0.512
+arm: 0.462
+architecture: 0.428
+debug: 0.370
+graphic: 0.359
+boot: 0.295
+register: 0.276
+peripherals: 0.222
+PID: 0.202
+risc-v: 0.179
+socket: 0.172
+semantic: 0.154
+hypervisor: 0.130
+TCG: 0.128
+mistranslation: 0.126
+kernel: 0.125
+files: 0.114
+vnc: 0.110
+virtual: 0.109
+VMM: 0.092
+user-level: 0.057
+permissions: 0.041
+assembly: 0.025
+x86: 0.003
+KVM: 0.002
+i386: 0.002
+
+Improve softmmu TLB utilisation by improving tlb_flush usage on PPC64
+Additional information:
+
diff --git a/results/classifier/118/device/770 b/results/classifier/118/device/770
new file mode 100644
index 00000000..32e6e0b1
--- /dev/null
+++ b/results/classifier/118/device/770
@@ -0,0 +1,31 @@
+device: 0.844
+performance: 0.755
+permissions: 0.708
+ppc: 0.642
+architecture: 0.631
+i386: 0.599
+graphic: 0.575
+network: 0.559
+peripherals: 0.525
+hypervisor: 0.495
+semantic: 0.450
+x86: 0.426
+kernel: 0.399
+mistranslation: 0.363
+PID: 0.340
+arm: 0.290
+VMM: 0.247
+register: 0.221
+files: 0.202
+debug: 0.199
+TCG: 0.178
+user-level: 0.175
+virtual: 0.143
+KVM: 0.125
+vnc: 0.109
+assembly: 0.106
+boot: 0.104
+socket: 0.093
+risc-v: 0.089
+
+READ memory access in /hw/acpi/pcihp.c
diff --git a/results/classifier/118/device/775 b/results/classifier/118/device/775
new file mode 100644
index 00000000..1140ebdf
--- /dev/null
+++ b/results/classifier/118/device/775
@@ -0,0 +1,34 @@
+device: 0.839
+arm: 0.805
+mistranslation: 0.799
+graphic: 0.634
+network: 0.622
+semantic: 0.546
+socket: 0.463
+files: 0.446
+boot: 0.441
+kernel: 0.407
+ppc: 0.372
+vnc: 0.365
+register: 0.341
+risc-v: 0.293
+architecture: 0.278
+performance: 0.242
+i386: 0.240
+assembly: 0.223
+x86: 0.220
+virtual: 0.217
+debug: 0.194
+VMM: 0.156
+TCG: 0.105
+hypervisor: 0.077
+KVM: 0.072
+user-level: 0.069
+permissions: 0.054
+peripherals: 0.049
+PID: 0.043
+
+Backup always use Microsoft VSS-FULL Option and breaks other Backups
+Additional information:
+MS VSS-Options 
+[https://docs.microsoft.com/en-us/windows/win32/api/vss/ne-vss-vss_backup_type](https://docs.microsoft.com/en-us/windows/win32/api/vss/ne-vss-vss_backup_type)
diff --git a/results/classifier/118/device/782 b/results/classifier/118/device/782
new file mode 100644
index 00000000..c5a7675c
--- /dev/null
+++ b/results/classifier/118/device/782
@@ -0,0 +1,35 @@
+device: 0.858
+vnc: 0.750
+network: 0.682
+graphic: 0.585
+VMM: 0.527
+i386: 0.475
+semantic: 0.454
+files: 0.398
+PID: 0.351
+register: 0.333
+socket: 0.328
+boot: 0.304
+TCG: 0.303
+ppc: 0.286
+x86: 0.263
+architecture: 0.260
+risc-v: 0.249
+virtual: 0.224
+mistranslation: 0.213
+arm: 0.211
+hypervisor: 0.204
+kernel: 0.168
+permissions: 0.144
+debug: 0.121
+performance: 0.087
+KVM: 0.076
+user-level: 0.076
+peripherals: 0.072
+assembly: 0.051
+
+nvme: DMA reentrancy issue leads to use-after-free (CVE-2021-3929)
+Description of problem:
+A DMA reentrancy issue was found in the NVM Express Controller (NVMe) emulation. Functions dma_buf_write() or dma_buf_read() in hw/nvme/ctrl.c:nvme_tx() can be called without checking if the destination region overlaps with device's MMIO. This is similar to CVE-2021-3750 (https://gitlab.com/qemu-project/qemu/-/issues/541) and, just like it, when the reentrancy write triggers the reset function nvme_ctrl_reset(), data structs will be freed leading to a use-after-free issue. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host.
+
+This issue was reported by Qiuhao Li.
diff --git a/results/classifier/118/device/784 b/results/classifier/118/device/784
new file mode 100644
index 00000000..171da431
--- /dev/null
+++ b/results/classifier/118/device/784
@@ -0,0 +1,43 @@
+x86: 0.963
+device: 0.952
+graphic: 0.951
+KVM: 0.936
+peripherals: 0.931
+performance: 0.910
+hypervisor: 0.892
+vnc: 0.879
+virtual: 0.859
+architecture: 0.835
+VMM: 0.828
+PID: 0.778
+permissions: 0.774
+network: 0.773
+semantic: 0.759
+i386: 0.723
+ppc: 0.717
+debug: 0.713
+risc-v: 0.711
+kernel: 0.705
+boot: 0.701
+TCG: 0.675
+register: 0.667
+socket: 0.606
+files: 0.599
+user-level: 0.596
+arm: 0.571
+assembly: 0.545
+mistranslation: 0.516
+
+max_hostmem does not work with virtio-vga-gl
+Description of problem:
+With property `max_hostmem=1000`, I hope the virgl VGA device can have 1GB video memory. But, after the VM starts, the command `glxinfo -B` returns "Video memory: 0MB", which I think means the virgl VGA does not obtain any video memory, or `max_hostmem=1000` does not work with `virtio-vga-gl`. Is it a bug or virgl has other property parameter to specify video memory?
+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.
+4. Type `glxinfo -B` in VM terminal
+Additional information:
+![image](/uploads/c0bfb7a336493387ee90ffe7e6209dfe/image.png)
diff --git a/results/classifier/118/device/785 b/results/classifier/118/device/785
new file mode 100644
index 00000000..0e953910
--- /dev/null
+++ b/results/classifier/118/device/785
@@ -0,0 +1,31 @@
+device: 0.862
+graphic: 0.608
+assembly: 0.530
+peripherals: 0.488
+performance: 0.411
+semantic: 0.335
+debug: 0.331
+arm: 0.281
+architecture: 0.252
+user-level: 0.210
+PID: 0.204
+permissions: 0.184
+TCG: 0.181
+ppc: 0.174
+risc-v: 0.156
+register: 0.138
+VMM: 0.137
+mistranslation: 0.125
+files: 0.111
+network: 0.093
+vnc: 0.090
+hypervisor: 0.045
+virtual: 0.040
+kernel: 0.037
+boot: 0.028
+socket: 0.008
+i386: 0.006
+KVM: 0.003
+x86: 0.001
+
+Build failure on macOS with jack
diff --git a/results/classifier/118/device/786208 b/results/classifier/118/device/786208
new file mode 100644
index 00000000..b80e55f2
--- /dev/null
+++ b/results/classifier/118/device/786208
@@ -0,0 +1,45 @@
+device: 0.886
+performance: 0.835
+graphic: 0.759
+semantic: 0.704
+mistranslation: 0.676
+network: 0.654
+architecture: 0.620
+register: 0.606
+kernel: 0.602
+i386: 0.575
+peripherals: 0.566
+PID: 0.562
+hypervisor: 0.545
+permissions: 0.544
+risc-v: 0.517
+debug: 0.506
+x86: 0.503
+vnc: 0.493
+files: 0.468
+ppc: 0.466
+assembly: 0.463
+socket: 0.462
+VMM: 0.451
+virtual: 0.446
+user-level: 0.419
+arm: 0.405
+boot: 0.384
+TCG: 0.347
+KVM: 0.246
+
+Missing checks for non-existent device in ide_exec_cmd
+
+Several calls in the ide_exec_cmd handler are missing checks for (!s->bs) or similar, resulting in NULL pointer dereferences, divide-by-zero, or possibly other badness if the guest performs operations on a non-existent IDE master.
+
+For example, the WIN_READ_NATIVE_MAX command does a 'ide_set_sector(s, s->nb_sectors - 1);', which does 'cyl = sector_num / (s->heads * s->sectors);', which will fail with a divide-by-zero if heads = sectors = 0.
+
+And WIN_MULTREAD also does not check for s->bs, but does a 'ide_sector_read(s);', which will do 'bdrv_read(s->bs, sector_num, s->io_buffer, n);' on a NULL s->bs, leading to a segfault.
+
+I do not *believe* that a malicious guest can do anything more than cause a crash with these bugs.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/786209 b/results/classifier/118/device/786209
new file mode 100644
index 00000000..337e5af1
--- /dev/null
+++ b/results/classifier/118/device/786209
@@ -0,0 +1,45 @@
+device: 0.810
+vnc: 0.649
+architecture: 0.634
+network: 0.605
+socket: 0.550
+kernel: 0.543
+graphic: 0.529
+semantic: 0.472
+arm: 0.472
+performance: 0.439
+risc-v: 0.429
+mistranslation: 0.429
+ppc: 0.397
+permissions: 0.389
+boot: 0.377
+i386: 0.358
+PID: 0.326
+peripherals: 0.326
+x86: 0.294
+files: 0.287
+register: 0.276
+VMM: 0.246
+TCG: 0.200
+debug: 0.190
+KVM: 0.162
+hypervisor: 0.134
+user-level: 0.101
+virtual: 0.091
+assembly: 0.084
+
+Information leak in IDE core
+
+When the DRQ_STAT bit is set, the IDE core permits both data reads and data writes, regardless of whether the current transfer was initiated as a read or write.
+
+Furthermore, the IO buffer is allocated via a qemu_memalign but not initialized or cleared at device creation.
+
+This potentially leaks uninitialized host memory into the guest, if, before doing anything else to an IDE device, the guest begins a write transaction (e.g. WIN_WRITE), but then *reads* from the IO port instead of writing to it. The IDE core will happily return the uninitialized contents of the buffer to the guest, potentially leaking offsets that could be used as part of an attack to get around ASLR.
+
+hi Nelson :
+    
+    what 's the flag 'DRQ_STAT' mean for   HD_STATUS ?
+
+Fixed here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=40c4ed3f95f0b2ffa0848df0f
+
diff --git a/results/classifier/118/device/788 b/results/classifier/118/device/788
new file mode 100644
index 00000000..25df020d
--- /dev/null
+++ b/results/classifier/118/device/788
@@ -0,0 +1,31 @@
+mistranslation: 0.930
+device: 0.926
+network: 0.882
+performance: 0.847
+kernel: 0.778
+arm: 0.764
+files: 0.649
+vnc: 0.613
+debug: 0.554
+socket: 0.537
+permissions: 0.502
+boot: 0.466
+architecture: 0.461
+hypervisor: 0.419
+register: 0.397
+VMM: 0.353
+peripherals: 0.334
+risc-v: 0.333
+ppc: 0.313
+graphic: 0.266
+semantic: 0.263
+TCG: 0.244
+i386: 0.236
+KVM: 0.220
+x86: 0.203
+user-level: 0.157
+PID: 0.114
+virtual: 0.099
+assembly: 0.099
+
+FEAT_PAuth trapping behaviour incorrectly emulated on Secure-EL0/1 with Secure-EL2 disabled
diff --git a/results/classifier/118/device/79 b/results/classifier/118/device/79
new file mode 100644
index 00000000..5da48a28
--- /dev/null
+++ b/results/classifier/118/device/79
@@ -0,0 +1,31 @@
+device: 0.907
+peripherals: 0.850
+performance: 0.744
+mistranslation: 0.689
+graphic: 0.581
+VMM: 0.501
+semantic: 0.450
+user-level: 0.400
+risc-v: 0.366
+KVM: 0.356
+TCG: 0.346
+vnc: 0.328
+permissions: 0.304
+assembly: 0.301
+boot: 0.254
+architecture: 0.214
+ppc: 0.212
+register: 0.176
+i386: 0.163
+PID: 0.156
+virtual: 0.136
+debug: 0.098
+x86: 0.091
+hypervisor: 0.080
+network: 0.079
+arm: 0.065
+files: 0.040
+kernel: 0.016
+socket: 0.011
+
+support horisontal mouse wheel
diff --git a/results/classifier/118/device/791 b/results/classifier/118/device/791
new file mode 100644
index 00000000..0fdc46f0
--- /dev/null
+++ b/results/classifier/118/device/791
@@ -0,0 +1,31 @@
+device: 0.942
+architecture: 0.880
+virtual: 0.818
+hypervisor: 0.813
+performance: 0.811
+network: 0.743
+debug: 0.705
+arm: 0.620
+boot: 0.467
+vnc: 0.457
+graphic: 0.413
+semantic: 0.367
+ppc: 0.291
+mistranslation: 0.289
+i386: 0.222
+socket: 0.194
+register: 0.177
+risc-v: 0.170
+permissions: 0.122
+VMM: 0.111
+x86: 0.102
+peripherals: 0.097
+user-level: 0.080
+PID: 0.055
+files: 0.025
+TCG: 0.023
+assembly: 0.008
+kernel: 0.007
+KVM: 0.001
+
+unable to execute QEMU command - SGX VM using libvirtd
diff --git a/results/classifier/118/device/795 b/results/classifier/118/device/795
new file mode 100644
index 00000000..4b2dd712
--- /dev/null
+++ b/results/classifier/118/device/795
@@ -0,0 +1,31 @@
+device: 0.812
+arm: 0.655
+performance: 0.639
+VMM: 0.555
+architecture: 0.554
+assembly: 0.534
+vnc: 0.443
+PID: 0.433
+files: 0.429
+boot: 0.411
+graphic: 0.368
+network: 0.363
+risc-v: 0.342
+register: 0.339
+TCG: 0.329
+ppc: 0.298
+debug: 0.277
+socket: 0.270
+mistranslation: 0.253
+semantic: 0.230
+permissions: 0.202
+kernel: 0.171
+user-level: 0.130
+i386: 0.123
+KVM: 0.113
+x86: 0.094
+hypervisor: 0.081
+virtual: 0.074
+peripherals: 0.002
+
+meson.build: coreaudio check failed
diff --git a/results/classifier/118/device/796 b/results/classifier/118/device/796
new file mode 100644
index 00000000..3bace64c
--- /dev/null
+++ b/results/classifier/118/device/796
@@ -0,0 +1,47 @@
+device: 0.910
+graphic: 0.758
+ppc: 0.758
+performance: 0.697
+PID: 0.674
+architecture: 0.670
+network: 0.653
+debug: 0.645
+socket: 0.639
+kernel: 0.612
+arm: 0.556
+semantic: 0.551
+vnc: 0.543
+user-level: 0.517
+mistranslation: 0.508
+boot: 0.508
+files: 0.507
+risc-v: 0.475
+register: 0.451
+VMM: 0.375
+TCG: 0.361
+hypervisor: 0.357
+peripherals: 0.353
+assembly: 0.305
+permissions: 0.215
+virtual: 0.150
+KVM: 0.058
+x86: 0.029
+i386: 0.019
+
+make -j126 check failed in qemu@6.2.0 on ubuntu_aarch64
+Steps to reproduce:
+the issue
+
+```console
+[root@localhost build]#make -j126 check
+Running test fp-test-sqrt
+Running test fp-test-sub
+Running test fp-test-log2
+**
+ERROR:../tests/unit/test-qga.c:718:test_qga_config: assertion failed (err == ""): ("/home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: symbol lookup error: /home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: undefined symbol: g_unix_get_passwd_entry\n" == "")
+ERROR test-qga - Bail out! ERROR:../tests/unit/test-qga.c:718:test_qga_config: assertion failed (err == ""): ("/home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: symbol lookup error: /home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: undefined symbol: g_unix_get_passwd_entry\n" == "")
+make: *** [Makefile.mtest:1472: run-test-182] Error 1
+make: *** Waiting for unfinished jobs....
+……
+```
+I don't know why happen,can you help me?
diff --git a/results/classifier/118/device/801 b/results/classifier/118/device/801
new file mode 100644
index 00000000..c79bef7c
--- /dev/null
+++ b/results/classifier/118/device/801
@@ -0,0 +1,42 @@
+x86: 0.951
+device: 0.929
+architecture: 0.805
+PID: 0.805
+graphic: 0.787
+virtual: 0.776
+files: 0.724
+debug: 0.708
+vnc: 0.682
+VMM: 0.663
+permissions: 0.604
+register: 0.592
+performance: 0.560
+semantic: 0.554
+ppc: 0.535
+socket: 0.522
+network: 0.464
+kernel: 0.460
+risc-v: 0.459
+KVM: 0.446
+boot: 0.434
+TCG: 0.379
+mistranslation: 0.375
+arm: 0.335
+user-level: 0.285
+i386: 0.235
+peripherals: 0.113
+assembly: 0.089
+hypervisor: 0.083
+
+QEMU test build failure with --enable-modules
+Description of problem:
+
+Steps to reproduce:
+1. ./configure --target-list=x86_64-softmmu --enable-kvm --enable-modules
+2.  make -j8 check-qtest-x86_64 V=1  
+ 
+ - A problem happens "qemu-system-x86_64: -accel qtest: invalid accelerator qtest" 
+ - The file accel-qtest-x86_64.so is not built
+ - This problem happens since 69c4c5c1c47f5dac140eb6485c5281a9f145dcf3 Mon Sep 17 00:00:00 2001
+Additional information:
+
diff --git a/results/classifier/118/device/804 b/results/classifier/118/device/804
new file mode 100644
index 00000000..16308840
--- /dev/null
+++ b/results/classifier/118/device/804
@@ -0,0 +1,39 @@
+device: 0.929
+peripherals: 0.869
+graphic: 0.712
+network: 0.711
+performance: 0.703
+debug: 0.608
+VMM: 0.550
+semantic: 0.519
+arm: 0.404
+PID: 0.368
+architecture: 0.331
+boot: 0.325
+hypervisor: 0.319
+i386: 0.295
+kernel: 0.271
+permissions: 0.270
+register: 0.252
+socket: 0.249
+TCG: 0.227
+files: 0.223
+mistranslation: 0.212
+KVM: 0.197
+risc-v: 0.191
+user-level: 0.174
+ppc: 0.167
+x86: 0.154
+virtual: 0.153
+vnc: 0.150
+assembly: 0.044
+
+savevm - QXL preventing save
+Description of problem:
+Attempting to savevm with a QXL VGA device attached causes the error "pre-save failed: qxl" to appear.
+Steps to reproduce:
+1. Start a QEMU instance with a QXL device
+2. Attempt to savevm
+3. See error
+Additional information:
+
diff --git a/results/classifier/118/device/805 b/results/classifier/118/device/805
new file mode 100644
index 00000000..7cb84b88
--- /dev/null
+++ b/results/classifier/118/device/805
@@ -0,0 +1,44 @@
+device: 0.803
+graphic: 0.630
+network: 0.569
+files: 0.476
+vnc: 0.451
+socket: 0.361
+ppc: 0.334
+debug: 0.254
+PID: 0.232
+boot: 0.214
+semantic: 0.207
+VMM: 0.165
+arm: 0.161
+risc-v: 0.146
+user-level: 0.127
+architecture: 0.111
+performance: 0.109
+TCG: 0.109
+permissions: 0.107
+mistranslation: 0.094
+x86: 0.085
+kernel: 0.081
+register: 0.068
+hypervisor: 0.044
+peripherals: 0.044
+KVM: 0.040
+virtual: 0.039
+i386: 0.038
+assembly: 0.008
+
+qemu-hexagon: [binary]: Error mapping file: Invalid argument
+Description of problem:
+Running a (32bit) hexagon binary on a 64bit/32bit system gives the following error:
+`qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument`
+Steps to reproduce:
+```
+./qemu-hexagon <hexagon-binary>
+qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument
+```
+Additional information:
+A similar problem has been reported on the mailing list:
+https://www.mail-archive.com/qemu-devel@nongnu.org/msg836466.html
+
+Unfortunately without a solution.
diff --git a/results/classifier/118/device/808 b/results/classifier/118/device/808
new file mode 100644
index 00000000..deb066b3
--- /dev/null
+++ b/results/classifier/118/device/808
@@ -0,0 +1,48 @@
+device: 0.963
+x86: 0.935
+graphic: 0.930
+architecture: 0.915
+boot: 0.898
+peripherals: 0.892
+KVM: 0.888
+hypervisor: 0.884
+virtual: 0.834
+ppc: 0.829
+semantic: 0.826
+performance: 0.818
+vnc: 0.796
+PID: 0.752
+VMM: 0.739
+files: 0.698
+network: 0.682
+risc-v: 0.670
+mistranslation: 0.662
+permissions: 0.658
+socket: 0.638
+kernel: 0.603
+TCG: 0.595
+register: 0.555
+arm: 0.554
+user-level: 0.522
+debug: 0.443
+assembly: 0.282
+i386: 0.194
+
+virtio-scsi in Windows guests cause QEMU to abort/crash
+Description of problem:
+* Attempting to load the virtio-scsi drivers in a Windows guest causes the VM to abort/crash.
+Steps to reproduce:
+* `qemu-system-x86_64 -accel kvm -m 4G -device virtio-scsi-pci,id=scsi0 -drive media=cdrom,file=windows7-x64.iso -drive media=cdrom,file=virtio-win-0.1.173.iso`
+ * Boot the installer ISO, click through all the menus to eventually get to Custom Install
+ * In "Where do you want to install" click Load driver
+ * Browse E: drive and pick the first amd64/w7 folder
+ * Should show "Red Had VirtIO SCSI pass-through controller"
+ * Click Next
+ * Abort/crash
+
+Same thing happens with VM's that used to work already running the virtio-scsi drivers. When they boot the VM aborts.
+Additional information:
+```
+qemu-system-x86_64: ../accel/kvm/kvm-all.c:1760: kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
+Aborted (core dumped)
+```
diff --git a/results/classifier/118/device/832 b/results/classifier/118/device/832
new file mode 100644
index 00000000..ce5d3ad5
--- /dev/null
+++ b/results/classifier/118/device/832
@@ -0,0 +1,43 @@
+device: 0.845
+files: 0.772
+graphic: 0.739
+vnc: 0.684
+network: 0.672
+virtual: 0.652
+socket: 0.626
+PID: 0.595
+boot: 0.574
+performance: 0.565
+register: 0.540
+VMM: 0.523
+KVM: 0.490
+user-level: 0.488
+hypervisor: 0.474
+semantic: 0.472
+permissions: 0.471
+debug: 0.466
+architecture: 0.450
+kernel: 0.423
+i386: 0.418
+TCG: 0.405
+x86: 0.403
+peripherals: 0.369
+arm: 0.355
+mistranslation: 0.350
+risc-v: 0.330
+ppc: 0.319
+assembly: 0.146
+
+error "# mkdir('/..../qtest-9p-local-M33XsI') failed: File exists"  on every  run of 'qos-test'
+Description of problem:
+```
+$ ./build//tests/qtest/qos-test -h
+# mkdir('/home/berrange/src/virt/qemu/qtest-9p-local-qThj5y') failed: File exists
+Usage:
+  ./build//tests/qtest/qos-test [OPTION...]
+...snip...
+```
+
+Notice the error message from 'mkdir()' whic appears every time you run this program.
+Steps to reproduce:
+1. Run  qos-test
diff --git a/results/classifier/118/device/837 b/results/classifier/118/device/837
new file mode 100644
index 00000000..bb30b7f6
--- /dev/null
+++ b/results/classifier/118/device/837
@@ -0,0 +1,60 @@
+architecture: 0.993
+x86: 0.960
+i386: 0.949
+device: 0.946
+performance: 0.931
+graphic: 0.919
+files: 0.864
+peripherals: 0.849
+debug: 0.815
+semantic: 0.776
+PID: 0.758
+permissions: 0.728
+user-level: 0.728
+mistranslation: 0.720
+network: 0.707
+boot: 0.693
+vnc: 0.638
+register: 0.628
+kernel: 0.624
+socket: 0.595
+ppc: 0.582
+TCG: 0.565
+assembly: 0.554
+VMM: 0.525
+risc-v: 0.457
+arm: 0.453
+hypervisor: 0.374
+virtual: 0.184
+KVM: 0.074
+
+x86 user: icebp/int1 raises wrong signal
+Description of problem:
+This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`.
+
+Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`.
+
+This also happens on an AArch64 host.
+```
+$ ./icebp
+Trace/breakpoint trap
+$ qemu-x86_64 ./icebp
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction
+```
+Steps to reproduce:
+1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386
+```
+    .globl _start
+_start:
+    .byte  0xF1 // gas doesn't assemble this instruction opcode but it disassembles it
+#ifdef __x86_64__
+    mov    $60, %eax
+    syscall
+#else
+    mov    $1, %eax
+    int    $0x80
+#endif 
+```
+2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message
+3. Run on qemu-user. Notice how it raises `SIGILL`.
diff --git a/results/classifier/118/device/84 b/results/classifier/118/device/84
new file mode 100644
index 00000000..44b2d658
--- /dev/null
+++ b/results/classifier/118/device/84
@@ -0,0 +1,31 @@
+device: 0.877
+performance: 0.791
+boot: 0.606
+debug: 0.595
+arm: 0.593
+network: 0.553
+semantic: 0.522
+graphic: 0.490
+hypervisor: 0.482
+VMM: 0.475
+KVM: 0.452
+mistranslation: 0.447
+register: 0.440
+architecture: 0.433
+kernel: 0.402
+risc-v: 0.397
+ppc: 0.320
+TCG: 0.308
+i386: 0.297
+x86: 0.289
+vnc: 0.273
+permissions: 0.265
+files: 0.214
+socket: 0.210
+PID: 0.201
+peripherals: 0.164
+assembly: 0.074
+virtual: 0.038
+user-level: 0.011
+
+Machine shut off after tons of lsi_scsi: error: MSG IN data too long
diff --git a/results/classifier/118/device/842290 b/results/classifier/118/device/842290
new file mode 100644
index 00000000..3528085b
--- /dev/null
+++ b/results/classifier/118/device/842290
@@ -0,0 +1,47 @@
+device: 0.861
+architecture: 0.805
+kernel: 0.805
+performance: 0.737
+ppc: 0.714
+socket: 0.702
+graphic: 0.673
+network: 0.654
+mistranslation: 0.638
+boot: 0.637
+vnc: 0.621
+files: 0.575
+semantic: 0.543
+assembly: 0.519
+arm: 0.518
+debug: 0.428
+VMM: 0.412
+permissions: 0.399
+PID: 0.371
+KVM: 0.322
+i386: 0.322
+risc-v: 0.305
+x86: 0.297
+TCG: 0.234
+hypervisor: 0.229
+user-level: 0.219
+peripherals: 0.218
+register: 0.198
+virtual: 0.163
+
+MIPS Malta mini-bootloader print function has bad jump instruction
+
+One of the hardcoded bootloader library instructions in the MIPS Malta mini-bootloader's print function is:
+
+stl_raw(p++, 0x08000205);                                     /* j 814 */
+
+Since this function is loaded at 0xbfc00808, this jump jumps to the middle of nowhere. The properly-encoded instruction is:
+
+stl_raw(p++, 0x0bf00205);                                     /* j 814 */
+
+With this patch, the print function behaves as expected.
+
+
+
+Looks like this has been finally fixed by this commit here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7f81dbb9a0e89b53
+
diff --git a/results/classifier/118/device/843 b/results/classifier/118/device/843
new file mode 100644
index 00000000..e3f0f277
--- /dev/null
+++ b/results/classifier/118/device/843
@@ -0,0 +1,33 @@
+device: 0.891
+network: 0.882
+graphic: 0.670
+arm: 0.609
+semantic: 0.591
+socket: 0.539
+architecture: 0.517
+debug: 0.491
+register: 0.449
+mistranslation: 0.437
+kernel: 0.428
+performance: 0.416
+boot: 0.401
+files: 0.383
+peripherals: 0.346
+VMM: 0.316
+vnc: 0.292
+ppc: 0.222
+hypervisor: 0.202
+PID: 0.185
+i386: 0.165
+assembly: 0.158
+virtual: 0.148
+x86: 0.118
+TCG: 0.108
+user-level: 0.087
+risc-v: 0.046
+permissions: 0.043
+KVM: 0.012
+
+qemu-binfmt-conf causes duplicate magic mips headers when installing all patterns
+Description of problem:
+The magic/mask patterns are the same for mips[el] and nipsn32[el]
diff --git a/results/classifier/118/device/873 b/results/classifier/118/device/873
new file mode 100644
index 00000000..03c27cfc
--- /dev/null
+++ b/results/classifier/118/device/873
@@ -0,0 +1,31 @@
+device: 0.902
+arm: 0.643
+architecture: 0.635
+debug: 0.559
+ppc: 0.523
+register: 0.508
+PID: 0.393
+semantic: 0.367
+boot: 0.352
+graphic: 0.318
+risc-v: 0.310
+mistranslation: 0.255
+network: 0.232
+performance: 0.226
+virtual: 0.212
+permissions: 0.176
+vnc: 0.166
+files: 0.162
+user-level: 0.161
+VMM: 0.153
+TCG: 0.118
+i386: 0.116
+peripherals: 0.101
+socket: 0.075
+assembly: 0.028
+x86: 0.020
+hypervisor: 0.020
+KVM: 0.002
+kernel: 0.002
+
+Meson warns about a broken Python install on Debian/Ubuntu
diff --git a/results/classifier/118/device/873460 b/results/classifier/118/device/873460
new file mode 100644
index 00000000..2842a447
--- /dev/null
+++ b/results/classifier/118/device/873460
@@ -0,0 +1,62 @@
+device: 0.851
+mistranslation: 0.848
+graphic: 0.831
+semantic: 0.785
+architecture: 0.707
+PID: 0.661
+user-level: 0.648
+register: 0.643
+performance: 0.636
+boot: 0.604
+kernel: 0.603
+permissions: 0.590
+network: 0.578
+socket: 0.577
+ppc: 0.546
+hypervisor: 0.536
+vnc: 0.514
+risc-v: 0.508
+assembly: 0.504
+VMM: 0.469
+KVM: 0.436
+files: 0.431
+arm: 0.428
+TCG: 0.426
+peripherals: 0.425
+virtual: 0.401
+x86: 0.401
+i386: 0.390
+debug: 0.349
+
+Likewise no sound
+
+Hi,
+using fresh Ubuntu 11.10 with Likewise 6 in a MS Domain.
+Domain users log with no sound.
+Local users are OK.
+
+Thx
+
+Sry, posted in the wrong chanel.
+
+Can I move it to https://bugs.launchpad.net/ubuntu/+source/likewise-open ?
+
+I have same issue.
+11.10 local user sound works.
+Sound hardware is shown under Ubuntu sound.
+Installed likewise from Ubuntu repository and logging in as domain user hardware doesn't show up in sound config. No sound.
+It also doesnt access sound hardware in most apps, although it does in Skype.
+I added Dom user to audio, admin etc, and reinstalled audio, but can't get this to work as Dom user.
+
+I also have the same problem on Ubuntu 12.04.1 64 bits.
+
+A fresh install only with likewise open from the repository. Local user have sound but domain user do not!
+
+I have tested on 4 diferent machines with diferent hardware and the problem is always the same...
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Moving this to likewise-open according to comment #1.
+
+This is a dupe of #925023 jadis confirmed on 2012-03-01 but never solved.
+
diff --git a/results/classifier/118/device/877498 b/results/classifier/118/device/877498
new file mode 100644
index 00000000..bf8b3580
--- /dev/null
+++ b/results/classifier/118/device/877498
@@ -0,0 +1,92 @@
+device: 0.867
+architecture: 0.860
+peripherals: 0.850
+vnc: 0.837
+hypervisor: 0.789
+risc-v: 0.776
+VMM: 0.743
+ppc: 0.739
+PID: 0.730
+KVM: 0.675
+graphic: 0.673
+TCG: 0.671
+boot: 0.635
+user-level: 0.605
+performance: 0.602
+register: 0.595
+x86: 0.593
+debug: 0.585
+permissions: 0.573
+mistranslation: 0.572
+socket: 0.553
+arm: 0.538
+files: 0.535
+semantic: 0.527
+virtual: 0.519
+network: 0.477
+assembly: 0.401
+kernel: 0.370
+i386: 0.328
+
+qemu does not pass sector size from physical devices to virtual devices
+
+When passing a physical disk (i.e. a multipathed fcal volume in my case) with a 4k sector size as raw image to qemu (-drive file=/dev/mapper/hartebeest-sys,if=none,id=drive-virtio-disk0,boot=on,format=raw), the resulting virtual device has a sector size of 512b, rendering the partition table unusable!
+
+QEMU 0.12 is pretty much outdated ... can you still reproduce this issue with the latest version of QEMU, or can we close this bug nowadays?
+
+Hi,
+
+I can’t verify it for the logical block size right away, but 
+this bug still present for the physical block size in qemu-kvm 1:2.1+dfsg-1.
+
+I will try to verify this bug with testing soon
+
+> On 20. Mar 2017, at 23:57, Thomas Huth <email address hidden> wrote:
+> 
+> QEMU 0.12 is pretty much outdated ... can you still reproduce this issue
+> with the latest version of QEMU, or can we close this bug 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/877498
+> 
+> Title:
+>  qemu does not pass sector size from physical devices to virtual
+>  devices
+> 
+> Status in QEMU:
+>  Incomplete
+> 
+> Bug description:
+>  When passing a physical disk (i.e. a multipathed fcal volume in my
+>  case) with a 4k sector size as raw image to qemu (-drive
+>  file=/dev/mapper/hartebeest-sys,if=none,id=drive-virtio-
+>  disk0,boot=on,format=raw), the resulting virtual device has a sector
+>  size of 512b, rendering the partition table unusable.
+> 
+>  Versions used: QEMU 0.12.5 (qemu-kvm-0.12.5) from debian unstable
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/877498/+subscriptions
+> 
+
+AVE!
+  Philipp S. Tiesel / phils…
+-- 
+   {phils}--->---(<email address hidden>)--->---(http://phils.in-panik.de)----,
+      wenn w eine   aube ist dn      man au dran dre en                   |
+           o     Schr        an muss     hc         h   (Kurt Schwitters) |
+:wq!  <----(phone: +49-179-6737439)---<---(jabber: <email address hidden>)----'
+
+
+
+QEMU 2.1 is also not supported anymore. Please test with the latest upstream QEMU version (2.8 ... or the latest 2.9 release candidate) - or otherwise report the bug in the bug tracker of your distribution instead.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+Recent QEMU is able to do read-modify-write operations when using 512 byte logical sectors in the VM and 4K logical sectors in the host.
+
diff --git a/results/classifier/118/device/879 b/results/classifier/118/device/879
new file mode 100644
index 00000000..e782a762
--- /dev/null
+++ b/results/classifier/118/device/879
@@ -0,0 +1,33 @@
+device: 0.947
+peripherals: 0.776
+performance: 0.581
+boot: 0.510
+arm: 0.504
+register: 0.503
+VMM: 0.478
+network: 0.418
+graphic: 0.380
+mistranslation: 0.365
+risc-v: 0.364
+ppc: 0.320
+semantic: 0.320
+TCG: 0.318
+debug: 0.246
+user-level: 0.214
+architecture: 0.205
+KVM: 0.197
+permissions: 0.183
+PID: 0.180
+virtual: 0.142
+vnc: 0.139
+hypervisor: 0.108
+assembly: 0.076
+files: 0.072
+kernel: 0.061
+i386: 0.058
+socket: 0.049
+x86: 0.016
+
+Microphone support for Macbooks
+Additional information:
+
diff --git a/results/classifier/118/device/887 b/results/classifier/118/device/887
new file mode 100644
index 00000000..f13f3772
--- /dev/null
+++ b/results/classifier/118/device/887
@@ -0,0 +1,31 @@
+device: 0.871
+graphic: 0.662
+performance: 0.598
+network: 0.580
+boot: 0.522
+hypervisor: 0.504
+files: 0.501
+mistranslation: 0.495
+register: 0.414
+semantic: 0.385
+arm: 0.344
+permissions: 0.338
+peripherals: 0.278
+user-level: 0.233
+socket: 0.220
+architecture: 0.198
+debug: 0.188
+vnc: 0.180
+assembly: 0.136
+risc-v: 0.133
+kernel: 0.115
+virtual: 0.104
+PID: 0.081
+VMM: 0.062
+ppc: 0.062
+x86: 0.040
+TCG: 0.021
+KVM: 0.004
+i386: 0.003
+
+OSX Sorbet Leopard 10.5.9 on QEMU ?
diff --git a/results/classifier/118/device/889 b/results/classifier/118/device/889
new file mode 100644
index 00000000..cc5b7cf2
--- /dev/null
+++ b/results/classifier/118/device/889
@@ -0,0 +1,31 @@
+device: 0.842
+network: 0.760
+architecture: 0.739
+kernel: 0.720
+VMM: 0.642
+register: 0.636
+mistranslation: 0.613
+arm: 0.599
+files: 0.586
+socket: 0.563
+performance: 0.542
+boot: 0.528
+debug: 0.514
+PID: 0.493
+assembly: 0.491
+graphic: 0.427
+vnc: 0.414
+TCG: 0.393
+semantic: 0.391
+i386: 0.383
+hypervisor: 0.361
+x86: 0.361
+peripherals: 0.339
+KVM: 0.319
+ppc: 0.310
+risc-v: 0.227
+virtual: 0.213
+permissions: 0.155
+user-level: 0.113
+
+cc1: error: ‘-fcf-protection’ is not compatible with this target
diff --git a/results/classifier/118/device/896 b/results/classifier/118/device/896
new file mode 100644
index 00000000..b7384dd9
--- /dev/null
+++ b/results/classifier/118/device/896
@@ -0,0 +1,31 @@
+arm: 0.983
+TCG: 0.978
+device: 0.935
+architecture: 0.847
+mistranslation: 0.845
+network: 0.799
+graphic: 0.693
+peripherals: 0.650
+performance: 0.617
+register: 0.387
+risc-v: 0.302
+debug: 0.290
+permissions: 0.249
+boot: 0.196
+user-level: 0.196
+i386: 0.161
+hypervisor: 0.138
+semantic: 0.117
+ppc: 0.115
+virtual: 0.111
+files: 0.088
+PID: 0.075
+vnc: 0.067
+VMM: 0.065
+socket: 0.061
+assembly: 0.061
+x86: 0.020
+kernel: 0.018
+KVM: 0.017
+
+tcg/arm emits UNPREDICTABLE LDRD insn
diff --git a/results/classifier/118/device/897 b/results/classifier/118/device/897
new file mode 100644
index 00000000..6a504186
--- /dev/null
+++ b/results/classifier/118/device/897
@@ -0,0 +1,31 @@
+device: 0.935
+architecture: 0.920
+performance: 0.911
+graphic: 0.822
+hypervisor: 0.617
+network: 0.553
+debug: 0.430
+arm: 0.356
+semantic: 0.331
+mistranslation: 0.322
+assembly: 0.230
+virtual: 0.224
+register: 0.222
+peripherals: 0.174
+kernel: 0.160
+x86: 0.157
+boot: 0.157
+permissions: 0.102
+files: 0.097
+user-level: 0.086
+socket: 0.084
+PID: 0.078
+VMM: 0.071
+ppc: 0.048
+vnc: 0.042
+TCG: 0.038
+i386: 0.014
+risc-v: 0.007
+KVM: 0.007
+
+Warning with "qemu-s390x -cpu max"
diff --git a/results/classifier/118/device/902 b/results/classifier/118/device/902
new file mode 100644
index 00000000..64722f50
--- /dev/null
+++ b/results/classifier/118/device/902
@@ -0,0 +1,31 @@
+architecture: 0.985
+device: 0.961
+TCG: 0.953
+boot: 0.881
+graphic: 0.412
+arm: 0.404
+performance: 0.399
+semantic: 0.248
+kernel: 0.173
+hypervisor: 0.166
+virtual: 0.149
+peripherals: 0.105
+network: 0.102
+PID: 0.092
+register: 0.087
+x86: 0.078
+socket: 0.071
+ppc: 0.071
+files: 0.071
+permissions: 0.069
+debug: 0.065
+mistranslation: 0.063
+risc-v: 0.062
+user-level: 0.041
+assembly: 0.032
+vnc: 0.024
+VMM: 0.014
+i386: 0.005
+KVM: 0.002
+
+BootLinuxS390X test failing due to a TCG bug
diff --git a/results/classifier/118/device/91 b/results/classifier/118/device/91
new file mode 100644
index 00000000..1d7682b2
--- /dev/null
+++ b/results/classifier/118/device/91
@@ -0,0 +1,31 @@
+device: 0.819
+architecture: 0.712
+network: 0.559
+register: 0.488
+arm: 0.422
+performance: 0.417
+boot: 0.387
+socket: 0.346
+risc-v: 0.278
+graphic: 0.261
+permissions: 0.244
+mistranslation: 0.237
+files: 0.226
+debug: 0.215
+hypervisor: 0.203
+assembly: 0.197
+peripherals: 0.195
+vnc: 0.176
+virtual: 0.175
+semantic: 0.165
+kernel: 0.144
+ppc: 0.140
+PID: 0.097
+user-level: 0.095
+VMM: 0.090
+TCG: 0.090
+i386: 0.068
+KVM: 0.041
+x86: 0.020
+
+RFE: Implement support for SMBIOS Type 41 structures
diff --git a/results/classifier/118/device/924 b/results/classifier/118/device/924
new file mode 100644
index 00000000..928d14e1
--- /dev/null
+++ b/results/classifier/118/device/924
@@ -0,0 +1,31 @@
+device: 0.933
+performance: 0.889
+arm: 0.772
+network: 0.746
+architecture: 0.679
+graphic: 0.616
+hypervisor: 0.423
+mistranslation: 0.358
+semantic: 0.335
+debug: 0.335
+register: 0.329
+boot: 0.267
+permissions: 0.254
+ppc: 0.176
+risc-v: 0.137
+peripherals: 0.128
+vnc: 0.124
+user-level: 0.121
+virtual: 0.114
+socket: 0.113
+files: 0.084
+PID: 0.069
+i386: 0.023
+VMM: 0.019
+TCG: 0.019
+assembly: 0.018
+x86: 0.018
+kernel: 0.003
+KVM: 0.001
+
+AHCI IRQ lost running Fedora on SBSA-ref
diff --git a/results/classifier/118/device/94 b/results/classifier/118/device/94
new file mode 100644
index 00000000..796d646e
--- /dev/null
+++ b/results/classifier/118/device/94
@@ -0,0 +1,31 @@
+device: 0.823
+architecture: 0.745
+performance: 0.501
+network: 0.495
+arm: 0.440
+debug: 0.427
+kernel: 0.290
+graphic: 0.273
+boot: 0.260
+semantic: 0.243
+virtual: 0.224
+i386: 0.222
+socket: 0.191
+hypervisor: 0.185
+files: 0.176
+ppc: 0.157
+TCG: 0.155
+register: 0.154
+vnc: 0.135
+PID: 0.120
+x86: 0.097
+peripherals: 0.083
+risc-v: 0.077
+permissions: 0.071
+VMM: 0.068
+KVM: 0.060
+user-level: 0.049
+mistranslation: 0.040
+assembly: 0.031
+
+MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction
diff --git a/results/classifier/118/device/942 b/results/classifier/118/device/942
new file mode 100644
index 00000000..a3a74d05
--- /dev/null
+++ b/results/classifier/118/device/942
@@ -0,0 +1,31 @@
+device: 0.856
+architecture: 0.795
+performance: 0.560
+risc-v: 0.479
+graphic: 0.382
+user-level: 0.342
+peripherals: 0.270
+semantic: 0.263
+mistranslation: 0.246
+hypervisor: 0.233
+virtual: 0.211
+debug: 0.161
+network: 0.144
+permissions: 0.096
+assembly: 0.093
+arm: 0.086
+boot: 0.079
+register: 0.048
+ppc: 0.047
+TCG: 0.045
+PID: 0.025
+socket: 0.021
+VMM: 0.020
+x86: 0.015
+vnc: 0.015
+files: 0.014
+i386: 0.011
+KVM: 0.008
+kernel: 0.007
+
+No TPM support for riscv64 in QEMU
diff --git a/results/classifier/118/device/96 b/results/classifier/118/device/96
new file mode 100644
index 00000000..5cead6c4
--- /dev/null
+++ b/results/classifier/118/device/96
@@ -0,0 +1,31 @@
+device: 0.878
+architecture: 0.802
+virtual: 0.760
+network: 0.708
+performance: 0.651
+debug: 0.613
+vnc: 0.577
+PID: 0.528
+arm: 0.482
+files: 0.445
+graphic: 0.440
+VMM: 0.436
+kernel: 0.431
+semantic: 0.417
+socket: 0.417
+hypervisor: 0.397
+permissions: 0.354
+TCG: 0.341
+ppc: 0.337
+mistranslation: 0.332
+boot: 0.317
+register: 0.297
+i386: 0.244
+x86: 0.197
+risc-v: 0.168
+peripherals: 0.150
+user-level: 0.098
+assembly: 0.047
+KVM: 0.020
+
+qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend
diff --git a/results/classifier/118/device/972 b/results/classifier/118/device/972
new file mode 100644
index 00000000..b5c8b029
--- /dev/null
+++ b/results/classifier/118/device/972
@@ -0,0 +1,31 @@
+device: 0.863
+network: 0.525
+register: 0.411
+boot: 0.360
+ppc: 0.309
+arm: 0.307
+graphic: 0.266
+performance: 0.258
+semantic: 0.245
+mistranslation: 0.196
+vnc: 0.174
+permissions: 0.141
+debug: 0.138
+risc-v: 0.134
+user-level: 0.103
+files: 0.086
+i386: 0.062
+virtual: 0.055
+x86: 0.043
+architecture: 0.030
+assembly: 0.029
+VMM: 0.028
+socket: 0.025
+peripherals: 0.025
+PID: 0.024
+TCG: 0.016
+hypervisor: 0.005
+kernel: 0.004
+KVM: 0.002
+
+LSI SCSI Use After Free (CVE-2022-0216)
diff --git a/results/classifier/118/device/975 b/results/classifier/118/device/975
new file mode 100644
index 00000000..fc7ccc17
--- /dev/null
+++ b/results/classifier/118/device/975
@@ -0,0 +1,68 @@
+device: 0.874
+performance: 0.849
+hypervisor: 0.835
+semantic: 0.814
+architecture: 0.798
+socket: 0.781
+graphic: 0.756
+x86: 0.738
+virtual: 0.726
+network: 0.694
+ppc: 0.667
+files: 0.628
+risc-v: 0.614
+boot: 0.604
+VMM: 0.604
+PID: 0.598
+kernel: 0.597
+arm: 0.589
+register: 0.547
+vnc: 0.500
+KVM: 0.487
+i386: 0.483
+permissions: 0.467
+peripherals: 0.466
+TCG: 0.426
+mistranslation: 0.406
+user-level: 0.380
+debug: 0.342
+assembly: 0.311
+
+LXD with QEMU 6.2.0 (and 7.0.0-rc3) breaks during stateful migration
+Description of problem:
+
+Steps to reproduce:
+```
+sudo snap install --lxd
+sudo lxd init --auto
+lxc init images:ubuntu/20.04/cloud v1 --vm
+Creating v1
+lxc config device override v1 root size.state=2GiB
+Device root overridden for v1
+lxc config set v1 migration.stateful=true
+lxc start v1
+sleep 10
+lxc exec v1 -- uptime
+ 22:05:54 up 0 min,  0 users,  load average: 0.07, 0.02, 0.00
+lxc snapshot v1 --stateful
+Error: Migration call failed
+lxc snapshot v1 --stateful
+Error: Monitor is disconnected
+```
+
+The first attempt at `lxc snapshot v1 --stateful` caused this in the `lxc info v1 --show-log` log output:
+
+```
+qemu-system-x86_64: qemu_savevm_state_complete_precopy_non_iterable: bdrv_inactivate_all() failed (-1)
+```
+
+The second attempt caused this:
+
+```
+qemu-system-x86_64: ../block.c:6757: bdrv_inactivate_recurse: Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed.
+```
+
+Which crashed QEMU completely and caused the VM to die.
+Nothing relevant showed up in dmesg, so this wasn't caused by an obvious seccomp or apparmor policy issue.
+Additional information:
+Originally reported by Stephane Graber at https://github.com/lxc/lxd/issues/9875
diff --git a/results/classifier/118/device/977 b/results/classifier/118/device/977
new file mode 100644
index 00000000..c38d3086
--- /dev/null
+++ b/results/classifier/118/device/977
@@ -0,0 +1,31 @@
+device: 0.834
+performance: 0.763
+network: 0.490
+arm: 0.481
+architecture: 0.336
+semantic: 0.323
+register: 0.311
+boot: 0.310
+user-level: 0.274
+graphic: 0.272
+peripherals: 0.267
+debug: 0.265
+ppc: 0.261
+risc-v: 0.237
+socket: 0.236
+hypervisor: 0.234
+permissions: 0.219
+vnc: 0.216
+mistranslation: 0.204
+files: 0.200
+PID: 0.155
+VMM: 0.134
+virtual: 0.133
+assembly: 0.104
+kernel: 0.071
+TCG: 0.050
+KVM: 0.009
+x86: 0.007
+i386: 0.005
+
+QEMU 6.2, windows 98 doesn't shutdown properly
diff --git a/results/classifier/118/device/978 b/results/classifier/118/device/978
new file mode 100644
index 00000000..868d2836
--- /dev/null
+++ b/results/classifier/118/device/978
@@ -0,0 +1,31 @@
+device: 0.849
+peripherals: 0.576
+performance: 0.547
+graphic: 0.495
+network: 0.480
+architecture: 0.413
+arm: 0.366
+semantic: 0.308
+i386: 0.214
+user-level: 0.185
+virtual: 0.175
+debug: 0.171
+x86: 0.145
+boot: 0.142
+mistranslation: 0.141
+ppc: 0.121
+register: 0.099
+risc-v: 0.075
+hypervisor: 0.065
+socket: 0.048
+PID: 0.047
+permissions: 0.044
+vnc: 0.041
+assembly: 0.041
+VMM: 0.030
+TCG: 0.024
+files: 0.019
+kernel: 0.008
+KVM: 0.001
+
+Running QEMU with "-vga help" crashes if there is no default VGA card
diff --git a/results/classifier/118/device/985288 b/results/classifier/118/device/985288
new file mode 100644
index 00000000..49d7b1e4
--- /dev/null
+++ b/results/classifier/118/device/985288
@@ -0,0 +1,40 @@
+device: 0.824
+architecture: 0.692
+vnc: 0.626
+performance: 0.497
+files: 0.458
+boot: 0.437
+semantic: 0.427
+risc-v: 0.421
+register: 0.394
+VMM: 0.377
+socket: 0.350
+mistranslation: 0.335
+TCG: 0.315
+graphic: 0.313
+ppc: 0.309
+PID: 0.275
+kernel: 0.258
+debug: 0.185
+permissions: 0.137
+i386: 0.130
+arm: 0.129
+user-level: 0.111
+assembly: 0.090
+x86: 0.078
+virtual: 0.074
+network: 0.066
+peripherals: 0.038
+KVM: 0.035
+hypervisor: 0.012
+
+scsi disk emulation doesn't enforce FUA (Force Unit Access) in write-back mode
+
+Microsoft NTFS utilizes the FUA bit in SCSI WRITE CDBs to insure integrity when a device advertises that it has write caching enabled.  The FUA bit is meant to ensure a write is written to non-volatile storage before returning.  This seems to not be enforced by QEMU's SCSI emulation code.
+
+Can you still reproduce this problem with the latest version of QEMU?
+
+Closing since there hasn't been any response within the last 7 months
+
+Fixed in 1.1 (commit 7e8c49c56154ab5c45d4f07edf0c22728735da35). :)
+
diff --git a/results/classifier/118/device/989504 b/results/classifier/118/device/989504
new file mode 100644
index 00000000..e2fbd9f5
--- /dev/null
+++ b/results/classifier/118/device/989504
@@ -0,0 +1,58 @@
+device: 0.852
+i386: 0.831
+peripherals: 0.752
+debug: 0.552
+graphic: 0.548
+architecture: 0.454
+socket: 0.447
+PID: 0.378
+semantic: 0.373
+performance: 0.372
+boot: 0.364
+ppc: 0.336
+network: 0.329
+mistranslation: 0.263
+user-level: 0.256
+permissions: 0.254
+vnc: 0.242
+x86: 0.210
+files: 0.202
+VMM: 0.163
+register: 0.154
+TCG: 0.128
+hypervisor: 0.119
+kernel: 0.114
+arm: 0.108
+risc-v: 0.107
+virtual: 0.100
+assembly: 0.026
+KVM: 0.010
+
+assertion failed when attaching USB MSD device
+
+version: git rev be5ea8ed4481f0ffa4ea0f7ba13e465701536001
+commandline: qemu-system-i386 -usb -fda dosusb.img -drive if=none,id=usbstick,file=usb.img -device usb-storage,bus=usb.0,drive=usbstick -boot a -L d:\_programs\qemu
+
+---------------------------
+Microsoft Visual C++ Runtime Library
+---------------------------
+Assertion failed!
+
+Program: E:\qemu-system-i386.exe
+File: C:/msys/home/User/qemu/hw/usb/hcd-uhci.c
+Line: 968
+
+Expression: ret == TD_RESULT_ASYNC_START
+
+For information on how your program can cause an assertion
+failure, see the Visual C++ documentation on asserts
+
+(Press Retry to debug the application - JIT must be enabled)
+---------------------------
+Abort   Retry   Ignore   
+---------------------------
+
+Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/device/991 b/results/classifier/118/device/991
new file mode 100644
index 00000000..b3c2f7fa
--- /dev/null
+++ b/results/classifier/118/device/991
@@ -0,0 +1,36 @@
+device: 0.896
+vnc: 0.807
+network: 0.800
+mistranslation: 0.729
+risc-v: 0.619
+semantic: 0.614
+graphic: 0.600
+PID: 0.587
+VMM: 0.550
+debug: 0.538
+TCG: 0.508
+ppc: 0.485
+performance: 0.474
+architecture: 0.452
+arm: 0.436
+boot: 0.413
+i386: 0.358
+virtual: 0.356
+files: 0.351
+x86: 0.351
+peripherals: 0.309
+register: 0.299
+permissions: 0.290
+socket: 0.286
+hypervisor: 0.150
+assembly: 0.146
+user-level: 0.118
+kernel: 0.064
+KVM: 0.006
+
+Failed to get write lock on qcow2 image from a sigkilled vm
+Additional information:
+That feature will solve an issue i have with qemu that i muself created 
+by sending a `kill -9` to a qemu VM after it stopped accepting vnc connections.
+I can't use the same qcow2 image currently. Maybe a reboot will fix it, but i did 
+check `lslocks` and there was no lock on it there.
diff --git a/results/classifier/118/device/994 b/results/classifier/118/device/994
new file mode 100644
index 00000000..d4d34e20
--- /dev/null
+++ b/results/classifier/118/device/994
@@ -0,0 +1,35 @@
+device: 0.823
+graphic: 0.719
+socket: 0.695
+architecture: 0.628
+debug: 0.526
+performance: 0.512
+kernel: 0.475
+network: 0.471
+vnc: 0.426
+register: 0.396
+VMM: 0.381
+boot: 0.377
+arm: 0.354
+PID: 0.344
+TCG: 0.308
+risc-v: 0.307
+files: 0.305
+peripherals: 0.299
+permissions: 0.271
+hypervisor: 0.228
+ppc: 0.220
+semantic: 0.219
+KVM: 0.210
+mistranslation: 0.164
+user-level: 0.158
+assembly: 0.100
+virtual: 0.080
+i386: 0.027
+x86: 0.008
+
+7.0.0-rc4 doesn't launch on Windows
+Description of problem:
+The program immediately exits, without even printing version information (or anything).
+Steps to reproduce:
+1. Run the command above