add 18th iteration of classifier

author: Christian Krinitsin <mail@krinitsin.com> 2025-06-16 16:59:00 +0000
committer: Christian Krinitsin <mail@krinitsin.com> 2025-06-16 16:59:33 +0000
commit: 9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch)
tree: b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/hypervisor
parent: b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download: emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz
emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip
39 files changed, 4626 insertions, 0 deletions
diff --git a/results/classifier/118/hypervisor/1035 b/results/classifier/118/hypervisor/1035
new file mode 100644
index 00000000..752b05b0
--- /dev/null
+++ b/results/classifier/118/hypervisor/1035
@@ -0,0 +1,46 @@
+hypervisor: 0.976
+KVM: 0.969
+architecture: 0.911
+kernel: 0.873
+device: 0.837
+graphic: 0.800
+network: 0.713
+register: 0.688
+PID: 0.667
+virtual: 0.645
+performance: 0.610
+permissions: 0.601
+files: 0.557
+arm: 0.549
+semantic: 0.546
+ppc: 0.519
+debug: 0.514
+risc-v: 0.443
+TCG: 0.442
+boot: 0.427
+VMM: 0.391
+peripherals: 0.389
+socket: 0.372
+vnc: 0.318
+user-level: 0.306
+mistranslation: 0.232
+x86: 0.156
+assembly: 0.098
+i386: 0.058
+
+Hyper-V on KVM does not work on AMD CPUs
+Description of problem:
+Can not enable hytper-v on KVM on AMD 3970x
+```
+[ 3743.647780] SVM: kvm [17094]: vcpu0, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.014046] SVM: kvm [17094]: vcpu1, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.016101] SVM: kvm [17094]: vcpu2, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.018011] SVM: kvm [17094]: vcpu3, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.020032] SVM: kvm [17094]: vcpu4, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.021834] SVM: kvm [17094]: vcpu5, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.023644] SVM: kvm [17094]: vcpu6, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+[ 3744.025478] SVM: kvm [17094]: vcpu7, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0
+```
+Additional information:
+Related issue:
+https://bugzilla.kernel.org/show_bug.cgi?id=203477
diff --git a/results/classifier/118/hypervisor/1057 b/results/classifier/118/hypervisor/1057
new file mode 100644
index 00000000..4695c70f
--- /dev/null
+++ b/results/classifier/118/hypervisor/1057
@@ -0,0 +1,53 @@
+hypervisor: 0.836
+architecture: 0.699
+semantic: 0.521
+device: 0.491
+register: 0.390
+arm: 0.389
+performance: 0.369
+debug: 0.344
+assembly: 0.282
+graphic: 0.233
+network: 0.207
+x86: 0.185
+virtual: 0.160
+user-level: 0.156
+kernel: 0.136
+mistranslation: 0.133
+i386: 0.120
+ppc: 0.103
+peripherals: 0.083
+socket: 0.065
+KVM: 0.060
+risc-v: 0.056
+vnc: 0.056
+permissions: 0.052
+boot: 0.050
+PID: 0.042
+VMM: 0.039
+TCG: 0.030
+files: 0.014
+
+AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions
+Description of problem:
+I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction:
+`0x0000000000000000:  C3 44 00 B8    str   w3, [x6], #4`
+
+notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting.
+
+Here is the relevant part of the manual:
+
+```
+For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts:
+• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback).
+```
+
+However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions.
+
+Another example of instruction: `0x00000000000002f8:  01 1C 40 38    ldrb  w1, [x0, #1]!`
+Steps to reproduce:
+1. Run some hypervisor in EL2
+2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP)
+3. Observe the value of ESR_EL2 on data abort
+
+Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch.
diff --git a/results/classifier/118/hypervisor/1135567 b/results/classifier/118/hypervisor/1135567
new file mode 100644
index 00000000..e965cae6
--- /dev/null
+++ b/results/classifier/118/hypervisor/1135567
@@ -0,0 +1,68 @@
+hypervisor: 0.977
+performance: 0.944
+architecture: 0.942
+KVM: 0.938
+virtual: 0.938
+graphic: 0.930
+kernel: 0.925
+semantic: 0.888
+mistranslation: 0.883
+network: 0.881
+peripherals: 0.879
+device: 0.877
+user-level: 0.876
+PID: 0.839
+register: 0.829
+risc-v: 0.790
+permissions: 0.784
+arm: 0.781
+boot: 0.781
+VMM: 0.770
+debug: 0.761
+ppc: 0.761
+socket: 0.700
+files: 0.697
+x86: 0.691
+assembly: 0.687
+vnc: 0.666
+TCG: 0.635
+i386: 0.406
+
+QXL crashes a Windows 7 guest if host goes into screensaver
+
+Note: if further information is required, I'll be glad to supply it.
+
+I am using on the host
+- HP z800 with 72GB RAM and 2x x5680
+- Gentoo 64-bit host (3.7.9 kernel, FGLRX RADEON driver 13.1)
+- LIBVIRT 1.0.2 with QEMU(-KVM) 1.4.0
+
+The guest:
+- Windows 7 32-bit
+- 2GB allocated
+- 2 CPU
+- using virtio for everything (disk,net,memballoon)
+- Display = SPICE with spice channel
+- Video driver is qxl (ram says 64MB)
+- Spice-guest-tools 0.52 installed
+
+When I use QXL and  have the guest open in Virt-Manager/Virt-Viewer and let the host go into screensaver mode, the Win7 crashes hard.
+
+When I change video to VGA, it survives the screen saver,  no problem at all ,smooth sailing.
+
+regards
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+Hello, 
+
+Obviously my hardware configuration and versions etc. have changed. 
+
+Also, I have taken to not using screensavers in the virtual machines anymore i.e. disabled.
+
+BUT: I have set it up as similarly as possible and the crash/freeze/hang up with current versions of the drivers seems to be gone.
+
+So I guess the ticket can be closed.
+
+Thanks for checking! ... so I'm closing this ticket now.
+
diff --git a/results/classifier/118/hypervisor/1138 b/results/classifier/118/hypervisor/1138
new file mode 100644
index 00000000..f62ec9f0
--- /dev/null
+++ b/results/classifier/118/hypervisor/1138
@@ -0,0 +1,31 @@
+hypervisor: 0.908
+KVM: 0.873
+architecture: 0.808
+device: 0.692
+performance: 0.578
+graphic: 0.516
+virtual: 0.503
+network: 0.490
+debug: 0.423
+semantic: 0.271
+user-level: 0.217
+permissions: 0.176
+mistranslation: 0.172
+boot: 0.159
+ppc: 0.117
+vnc: 0.109
+files: 0.091
+arm: 0.077
+register: 0.074
+x86: 0.057
+risc-v: 0.054
+TCG: 0.042
+assembly: 0.022
+kernel: 0.021
+PID: 0.021
+peripherals: 0.020
+socket: 0.017
+i386: 0.010
+VMM: 0.005
+
+Not able to get KVM in qemu-system-s390x built from 6.2.0 source on Fedora 31
diff --git a/results/classifier/118/hypervisor/1201447 b/results/classifier/118/hypervisor/1201447
new file mode 100644
index 00000000..0bc6c87d
--- /dev/null
+++ b/results/classifier/118/hypervisor/1201447
@@ -0,0 +1,58 @@
+hypervisor: 0.982
+KVM: 0.978
+virtual: 0.940
+peripherals: 0.924
+device: 0.922
+files: 0.915
+performance: 0.726
+architecture: 0.700
+PID: 0.685
+graphic: 0.669
+ppc: 0.663
+kernel: 0.651
+register: 0.645
+semantic: 0.630
+mistranslation: 0.623
+user-level: 0.618
+permissions: 0.537
+socket: 0.536
+network: 0.462
+vnc: 0.459
+boot: 0.446
+VMM: 0.422
+x86: 0.329
+debug: 0.312
+risc-v: 0.299
+TCG: 0.274
+assembly: 0.244
+arm: 0.220
+i386: 0.220
+
+Blue screen when disk uses cache='writeback'
+
+I am running Windows 2008R2 as KVM guest on Ubuntu 12.04 hypervisor. Disk controller and network card are virtio devices with drivers from https://launchpad.net/kvm-guest-drivers-windows/+download (virtio-win-drivers-20120712-1.iso).
+Everything worked fine until I changed disk controller cache from the default (writethrough) to writeback. This introduced occasional blue screens. I noticed that they are linked to high disk IO. For example restoring over 1GB of backup files will results in a blue screen on around 4 out of 5 attempts. Also Windows update crashes the system sometimes. When idle the system will run fine for hours or sometimes even days.
+After removing cache='writeback' from the config everything came back to normal.
+
+qemu-kvm:
+  Installed: 1.0+noroms-0ubuntu14.8
+  Candidate: 1.0+noroms-0ubuntu14.8
+  Version table:
+ *** 1.0+noroms-0ubuntu14.8 0
+        500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
+        100 /var/lib/dpkg/status
+     1.0+noroms-0ubuntu14.7 0
+        500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages
+     1.0+noroms-0ubuntu13 0
+        500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
+
+
+
+Hi Jacek,
+I haven't seen other writeback related crashes and the info so far isn't enough to debug anything.
+
+Did you get any related host logs on the crashes.
+In dmesg or the guest log in /var/log/libvirt/qemu/<guestname>.log?
+
+[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/hypervisor/1211910 b/results/classifier/118/hypervisor/1211910
new file mode 100644
index 00000000..d9dbaedc
--- /dev/null
+++ b/results/classifier/118/hypervisor/1211910
@@ -0,0 +1,43 @@
+hypervisor: 0.986
+x86: 0.932
+architecture: 0.907
+graphic: 0.888
+performance: 0.828
+device: 0.775
+mistranslation: 0.658
+semantic: 0.642
+register: 0.559
+permissions: 0.542
+network: 0.533
+vnc: 0.528
+virtual: 0.498
+socket: 0.489
+VMM: 0.482
+i386: 0.480
+debug: 0.405
+arm: 0.401
+peripherals: 0.392
+user-level: 0.390
+risc-v: 0.385
+PID: 0.379
+boot: 0.349
+kernel: 0.340
+files: 0.340
+ppc: 0.339
+assembly: 0.275
+TCG: 0.227
+KVM: 0.035
+
+Logical to linear address translation is wrong for 32-bit guests on a 64-bit hypervisor
+
+I run a 64-bit hypervisor in qemu-system-x86_64 (without KVM) and on top of that I have a 32-bit guest. The guest configures the code-segment to have a base of 0x4000_0000 and a limit of 0xFFFF_FFFF with paging disabled. Thus, if a logical address of e.g. 0xC000_0000 is used, it should be translated to 0x0000_0000 (linear and physical), because of the overflow that happens.
+But this does not happen with the described setup. Instead, qemu seems to calculate the logical to linear translation with 64-bit addresses so that no overflow happens. Consequently, the resulting address is 0x1_0000_0000 and this gets written to exitinfo2 in the VMCB structure. This causes trouble for hypervisors that expect the upper 32 bits of exitinfo2 to be 0 for 32-bit guests.
+
+Note also that the exact same setup runs fine on real AMD machines with SVM. That is, the upper 32 bits in exitinfo2 are always 0 because of the overflow.
+
+I've tested that with the latest development version of QEMU (commit 328465fd9f3a628ab320b5959d68d3d49df58fa6).
+
+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/hypervisor/1243968 b/results/classifier/118/hypervisor/1243968
new file mode 100644
index 00000000..d4426021
--- /dev/null
+++ b/results/classifier/118/hypervisor/1243968
@@ -0,0 +1,69 @@
+hypervisor: 0.948
+kernel: 0.912
+graphic: 0.912
+architecture: 0.863
+device: 0.853
+performance: 0.821
+peripherals: 0.812
+ppc: 0.808
+x86: 0.769
+permissions: 0.766
+files: 0.756
+virtual: 0.751
+user-level: 0.730
+PID: 0.714
+VMM: 0.700
+socket: 0.695
+vnc: 0.688
+register: 0.643
+network: 0.642
+semantic: 0.621
+mistranslation: 0.617
+risc-v: 0.600
+i386: 0.576
+arm: 0.567
+debug: 0.566
+assembly: 0.520
+boot: 0.509
+KVM: 0.480
+TCG: 0.476
+
+VMware ESXi on QEmu Kernel Panic
+
+I attempted to install ESXi 5.5 (the free version) into a QEmu 1.6.1 VM. The guest OS does have the svm capabilities, but it appears VMware is trying to do some kind of hypercall that crashes the guest.
+
+There is more information here: https://communities.vmware.com/message/2297382
+
+It seems to me that this stubbed feature should just be disabled if it is unusable. Or at the very least I should be able to disable it at run-time with a command-line argument.
+
+Is there some way to disable all the hypervisor features that makes it very obvious to a guest os that it is running inside a VM? It would be great if I could install a software and it would actually work (even if it's slow with those features disabled).
+
+FYI, my guest OS capabilities are:
+
+# cat /proc/cpuinfo
+processor       : 0
+vendor_id       : AuthenticAMD
+cpu family      : 6
+model           : 2
+model name      : QEMU Virtual CPU version 1.5.3
+stepping        : 3
+microcode       : 0x1000065
+cpu MHz         : 1999.999
+cache size      : 512 KB
+fpu             : yes
+fpu_exception   : yes
+cpuid level     : 4
+wp              : yes
+flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm nopl pni cx16 popcnt hypervisor lahf_lm svm abm sse4a
+bogomips        : 3999.99
+TLB size        : 1024 4K pages
+clflush size    : 64
+cache_alignment : 64
+address sizes   : 40 bits physical, 48 bits virtual
+power management:
+
+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/hypervisor/1352179 b/results/classifier/118/hypervisor/1352179
new file mode 100644
index 00000000..9bf229cd
--- /dev/null
+++ b/results/classifier/118/hypervisor/1352179
@@ -0,0 +1,63 @@
+hypervisor: 0.954
+architecture: 0.906
+kernel: 0.867
+virtual: 0.861
+KVM: 0.838
+x86: 0.828
+device: 0.763
+graphic: 0.688
+performance: 0.656
+ppc: 0.584
+semantic: 0.552
+socket: 0.525
+debug: 0.525
+register: 0.523
+PID: 0.518
+files: 0.509
+assembly: 0.496
+mistranslation: 0.481
+user-level: 0.463
+network: 0.459
+i386: 0.414
+vnc: 0.345
+peripherals: 0.335
+boot: 0.320
+permissions: 0.307
+risc-v: 0.260
+arm: 0.253
+VMM: 0.203
+TCG: 0.167
+
+could not open disk image
+
+After restart the server it's show this error:
+
+Error starting domain: internal error process exited while connecting to monitor: char device redirected to /dev/pts/1
+qemu-kvm: -drive file=/var/lib/nova/instances/b4535ce9-54b5-4581-a906-16b83bf1ba2f/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none: could not open disk image /var/lib/nova/instances/b4535ce9-54b5-4581-a906-16b83bf1ba2f/disk: No such file or directory
+
+the disk info show 
+ qemu-img info disk
+image: disk
+file format: qcow2
+virtual size: 100G (107374182400 bytes)
+disk size: 22G
+cluster_size: 65536
+backing file: /var/lib/nova/instances/_base/b4535ce9-54b5-4581-a906-16b83bf1ba2f
+
+but this file (backing file : /var/lib/nova/instances/_base/b4535ce9-54b5-4581-a906-16b83bf1ba2f) is empty.
+And all the instances cant't find the disk image
+
+We use CentOS release 6.5 (64bit)
+kernel version : 2.6.32-431.11.2.el6.x86_64
+qemu-kvm-0.12.1.2-2.415.el6_5.10.x86_64
+
+virsh version
+Compiled against library: libvirt 0.10.2
+Using library: libvirt 0.10.2
+Using API: QEMU 0.10.2
+Running hypervisor: QEMU 0.12.1
+
+Triaging old bug tickets ... can you still reproduce this problem with the latest release of QEMU? how did you create the disk image?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/hypervisor/1557057 b/results/classifier/118/hypervisor/1557057
new file mode 100644
index 00000000..342c7b1f
--- /dev/null
+++ b/results/classifier/118/hypervisor/1557057
@@ -0,0 +1,108 @@
+hypervisor: 0.868
+KVM: 0.861
+TCG: 0.827
+user-level: 0.820
+ppc: 0.813
+device: 0.811
+peripherals: 0.793
+x86: 0.792
+VMM: 0.789
+vnc: 0.784
+risc-v: 0.780
+i386: 0.777
+virtual: 0.775
+permissions: 0.762
+boot: 0.736
+arm: 0.725
+register: 0.710
+mistranslation: 0.648
+performance: 0.642
+architecture: 0.637
+graphic: 0.633
+semantic: 0.630
+debug: 0.625
+files: 0.624
+network: 0.621
+socket: 0.619
+kernel: 0.615
+assembly: 0.608
+PID: 0.607
+
+Windows 10 guest under qemu cannot wake up from S3 using rtc wake with -no_hpet
+
+Problem : Windows 10 guest cannot wake up from S3 using rtc wake
+
+Steps to reproduce.
+
+1. Boot Windows 10 Guest VM.
+2. Create  scheduled task (using Task Scheduler) to  +5 minutes time  from current time to run notepad and enabling "Wake the computer to run this task" option
+3. Click Start->Power ->Sleep
+4. Guest VM enters suspend mode( screen is black)
+5. Wait 10 minutes - nothing happens
+6. Press key in spicy window
+7. VM resumes
+
+Expected behavior - VM should wake after 5 minutes in step 5.
+
+More information:
+#uname -a
+Linux vm-host 4.4.3-300.fc23.x86_64 #1 SMP Fri Feb 26 18:45:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
+
+# /usr/local/bin/qemu-system-x86_64 --version
+QEMU emulator version 2.5.50, Copyright (c) 2003-2008 Fabrice Bellard
+
+
+-----------------QEMU guest config---------------------
+OPTS="$OPTS -enable-kvm "
+OPTS="$OPTS -name win10_35"
+#OPTS="$OPTS -bios seabios/out/bios.bin"
+OPTS="$OPTS -machine pc-q35-2.4,accel=kvm,usb=off,vmport=off"
+OPTS="$OPTS -cpu Broadwell,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff"
+OPTS="$OPTS -m 4096"
+OPTS="$OPTS -realtime mlock=off"
+OPTS="$OPTS -smp 2,sockets=2,cores=1,threads=1"
+OPTS="$OPTS -uuid e09cbfe5-9016-40b0-a027-62e0d2ef0ba1"
+OPTS="$OPTS -no-user-config"
+OPTS="$OPTS -nodefaults "
+OPTS="$OPTS -rtc base=localtime,driftfix=slew"
+OPTS="$OPTS -global kvm-pit.lost_tick_policy=discard"
+OPTS="$OPTS -no-hpet"
+OPTS="$OPTS -no-shutdown"
+OPTS="$OPTS -global ICH9-LPC.disable_s3=0"
+OPTS="$OPTS -global ICH9-LPC.disable_s4=0"
+OPTS="$OPTS -boot order=c,menu=on,strict=on"
+OPTS="$OPTS -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e"
+OPTS="$OPTS -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1"
+OPTS="$OPTS -device ich9-usb-ehci1,id=usb,bus=pci.2,addr=0x3.0x7"
+OPTS="$OPTS -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.2,multifunction=on,addr=0x3"
+OPTS="$OPTS -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.2,addr=0x3.0x1"
+OPTS="$OPTS -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.2,addr=0x3.0x2"
+OPTS="$OPTS -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4"
+OPTS="$OPTS -drive file=/var/lib/images/win10-run2.qcow2,format=qcow2,if=none,id=drive-sata0-0-0,cache=none"
+OPTS="$OPTS -device ide-hd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0"
+OPTS="$OPTS -drive file=/var/lib/images/diskd.vhd,format=vpc,if=none,id=drive-sata0-0-1"
+OPTS="$OPTS -device ide-hd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1"
+OPTS="$OPTS -drive file=virtio-win.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-2,readonly=on"
+OPTS="$OPTS -device ide-cd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2 "
+OPTS="$OPTS -chardev pty,id=charserial0"
+OPTS="$OPTS -device isa-serial,chardev=charserial0,id=serial0"
+OPTS="$OPTS -chardev spicevmc,id=charchannel0,name=vdagent"
+OPTS="$OPTS -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0"
+OPTS="$OPTS -device usb-tablet,id=input0"
+OPTS="$OPTS -spice port=5901,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on"
+OPTS="$OPTS -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pcie.0,addr=0x1"
+OPTS="$OPTS -device intel-hda,id=sound0,bus=pci.2,addr=0x2"
+OPTS="$OPTS -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0"
+OPTS="$OPTS -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5"
+OPTS="$OPTS -msg timestamp=on"
+OPTS="$OPTS -monitor stdio"
+#OPTS="$OPTS -qmp stdio"
+#OPTS="$OPTS -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios"
+
+/usr/local/bin/qemu-system-x86_64 $OPTS
+
+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/hypervisor/1558 b/results/classifier/118/hypervisor/1558
new file mode 100644
index 00000000..a121aa23
--- /dev/null
+++ b/results/classifier/118/hypervisor/1558
@@ -0,0 +1,51 @@
+hypervisor: 0.979
+i386: 0.905
+device: 0.819
+ppc: 0.699
+graphic: 0.670
+socket: 0.624
+kernel: 0.613
+architecture: 0.601
+register: 0.584
+PID: 0.571
+arm: 0.547
+virtual: 0.538
+vnc: 0.488
+risc-v: 0.436
+files: 0.418
+performance: 0.392
+network: 0.382
+semantic: 0.374
+permissions: 0.365
+boot: 0.341
+debug: 0.320
+peripherals: 0.308
+TCG: 0.266
+user-level: 0.247
+mistranslation: 0.239
+assembly: 0.238
+VMM: 0.209
+x86: 0.146
+KVM: 0.092
+
+Bug checklist for AEHD
+Description of problem:
+There was a discussion on qemu-devel about addition of a new hypervisor, which is essentially a rewrite of linux/kvm, but for windows
+- 202303002 Haito Shan [PATCH 0/6] Adding the Android Emulator hypervisor driver accelerator  
+  https://lore.kernel.org/qemu-devel/CAGD3tSzW1QoAsn+uGjoAkBegLt1iZ=9YWDFcvqbcHMr0S_5kVw@mail.gmail.com/
+
+If the new hypervisor AEHD does not support these, then each of the below may automatically qualify as a feature catchup bug
+1) Nested Virtualization
+2) virtio-GPU/virgl/OpenGL/venus
+3) Vulkan passthrough
+4) Xen emulation on KVM ( a feature also currently under development)   
+  20230302 [phase1-qemu-8.0](https://lore.kernel.org/qemu-devel/20230302123029.153265-1-pbonzini@redhat.com/) [PULL 00/62] i386, misc changes for QEMU 8.0 soft freeze  
+  20230307 [phase2-qemu-8.0](https://lore.kernel.org/qemu-devel/20230307171750.2293175-1-dwmw2@infradead.org/) [PATCH v2 00/27] Enable PV backends with Xen/KVM emulation  
+5) Migration 
+6) others??
+
+perhaps also document if known for certain that there is no intention to catchup to a particular feature.
+Steps to reproduce:
+NA
+Additional information:
+
diff --git a/results/classifier/118/hypervisor/1585840 b/results/classifier/118/hypervisor/1585840
new file mode 100644
index 00000000..6095bb1d
--- /dev/null
+++ b/results/classifier/118/hypervisor/1585840
@@ -0,0 +1,130 @@
+hypervisor: 0.894
+permissions: 0.892
+device: 0.876
+performance: 0.858
+x86: 0.853
+semantic: 0.851
+architecture: 0.836
+vnc: 0.836
+assembly: 0.835
+KVM: 0.835
+peripherals: 0.831
+ppc: 0.827
+TCG: 0.825
+register: 0.824
+user-level: 0.823
+debug: 0.817
+PID: 0.811
+graphic: 0.806
+arm: 0.804
+risc-v: 0.804
+kernel: 0.796
+VMM: 0.796
+network: 0.788
+socket: 0.783
+files: 0.742
+boot: 0.734
+i386: 0.696
+virtual: 0.695
+mistranslation: 0.691
+
+multiprocess program gets incorrect results with qemu arm-linux-user
+
+The attached program can run either in a threaded mode or a multiprocess mode.  It defaults to threaded mode, and switches to multiprocess mode if the first positional argument is "process".  "success" of the test is defined as the final count being seen as 2000000 by both tasks.
+
+In standard linux x86_64 userspace (i7, 4 cores) and in standard armhf userspace (4 cores), the test program consistently completes successfully in both modes.  But with qemu arm-linux-user, the test consistently succeeds in threaded mode and generally fails in multiprocess mode.
+
+The test reflects an essential aspect of how the Free and Open Source project linuxcnc's IPC system works: shared memory regions (created by shmat, but mmap would probably behave the same) contain data and mutexes.  I observed that our testsuite encounters numerous deadlocks and failures when running in an schroot with qemu-user (x86_64 host), and I believe the underlying cause is improper support for atomic operations in a multiprocess model. (the testsuite consistently passes on real hardware)
+
+I observed the same failure at v1.6.0 and master (v2.6.0-424-g287db79), as well as in the outdated Debian version 1:2.1+dfsg-12+deb8u5a.
+
+
+
+Hi. Your test program doesn't work for me running natively (x86-64):
+$ gcc -O -pthread -o /tmp/shmipc-native -static /tmp/shmipc.c
+$ time /tmp/shmipc-native 
+threaded test
+^C
+
+real    929m16.382s
+user    1858m14.140s
+sys     0m2.924s
+
+...I left it running overnight and it still hadn't finished when I got in in the morning, so I killed it.
+
+Do you have a repro case that completes in a more reasonable timescale?
+
+
+I agree.  The test program I originally attached works (completes in way under 1 second) on
+ debian wheezy
+ x86_64
+ i7-4930K
+
+and doesn't work on
+ debian stretch
+ x86_64
+ i7-4790K
+
+The test program should run in well under 1s, even under qemu-user-arm.
+
+The problem with my test program seems to be in the initial synchronization, which is janky because my standalone test program isn't using a proper synchronization primitive to make sure the two threads start incrementing the shared counter at around the same time.  I've attached an updated version which works for me on wheezy x86_64, stretch x86_64, trusty armhf, but not on stretch x86-64 + qemu-user.
+
+
+Typical output:
+ $ ./a.out process
+ multiprocess test
+ starting is_primary=0
+ starting is_primary=1
+ at end, *mem = 2000000
+ at end, *mem = 2000000
+ should be 2000000
+ should be 2000000
+
+Typical failing output under qemu-arm-static:
+
+ $ qemu-arm-static ./a.arm process
+ multiprocess test
+ starting is_primary=0
+ starting is_primary=1
+ at end, *mem = 1010975
+ at end, *mem = 1010975
+ should be 2000000
+ should be 2000000
+
+Note that when qemu-arm-static is restricted to 1 CPU via `tasket`, the frequency of the failure changes from "almost every time" to "one in ten".
+
+Thank you for taking the time to look at my test program.  I apologize that I caused you to waste a day of (CPU) time waiting for the test program to complete.
+
+Latest tests of qemu-arm-static performed with
+$ apt policy qemu-user-static
+qemu-user-static:
+  Installed: 1:2.8+dfsg-6+deb9u3
+  Candidate: 1:2.8+dfsg-6+deb9u3
+  Version table:
+ *** 1:2.8+dfsg-6+deb9u3 500
+        500 http://security.debian.org stretch/updates/main amd64 Packages
+        100 /var/lib/dpkg/status
+     1:2.8+dfsg-6+deb9u2 500
+        500 http://ftp.us.debian.org/debian stretch/main amd64 Packages
+
+
+Thanks for the updated test program. I've now run it and can confirm it still fails in 'process' mode with current head of git:
+
+$ ~/linaro/qemu-from-laptop/qemu/build/all-linux-static/arm-linux-user/qemu-arm /tmp/shmipc-armhf process
+multiprocess test
+starting is_primary=0
+starting is_primary=1
+at end, *mem = 1013192
+at end, *mem = 1013192
+should be 2000000
+should be 2000000
+
+
+
+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/121
+
+
diff --git a/results/classifier/118/hypervisor/1613133 b/results/classifier/118/hypervisor/1613133
new file mode 100644
index 00000000..7bf41943
--- /dev/null
+++ b/results/classifier/118/hypervisor/1613133
@@ -0,0 +1,136 @@
+hypervisor: 0.839
+graphic: 0.812
+vnc: 0.806
+ppc: 0.797
+VMM: 0.788
+KVM: 0.773
+peripherals: 0.767
+virtual: 0.764
+i386: 0.762
+TCG: 0.761
+register: 0.756
+semantic: 0.720
+performance: 0.707
+architecture: 0.699
+debug: 0.692
+arm: 0.689
+permissions: 0.683
+assembly: 0.667
+device: 0.666
+x86: 0.658
+boot: 0.639
+PID: 0.626
+risc-v: 0.618
+user-level: 0.616
+kernel: 0.616
+socket: 0.580
+files: 0.540
+network: 0.539
+mistranslation: 0.520
+
+SLIRP code regression fails to build on OpenBSD
+
+The SLIRP code has regressed between 2.6 and 2.7 and now fails to build on OpenBSD.
+
+cc -I/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2/tcg -I/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2/tcg/i386 -I. -I/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2 -I/home/ports/pobj/
+qemu-2.7.0-rc2/qemu-2.7.0-rc2/include -Islirp -Islirp -I/usr/X11R6/include/pixman-1  -DHAS_LIBSSH2_SFTP_FSYNC -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -W
+strict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common  -I/usr/local/include -I/usr/X11R6/include -Wno-redundant-decls -D
+TIME_MAX=LLONG_MAX -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style
+-definition -Wtype-limits -fstack-protector-strong -I/usr/local/include -I/usr/local/include/p11-kit-1 -I/usr/include -I/usr/local/include  -I/usr/local/include/libpng16 -I/usr/local/inc
+lude/libusb-1.0 -I/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2/tests -MMD -MP -MT slirp/slirp.o -MF slirp/slirp.d -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/inclu
+de -I/usr/local/include -O2 -pipe  -c -o slirp/slirp.o slirp/slirp.c
+In file included from /usr/include/net/if.h:454:0,
+                 from slirp/slirp.c:34:
+/usr/include/net/if_arp.h:47:8: error: redefinition of 'struct arphdr'
+ struct arphdr {
+        ^
+In file included from slirp/slirp.c:29:0:
+slirp/slirp.h:108:8: note: originally defined here
+ struct arphdr {
+        ^
+slirp/slirp.c: In function 'arp_input':
+slirp/slirp.c:790:15: error: 'struct arphdr' has no member named 'ar_tip'
+         if (ah->ar_tip == ah->ar_sip) {
+               ^
+slirp/slirp.c:790:29: error: 'struct arphdr' has no member named 'ar_sip'
+         if (ah->ar_tip == ah->ar_sip) {
+                             ^
+slirp/slirp.c:792:36: error: 'struct arphdr' has no member named 'ar_sip'
+             arp_table_add(slirp, ah->ar_sip, ah->ar_sha);
+                                    ^
+slirp/slirp.c:792:48: error: 'struct arphdr' has no member named 'ar_sha'
+             arp_table_add(slirp, ah->ar_sip, ah->ar_sha);
+
+slirp/slirp.c:796:16: error: 'struct arphdr' has no member named 'ar_tip'
+         if ((ah->ar_tip & slirp->vnetwork_mask.s_addr) ==
+                ^
+slirp/slirp.c:798:19: error: 'struct arphdr' has no member named 'ar_tip'
+             if (ah->ar_tip == slirp->vnameserver_addr.s_addr ||
+                   ^
+slirp/slirp.c:799:19: error: 'struct arphdr' has no member named 'ar_tip'
+                 ah->ar_tip == slirp->vhost_addr.s_addr)
+                   ^
+slirp/slirp.c:802:49: error: 'struct arphdr' has no member named 'ar_tip'
+                 if (ex_ptr->ex_addr.s_addr == ah->ar_tip)
+                                                 ^
+slirp/slirp.c:809:36: error: 'struct arphdr' has no member named 'ar_sip'
+             arp_table_add(slirp, ah->ar_sip, ah->ar_sha);
+                                    ^
+slirp/slirp.c:809:48: error: 'struct arphdr' has no member named 'ar_sha'
+             arp_table_add(slirp, ah->ar_sip, ah->ar_sha);
+                                                ^
+slirp/slirp.c:814:42: error: 'struct arphdr' has no member named 'ar_tip'
+             memcpy(&reh->h_source[2], &ah->ar_tip, 4);
+                                          ^
+slirp/slirp.c:822:23: error: 'struct arphdr' has no member named 'ar_sha'
+             memcpy(rah->ar_sha, reh->h_source, ETH_ALEN);
+                       ^
+slirp/slirp.c:823:16: error: 'struct arphdr' has no member named 'ar_sip'
+             rah->ar_sip = ah->ar_tip;
+                ^
+slirp/slirp.c:823:29: error: 'struct arphdr' has no member named 'ar_tip'
+             rah->ar_sip = ah->ar_tip;
+                             ^
+slirp/slirp.c:824:23: error: 'struct arphdr' has no member named 'ar_tha'
+             memcpy(rah->ar_tha, ah->ar_sha, ETH_ALEN);
+
+slirp/slirp.c:824:35: error: 'struct arphdr' has no member named 'ar_sha'
+             memcpy(rah->ar_tha, ah->ar_sha, ETH_ALEN);
+                                   ^
+slirp/slirp.c:825:16: error: 'struct arphdr' has no member named 'ar_tip'
+             rah->ar_tip = ah->ar_sip;
+                ^
+slirp/slirp.c:825:29: error: 'struct arphdr' has no member named 'ar_sip'
+             rah->ar_tip = ah->ar_sip;
+                             ^
+slirp/slirp.c:830:32: error: 'struct arphdr' has no member named 'ar_sip'
+         arp_table_add(slirp, ah->ar_sip, ah->ar_sha);
+                                ^
+slirp/slirp.c:830:44: error: 'struct arphdr' has no member named 'ar_sha'
+         arp_table_add(slirp, ah->ar_sip, ah->ar_sha);
+                                            ^
+slirp/slirp.c: In function 'if_encap4':
+slirp/slirp.c:910:23: error: 'struct arphdr' has no member named 'ar_sha'
+             memcpy(rah->ar_sha, special_ethaddr, ETH_ALEN - 4);
+                       ^
+slirp/slirp.c:911:24: error: 'struct arphdr' has no member named 'ar_sha'
+             memcpy(&rah->ar_sha[2], &slirp->vhost_addr, 4);
+                        ^
+slirp/slirp.c:914:16: error: 'struct arphdr' has no member named 'ar_sip'
+             rah->ar_sip = slirp->vhost_addr.s_addr;
+                ^
+slirp/slirp.c:917:23: error: 'struct arphdr' has no member named 'ar_tha'
+             memset(rah->ar_tha, 0, ETH_ALEN);
+                       ^
+slirp/slirp.c:920:16: error: 'struct arphdr' has no member named 'ar_tip'
+             rah->ar_tip = iph->ip_dst.s_addr;
+                ^
+gmake: *** [/home/ports/pobj/qemu-2.7.0-rc2/qemu-2.7.0-rc2/rules.mak:59: slirp/slirp.o] Error 1
+*** Error 2 in . (/home/ports/infrastructure/mk/bsd.port.mk:2674 '/home/ports/pobj/qemu-2.7.0-rc2/.build_done')
+*** Error 1 in /home/ports/emulators/qemu (/home/ports/infrastructure/mk/bsd.port.mk:2396 'all')
+
+Patch suggested here: http://patchwork.ozlabs.org/patch/659132/
+
+Fix has been included in QEMU v2.7.0:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=1f8b56e7cebc71d80a
+
diff --git a/results/classifier/118/hypervisor/1647 b/results/classifier/118/hypervisor/1647
new file mode 100644
index 00000000..e0bcc767
--- /dev/null
+++ b/results/classifier/118/hypervisor/1647
@@ -0,0 +1,42 @@
+hypervisor: 0.985
+kernel: 0.957
+risc-v: 0.892
+device: 0.773
+graphic: 0.705
+vnc: 0.629
+architecture: 0.585
+network: 0.551
+ppc: 0.547
+permissions: 0.536
+socket: 0.523
+register: 0.505
+semantic: 0.502
+files: 0.485
+arm: 0.424
+boot: 0.413
+performance: 0.376
+debug: 0.376
+virtual: 0.361
+user-level: 0.324
+mistranslation: 0.316
+VMM: 0.310
+x86: 0.307
+i386: 0.307
+TCG: 0.302
+PID: 0.246
+peripherals: 0.125
+KVM: 0.113
+assembly: 0.100
+
+Potential Bug in RISCV Hypervisor Extension: Timer Interrupt Handling in QEMU v8.0.0-rc1
+Steps to reproduce:
+1. Build and run a simple hypervisor on QEMU v8.0.0-rc1 with the hypervisor extension feature of RISCV.
+2. Set up hideleg, henvcfg, etc., in hypervisor and run the Linux kernel.
+3. Observe the issue of infinite loop caused by the pending timer interrupt.
+Additional information:
+Linux version: riscv_aia_v1 from github.com/avpatel/linux
+OpenSBI version: Modified 1.1
+
+I would greatly appreciate it if you could kindly provide some guidance. Is this behavior expected or could this be a bug? I've tried to provide a detailed analysis of my observations, but I'm not 100% certain if my understanding is correct.
+
+Thank you for your time and consideration.
diff --git a/results/classifier/118/hypervisor/1705118 b/results/classifier/118/hypervisor/1705118
new file mode 100644
index 00000000..3c621d4f
--- /dev/null
+++ b/results/classifier/118/hypervisor/1705118
@@ -0,0 +1,188 @@
+hypervisor: 0.859
+virtual: 0.824
+graphic: 0.819
+TCG: 0.801
+vnc: 0.799
+user-level: 0.798
+debug: 0.790
+ppc: 0.776
+assembly: 0.766
+device: 0.758
+mistranslation: 0.755
+KVM: 0.754
+register: 0.753
+semantic: 0.753
+risc-v: 0.746
+permissions: 0.742
+kernel: 0.741
+performance: 0.737
+PID: 0.736
+peripherals: 0.734
+VMM: 0.709
+socket: 0.706
+architecture: 0.702
+arm: 0.683
+network: 0.682
+x86: 0.678
+files: 0.667
+boot: 0.662
+i386: 0.627
+
+qemu user mode: rt signals not implemented for sparc guests
+
+The documentation
+<https://qemu.weilnetz.de/doc/qemu-doc.html#Features> says that
+qemu in user mode supports POSIX signal handling.
+
+Catching SIGSEGV according to POSIX, however, does not work on
+  ppc, ppc64, ppc64le, s390x, sparc64.
+It does work, however, on
+  aarch64, alpha, arm, hppa, m68k, mips, mips64, sh4.
+
+How to reproduce:
+The attached program runs fine (exits with code 0) on
+  - real hardware Linux/PowerPC64 (in 32-bit and 64-bit mode),
+  - real hardware Linux/PowerPC64LE,
+  - qemu-system-s390x emulated Linux/s390x,
+  - real hardware Linux/SPARC64.
+$ gcc -O -Wall testsigsegv.c; ./a.out; echo $?
+0
+
+For ppc:
+$ powerpc-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc
+$ ~/inst-qemu/2.9.0/bin/qemu-ppc testsigsegv-ppc
+$ echo $?
+3
+
+For ppc64:
+$ powerpc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc64
+$ ~/inst-qemu/2.9.0/bin/qemu-ppc64 testsigsegv-ppc64
+$ echo $?
+3
+
+For ppc64le:
+$ powerpc64le-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc64le
+$ ~/inst-qemu/2.9.0/bin/qemu-ppc64le testsigsegv-ppc64le
+$ echo $?
+3
+
+For s390x:
+$ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-s390x
+$ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x
+$ echo $?
+3
+$ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -DAVOID_LINUX_S390X_COMPAT -o testsigsegv-s390x-a
+$ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x-a
+$ echo $?
+0
+So, the test fails here because the Linux/s390x kernel omits the least
+significant 12 bits of the fault address in the 'si_addr' field. But
+qemu-s390x is not compatible with the Linux/s390x behaviour: it puts
+the complete fault address in the 'si_addr' field.
+
+For sparc64:
+$ sparc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-sparc64
+$ ~/inst-qemu/2.9.0/bin/qemu-sparc64 testsigsegv-sparc64
+Segmentation fault (core dumped)
+
+
+
+
+
+
+
+
+
+
+
+
+
+The behaviour in qemu-2.10 is the same as in qemu-2.9.
+
+This is an interesting collection of different bugs:
+ * s390x is missing masking operations, as you describe
+ * ppc is passing the PC of the offending insn, not the data address, into si_addr
+ * sparc fails to record the address of a data fault and so passes 0 into si_addr
+ * sparc also isn't implementing rt_sigaction correctly and so the calls in your test program fail EINVAL (your test program doesn't check the return value from sigaction, so it ploughs ahead and makes the faulting data access with the SIG_DFL behaviour for SEGV, hence the uncaught SEGV).
+
+I'm putting together some patches for these.
+
+
+...and also
+ * SPARC doesn't implement setup_rt_frame(), so it can't deliver RT signals at all.
+That's a bigger missing feature than the rest.
+
+
+Patchset that fixes all the minor parts of this, leaving (probably) just sparc setup_rt_frame/rt_sigreturn:
+https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg00833.html
+
+
+I confirm that in qemu-2.11, the ppc and s390x cases are fixed, however the sparc64 case is still failing:
+
+$ ~/inst-qemu/2.11.0/bin/qemu-ppc testsigsegv-ppc
+$ echo $?
+0
+
+$ ~/inst-qemu/2.11.0/bin/qemu-ppc64 testsigsegv-ppc64
+$ echo $?
+0
+
+$ ~/inst-qemu/2.11.0/bin/qemu-ppc64le testsigsegv-ppc64le
+$ echo $?
+0
+
+$ ~/inst-qemu/2.11.0/bin/qemu-s390x testsigsegv-s390x
+$ echo $?
+0
+$ ~/inst-qemu/2.11.0/bin/qemu-s390x testsigsegv-s390x-a
+$ echo $?
+3
+
+$ ~/inst-qemu/2.11.0/bin/qemu-sparc64 testsigsegv-sparc64
+setup_rt_frame: not implemented
+Segmentation fault (core dumped)
+
+
+I don't suppose anybody's going to get round to implementing RT signals for SPARC any time soon, so let's retitle this bug to track the one remaining issue.
+
+
+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.
+
+
+The situation in version 6.0.0 is the same as in version 2.11.0: The cases ppc, ppc64, ppc64le, s390x are fixed, but the sparc64 executable still crashes.
+
+
+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/311
+
+
diff --git a/results/classifier/118/hypervisor/1712027 b/results/classifier/118/hypervisor/1712027
new file mode 100644
index 00000000..94c3a3b2
--- /dev/null
+++ b/results/classifier/118/hypervisor/1712027
@@ -0,0 +1,83 @@
+hypervisor: 0.984
+device: 0.979
+virtual: 0.946
+user-level: 0.883
+graphic: 0.881
+architecture: 0.864
+socket: 0.860
+ppc: 0.855
+register: 0.852
+performance: 0.810
+kernel: 0.782
+PID: 0.754
+arm: 0.753
+x86: 0.747
+KVM: 0.730
+debug: 0.710
+files: 0.709
+mistranslation: 0.706
+peripherals: 0.689
+VMM: 0.686
+semantic: 0.682
+vnc: 0.682
+TCG: 0.667
+risc-v: 0.656
+boot: 0.634
+network: 0.619
+permissions: 0.613
+assembly: 0.491
+i386: 0.479
+
+qemu: Cryptography adding encrypted disk with luks format failed
+
+I'm using libvirt to attach luks encrypted disk to a running VM. The qemu-monitor-command like the 
+
+following:
+
+{"execute":"object-add","arguments":{"qom-type":"secret","id":"virtio-disk11-luks-secret0","props":{"data":"El7jOYLCZwrij2Mue0q2tA==","keyid":"masterKey0","iv":"J2je0WJjCa89L3iKc1lceg==","format":"base64"}}
+
+the masterKey0 specify the secret which has been created before. 
+
+command above return with error message "Incorrect number of padding bytes XXX found on decrypted 
+
+data". This is triggered by the following code snippets in qemu/crypto/secret.c:
+         
+if (plaintext[ciphertextlen - 1] > 16 ||
+             plaintext[ciphertextlen - 1] > ciphertextlen) {
+             error_setg(errp, "Incorrect number of padding bytes (%d) "
+                     "found on decrypted data",
+                     (int)plaintext[ciphertextlen - 1]); 
+                   …
+         }
+
+The bug is: There is on padding in plaintext if the actual length of the plaintext  decrypted is 
+
+equal to ciphertext.
+
+In this case, the last element in plaintext array may be one of the character in base64 code table 
+
+or other.
+
+I would like to know why length of padding bytes cannot exceed 16 and whether i can remove 
+
+judement: “plaintext[ciphertextlen - 1] > 16” so that I can eliminate the error above. 
+
+Much appreciate it if doubts above is cleared up.
+
+libvirt/qemu version:
+
+# virsh version
+Compiled against library: libvirt 3.0.0
+Using library: libvirt 3.0.0
+Using API: QEMU 3.0.0
+Running hypervisor: QEMU 2.7.1
+
+OS: Ubuntu 12.04 LTS
+
+If the alg is GCRY_CIPHER_AES256 and length of data to be encrypted is multiple of 16 (16/32/48...),the length of encryted data is equal to the raw data. There is no padding and the bug is triggerd.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/hypervisor/1722884 b/results/classifier/118/hypervisor/1722884
new file mode 100644
index 00000000..609b382b
--- /dev/null
+++ b/results/classifier/118/hypervisor/1722884
@@ -0,0 +1,173 @@
+hypervisor: 0.908
+peripherals: 0.901
+risc-v: 0.896
+ppc: 0.885
+TCG: 0.876
+arm: 0.867
+VMM: 0.855
+semantic: 0.852
+user-level: 0.849
+KVM: 0.837
+vnc: 0.836
+x86: 0.835
+permissions: 0.833
+graphic: 0.832
+debug: 0.830
+device: 0.828
+performance: 0.827
+i386: 0.823
+virtual: 0.816
+register: 0.792
+assembly: 0.776
+PID: 0.746
+mistranslation: 0.742
+network: 0.740
+boot: 0.735
+kernel: 0.694
+socket: 0.688
+architecture: 0.683
+files: 0.333
+
+keyboard input while mouse moving triggers mouse failure
+
+When QEMU is getting a ton of mouse input events if keys are pressed on the keyboard the scan code will be corrupted causing erroneous behavior. I have confirmed this problem in the latest version in git (530049bc1dcc24c1178a29d99ca08b6dd08413e0).
+
+After the erroneous behavior the operating system issues a keyboard reset which prevents the mouse from functioning until the operating system is restarted.
+
+This seems to only occur if the PS2 mouse is being used as the input, the tablet input device doesn't exhibit this behavior.
+
+The same problem was reported here also: https://openxt.atlassian.net/browse/OXT-562
+
+Host  : Debian 9
+CPU   : Ryzen 1700X
+RAM   : 16GB
+Kernel: 4.12.0-0.bpo.2-amd64
+
+Guest : Windows 10 (KVM)
+RAM   : 8GB (1GB Huge pages)
+
+Here is a backtrace of the PS2 reset event:
+
+#0  ps2_write_mouse (opaque=0x55804518ae30, val=255) at /home/geoff/Projects/qemu/qemu/hw/input/ps2.c:1033
+#1  0x00005580420e1dd9 in kbd_write_data (opaque=0x558045147aa0, addr=0, val=255, size=1) at /home/geoff/Projects/qemu/qemu/hw/input/pckbd.c:357
+#2  0x0000558041e7e64f in memory_region_write_accessor (mr=0x558045147ae0, addr=0, value=0x7f9ec016f478, size=1, shift=0, mask=255, attrs=...)
+    at /home/geoff/Projects/qemu/qemu/memory.c:560                                                                                            
+#3  0x0000558041e7e867 in access_with_adjusted_size (addr=0, value=0x7f9ec016f478, size=1, access_size_min=1, access_size_max=1,
+    access_fn=0x558041e7e565 <memory_region_write_accessor>, mr=0x558045147ae0, attrs=...) at /home/geoff/Projects/qemu/qemu/memory.c:627
+#4  0x0000558041e814e9 in memory_region_dispatch_write (mr=0x558045147ae0, addr=0, data=255, size=1, attrs=...)
+    at /home/geoff/Projects/qemu/qemu/memory.c:1503                                                            
+#5  0x0000558041e31302 in flatview_write_continue (fv=0x7f9e90010c10, addr=96, attrs=..., buf=0x7f9eee9de000 "\377\006", len=1, addr1=0, l=1,
+    mr=0x558045147ae0) at /home/geoff/Projects/qemu/qemu/exec.c:2900                                                                         
+#6  0x0000558041e31450 in flatview_write (fv=0x7f9e90010c10, addr=96, attrs=..., buf=0x7f9eee9de000 "\377\006", len=1)
+    at /home/geoff/Projects/qemu/qemu/exec.c:2945                                                                     
+#7  0x0000558041e31827 in flatview_rw (fv=0x7f9e90010c10, addr=96, attrs=..., buf=0x7f9eee9de000 "\377\006", len=1, is_write=true)
+    at /home/geoff/Projects/qemu/qemu/exec.c:3054                                                                                 
+#8  0x0000558041e318df in address_space_rw (as=0x558042a4c940 <address_space_io>, addr=96, attrs=..., buf=0x7f9eee9de000 "\377\006", len=1, is_write=true)
+    at /home/geoff/Projects/qemu/qemu/exec.c:3064                                                                                                         
+#9  0x0000558041e9617e in kvm_handle_io (port=96, attrs=..., data=0x7f9eee9de000, direction=1, size=1, count=1)
+    at /home/geoff/Projects/qemu/qemu/accel/kvm/kvm-all.c:1698                                                 
+#10 0x0000558041e968c2 in kvm_cpu_exec (cpu=0x5580444f4650) at /home/geoff/Projects/qemu/qemu/accel/kvm/kvm-all.c:1938
+#11 0x0000558041e670d9 in qemu_kvm_cpu_thread_fn (arg=0x5580444f4650) at /home/geoff/Projects/qemu/qemu/cpus.c:1128
+#12 0x00007f9ed49c5494 in start_thread (arg=0x7f9ec0172700) at pthread_create.c:333
+#13 0x00007f9ed4707aff in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
+
+
+
+Further to this, it appears to be a race condition with reading from the i8042 controller. I have turned on debugging of PS2 and KBD and filtered out the event that causes the issue. I have split the below up to show the valid reads for the mouse and then the sequence that triggers a reset when the keyboard is used.
+
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x08
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x00
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x02
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x00
+
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x18
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0xfe
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x02
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x00
+
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x08
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x00
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x01
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x00
+
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x1d <-- the status changed on the 2nd call.
+KBD: kbd: read status=0x1d
+KBD: kbd: read data=0x9e
+
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x18
+KBD: kbd: read data=0xff <-- two data reads without checking status
+KBD: kbd: read status=0x3d <-- guest looking for mouse movements
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x02   <-- first byte
+KBD: kbd: read status=0x3d
+KBD: kbd: read status=0x3d
+KBD: kbd: read data=0x00   <-- 2nd byte
+KBD: kbd: read status=0x1c <-- no more data, there should be two more bytes
+KBD: kbd: read status=0x1c
+KBD: kbd: read status=0x1c
+
+here the host attempts to reset the device
+
+KBD: kbd: write cmd=0xd4   <-- write to mouse cmd
+KBD: kbd: read status=0x1c
+KBD: kbd: read status=0x1c
+KBD: kbd: read status=0x1c
+KBD: kbd: write data=0xff  <-- reset mouse
+kbd: write mouse 0xff
+
+
+I believe I am onto the cause of this issue, because the input events are coming from a multi threaded source (in my instance spice) keyboard and mouse input share common code paths without any thread interlocking.
+
+Since keyboard input takes priority over mouse, when more mouse events are being handled it is overwriting and swapping out the data the guest was expecting with mouse input data.
+
+In short, there is a race condition here.
+
+This bug needs some attention, we just released Looking Glass which relies heavily on the relative input mode of SPICE which in turn relies heavily on the virtual i8042 controller. This project has the ability to completely eliminate the need to dual boot a Linux machine with windows and is gaining much public attention, if it wasn't for this bug it would be damn near perfect.
+
+Please see:
+
+https://looking-glass.hostfission.com
+https://github.com/gnif/LookingGlass
+https://level1techs.com/video/new-tech-iommu-users-looking-glass-headless-passthrough
+https://www.phoronix.com/scan.php?page=news_item&px=Looking-Glass-KVM-Frame-Relay
+
+I have already tried to trace this down but between Looking Glass and my day job I simply don't have time at the moment.
+
+
+I tried to look into this as well. One finding I have made is that the problem happens for -display gtk but not with -display sdl so I'm thinking it might not be reading of data from the ps2 controller that is problematic but the writing to it. I will need to investigate further.
+
+I tracked this down and fixed it last year, your issue is unrelated.
+
+https://github.com/qemu/qemu/commit/143c04c7e0639e53086519592ead15d2556bfbf2#diff-3b5bd599c018d558b135bd19647a00c6
+
+https://github.com/qemu/qemu/commit/7abe7eb29494b4e4a11ec99ae5623083409a2f1e#diff-3b5bd599c018d558b135bd19647a00c6
+
+Ok, so if this bug has been fixed, let's close this ticket.
+
diff --git a/results/classifier/118/hypervisor/1756927 b/results/classifier/118/hypervisor/1756927
new file mode 100644
index 00000000..d96f24c8
--- /dev/null
+++ b/results/classifier/118/hypervisor/1756927
@@ -0,0 +1,64 @@
+hypervisor: 0.849
+architecture: 0.844
+debug: 0.777
+arm: 0.772
+performance: 0.757
+device: 0.753
+x86: 0.713
+kernel: 0.688
+boot: 0.666
+mistranslation: 0.622
+ppc: 0.614
+risc-v: 0.562
+semantic: 0.554
+graphic: 0.551
+permissions: 0.546
+network: 0.531
+user-level: 0.525
+vnc: 0.523
+socket: 0.491
+VMM: 0.485
+PID: 0.475
+TCG: 0.474
+i386: 0.439
+register: 0.411
+assembly: 0.407
+files: 0.406
+KVM: 0.400
+virtual: 0.345
+peripherals: 0.244
+
+ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT
+
+When a user application triggers a 'bkpt' instruction while LPAE is used, the bit [9] of IFSR is not correctly set during the prefetch abort exception.
+
+You'll find attached a minimal example to reproduce the issue (just run 'make all').
+The output I get is:
+
+supervisor
+user
+prefetch
+short-descriptor
+
+The last entry should read 'long-descriptor'.
+
+
+Qemu revision: 48ae1f60d8c9a770e6da64407984d84e25253c69
+Ubuntu verison: 16.04 LTS
+Cross Compiler: gcc linaro 6.3.1-2017.02-x86_64_arm-eabi
+
+
+
+I've just sent this patchset:
+http://<email address hidden>/
+which should fix this bug and a couple of others that I noticed with our debug exception handling while I was doing that.
+
+
+thanks Peter ! Any news on the review ?
+
+The patches are in master now.
+
+
+Hi Peter,
+we tested the fix and it work correctly now, thank you very much !
+
diff --git a/results/classifier/118/hypervisor/1769189 b/results/classifier/118/hypervisor/1769189
new file mode 100644
index 00000000..89806326
--- /dev/null
+++ b/results/classifier/118/hypervisor/1769189
@@ -0,0 +1,159 @@
+hypervisor: 0.897
+KVM: 0.892
+peripherals: 0.885
+kernel: 0.884
+permissions: 0.882
+virtual: 0.881
+performance: 0.875
+debug: 0.871
+VMM: 0.867
+device: 0.867
+boot: 0.861
+user-level: 0.861
+vnc: 0.859
+architecture: 0.857
+mistranslation: 0.856
+files: 0.853
+x86: 0.849
+PID: 0.838
+semantic: 0.832
+arm: 0.828
+assembly: 0.824
+register: 0.814
+ppc: 0.795
+network: 0.792
+graphic: 0.791
+risc-v: 0.781
+TCG: 0.747
+socket: 0.700
+i386: 0.528
+
+Issue with qemu 2.12.0 + SATA
+
+(first reported here: https://bugzilla.tianocore.org/show_bug.cgi?id=949 )
+
+I had a Windows 10 VM running perfectly fine with OVMF UEFI, since I upgraded to qemu 2.12, the guests hangs for a couple of minutes, works for a few seconds, and hangs again, etc. By "hang" I mean it doesn't freeze, but it looks like it's waiting on IO or something, I can move the mouse but everything needing disk access is unresponsive.
+
+What doesn't work: qemu 2.12 with OVMF
+What works: using BIOS or downgrading qemu to 2.11.1.
+
+Platform is arch linux 4.16.7 on skylake, I have attached the vm xml file.
+
+
+
+I'm seeing the same Win10 I/O stall problem with qemu 2.12, but with a vm with BIOS, not UEFI.
+The solution for me is only dowgrading for now.
+
+I have the same issue. When I open the task manager on the virtualized Windows 10 VM I see the HDD time is at 100% but the data transfer rate is actual 0b/s. 
+I've tried any combination of the options below and the issue was always reproducible with qemu-2.12.0-1 and never with qemu-2.11.1-2.
+
+Linux kernels:
+- 4.14.5-1
+- 4.16.7
+
+Windows 10 Verson (for the VM) 
+- 1709
+- 1803
+
+Boot HDD for VM
+- Actual SSD (/dev/sda)
+- QCOW2 Image
+
+QEMU 
+- qemu-2.11.1-2
+- qemu-2.12.0-1
+
+
+I also use ARCH Linux and have also downgraded to pre 2.12 QEMU
+
+
+I have done some further tests and the problem seems to be SATA, not UEFI, I have updated the bug description to reflect this.
+
+François: Would it be possible for you to try a bisect build to try and figure out which change in qemu caused the problem?
+
+
+For me it is hangs with SATA, but IDE is fine.
+
+Windows 7 Version (for the VM)
+- SP1
+
+Boot HDD for VM
+- Actual HDD (/dev/sda)
+- QCOW2 Image
+
+QEMU
+- qemu-2.12.0-1 
+
+I've tried bisecting a few times, but since my reproducer wasn't reliable enough, I didn't identify the issue. (I see a bisect reported on qemu ML which seems like a bogus result, similar to mine).
+
+In my case, after the "hang", Windows 10 resets the ahci device after 2 minutes and it continues on until another hang happens. Seems fairly random. I increased the number of vcpu's assigned which seemed to increase the likelihood of the hang.
+
+I also went so far as to instrument an injection of the ahci interrupt via the monitor (total kludge, I know), and the guest did get out of the hung condition right away when I did that.
+
+I tried bisecting as well, and I wound up at:
+
+1a423896 -- five out of five boot attempts succeeded.
+d759c951 -- five out of five boot attempts failed.
+
+
+
+d759c951f3287fad04210a52f2dc93f94cf58c7f is the first bad commit
+commit d759c951f3287fad04210a52f2dc93f94cf58c7f
+Author: Alex Bennée <email address hidden>
+Date:   Tue Feb 27 12:52:48 2018 +0300
+
+    replay: push replay_mutex_lock up the call tree
+
+
+
+
+My methodology was to boot QEMU like this:
+
+./x86_64-softmmu/qemu-system-x86_64 -m 4096 -cpu host -M q35 -enable-kvm -smp 4 -drive id=sda,if=none,file=/home/bos/jhuston/windows_10.qcow -device ide-hd,drive=sda -qmp tcp::4444,server,nowait
+
+and run it three times with -snapshot and see if it hung during boot; if it did, I marked the commit bad. If it did not, I booted and attempted to log in and run CrystalDiskMark. If it froze before I even launched CDM, I marked it bad.
+
+Interestingly enough, on a subsequent (presumably bad) commit (6dc0f529) which hangs fairly reliably on bootup (66%) I can occasionally get into Windows 10 and run CDM -- and that unfortunately does not seem to trigger the error again, so CDM doesn't look like a reliable way to trigger the hangs.
+
+
+
+
+Anyway, d759c951 definitely appears to change the odds of AHCI locking up during boot for me, and I suppose it might have something to do with how it is changing the BQL acquisition/release in main-loop.c, but I am not sure why/what yet.
+
+Before this patch, we only lock the iothread and re-lock it if there was a timeout, and after this patch we *always* lock and unlock the iothread. This is probably just exposing some latent bug in the AHCI emulator that has always existed, but now the odds of seeing it are much higher.
+
+I'll have to dig as to what the race is -- I'm not sure just yet.
+
+
+If those of you who are seeing this bug too could confirm for me that d759c951 appears to be the guilty party, that probably wouldn't hurt.
+
+Thanks!
+--js
+
+I can confirm that for me commit d759c951 does cause / expose the issue.
+
+There might be multiple issues present and I'm having difficulty reliably doing any kind of regression testing here, but I think this patch helps fix at least one of the issues I was seeing that occurs specifically during early boot. It may fix other hangs.
+
+
+
+Oughtta be fixed in current master, will be fixed in 2.12.1 and 3.0.
+
+Hi, Where can I find the fix patch at present?
+
+5694c7eacce6b263ad7497cc1bb76aad746cfd4e ahci: fix PxCI register race
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5694c7eacce6b263ad7497cc1bb76aad746cfd4e
+
+Could this affect virtio-scsi? I'm not so sure since it's not perfectly reliable to reproduce, but v2.12.0 was hanging for me for a few minutes at a time with virtio-scsi cache=writeback showing 100% disk util%. I never had issues booting up, and didn't try SATA. v2.11.1 was fine.
+
+My first attempt to bisect didn't turn out right... had some false positives I guess. The 2nd attempt (telling git the bads from first try) got to 89e46eb477113550485bc24264d249de9fd1260a as latest good (which is 4 commits *after* the bisect by John Snow) and 7273db9d28d5e1b7a6c202a5054861c1f0bcc446 as bad.
+
+But testing with this patch, it seems to work (or false positive still... after a bunch of usage). And so I didn't finish the bisect.
+
+The fix posted exclusively changes the behavior of AHCI devices; however the locking changes that jostled the AHCI bug loose could in theory jostle loose some bugs in other devices, too.
+
+I don't think it is possible that the fix for AHCI would have any impact on virtio-scsi devices.
+
+If you're seeing issues in virtio-scsi, I'd make a new writeup in a new LP.
+--js
+
diff --git a/results/classifier/118/hypervisor/1777777 b/results/classifier/118/hypervisor/1777777
new file mode 100644
index 00000000..43662b1d
--- /dev/null
+++ b/results/classifier/118/hypervisor/1777777
@@ -0,0 +1,363 @@
+hypervisor: 0.846
+register: 0.809
+arm: 0.793
+peripherals: 0.775
+mistranslation: 0.766
+semantic: 0.752
+architecture: 0.750
+PID: 0.742
+performance: 0.740
+device: 0.736
+permissions: 0.730
+risc-v: 0.717
+graphic: 0.706
+boot: 0.701
+ppc: 0.697
+virtual: 0.697
+TCG: 0.695
+KVM: 0.691
+user-level: 0.689
+assembly: 0.686
+VMM: 0.681
+vnc: 0.661
+debug: 0.657
+files: 0.641
+network: 0.616
+x86: 0.600
+socket: 0.527
+kernel: 0.524
+i386: 0.365
+
+arm9 clock pending (SP804)
+
+Hello all,
+
+I'm using the versatilepb board and the timer Interrupt Mask Status register (offset 0x14 of the SP804) does not seem to be working properly on the latest qemu-2.12. I tried on the 2.5 (i believe this is the mainstream version that comes with Linux) and it works perfectly.
+
+What happens is that the pending bit does not seem to be set in some scenarios. In my case, I see the timer value decreasing to 0 and then being reset to the reload value and neither does the interrupt is triggered nor the pending bit is set.
+
+I believe this is a matter of timing since in the "long" run the system eventually catches up (after a few microseconds).
+
+Thank you
+
+Do you have a test case image you can provide that reproduces the problem?
+
+
+Hello,
+
+Let me explain a bit how to reproduce the problem. I'm developing a RTOS with qemu (and boards,etc) - https://sourceforge.net/projects/rtospharos/. The first version used ARM926 with the versatilepb board and I used the qemu 2.5 version.
+
+In my test (to check that the RTOS is working correctly) I produced a loop that is always reading the current time ("pharosClockGet") and checking that it is always increasing. This works perfectly on qemu 2.5. When qemu 2.12 was released I updated to the new version to add support for the raspberry pi 3. 
+
+Here is a piece of the test:
+
+
+void aperiodicThread0_0()
+{
+    uint64_t microseconds;
+    uint64_t previousMicroseconds = 0;
+    uint32_t i;
+
+    for(i = 0; i < NUMBER_REPETITIONS; i++)
+    {
+        microseconds = pharosClockGetSinceBoot();
+        if(previousMicroseconds > microseconds) 
+        {
+            print("ERROR! Clock got lower\r\n");
+            break;
+        }
+    }
+}
+
+
+I'll show you the "internals" of Pharos next (this is file clock.c):
+
+
+uint64_t pharosIClockGetSinceBoot(void)
+{
+    /* microseconds since last clock tick*/
+    uint32_t microseconds;
+
+    /* number of clock ticks since boot */
+    ClockTick clockTicks;
+
+    /* >> interrupts are disabled when we get here << */
+
+    /* read the number of microseconds on the counter */
+    clockTicks = pharosVClockTicks;
+
+    /* read the timer value */
+    microseconds = pharosCpuClockReadCounter();
+
+    /* if the clock interrupt is pending we might have read the microseconds before or after the clock tick occurred (but not processed since interrupts are disabled) */
+    if(pharosCpuClockIsrIsPending() == TRUE)
+    {
+        /* interrupt is pending, so read again the microseconds and subtract 2 clock ticks */
+        microseconds = (2U * pharosIMicrosecondsPerClockTick()) - pharosCpuClockReadCounter();
+    }
+    else
+    {
+        /* the timer counts backwards so we must subtract to get the number of microseconds since last tick */
+        microseconds = pharosIMicrosecondsPerClockTick() - microseconds;
+    }
+
+    /* calculate the result using the last us read */
+    return (uint64_t) ((pharosIMicrosecondsPerClockTick() * clockTicks) + microseconds);
+}
+
+
+And the part that is hw dependent (for ARM926) - this is in file ClockSp804.h: 
+
+INLINE bool armSp804TimerInterruptIsPending(const ptrArmSp804Timer c)
+{
+        /* get the first bit of the interrupt status (ignore other bits) to check if the interrupt is pending */
+        return (c->timerInterruptMaskStatus & 0x1U) == 1U ? TRUE : FALSE;
+}
+
+
+I hope the code is easy enough to read.
+Thank you
+
+
+Sorry, I should have been clearer. Please can you provide a test case binary and QEMU command line that reproduces the problem (including what the expected output is and what the actual output is)? 
+
+Mark this bug as Incomplete as we're still waiting for the test case binary and command line to reproduce it.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+Sorry to have taken some time to answer.
+
+Created the binary with the test.
+
+Here is the output when it fails (tested in Qemu 2.12):
+
+Checked 0 times if the time is always increasing
+Checked 100000 times if the time is always increasing
+Checked 200000 times if the time is always increasing
+Checked 300000 times if the time is always increasing
+Checked 400000 times if the time is always increasing
+Checked 500000 times if the time is always increasing
+Checked 600000 times if the time is always increasing
+Checked 700000 times if the time is always increasing
+Error: the time read is smaller than the previous time read
+
+
+And here with the latest Qemu (4.1.0):
+
+Checked 0 times if the time is always increasing
+Checked 100000 times if the time is always increasing
+Error: the time read is smaller than the previous time read
+
+
+
+The error can occur basically at any time. But when tested with Qemu 2.5 it goes well:
+
+Checked 0 times if the time is always increasing
+Checked 100000 times if the time is always increasing
+Checked 200000 times if the time is always increasing
+Checked 300000 times if the time is always increasing
+Checked 400000 times if the time is always increasing
+Checked 500000 times if the time is always increasing
+Checked 600000 times if the time is always increasing
+Checked 700000 times if the time is always increasing
+Checked 800000 times if the time is always increasing
+Checked 900000 times if the time is always increasing
+Checked 1000000 times if the time is always increasing
+Checked 1100000 times if the time is always increasing
+Checked 1200000 times if the time is always increasing
+Checked 1300000 times if the time is always increasing
+Checked 1400000 times if the time is always increasing
+Checked 1500000 times if the time is always increasing
+Checked 1600000 times if the time is always increasing
+Checked 1700000 times if the time is always increasing
+Checked 1800000 times if the time is always increasing
+Checked 1900000 times if the time is always increasing
+Checked 2000000 times if the time is always increasing
+Checked 2100000 times if the time is always increasing
+Checked 2200000 times if the time is always increasing
+Checked 2300000 times if the time is always increasing
+Checked 2400000 times if the time is always increasing
+Checked 2500000 times if the time is always increasing
+Checked 2600000 times if the time is always increasing
+Checked 2700000 times if the time is always increasing
+Checked 2800000 times if the time is always increasing
+Checked 2900000 times if the time is always increasing
+.
+.
+.
+Checked 9500000 times if the time is always increasing
+Checked 9600000 times if the time is always increasing
+Checked 9700000 times if the time is always increasing
+Checked 9800000 times if the time is always increasing
+Checked 9900000 times if the time is always increasing
+Example finished
+
+
+
+Just to give some background on the test itself, the main.c file contains this:
+
+void helloWorld0()
+{
+    uint64_t microseconds;
+    uint64_t previousMicroseconds = 0;
+    uint32_t i;
+
+    for(i = 0; i < NUMBER_REPETITIONS; i++)
+    {
+        microseconds = pharosClockGetSinceBoot();
+
+        if(microseconds < previousMicroseconds)
+        {
+            printk("Error: the time read is smaller than the previous time read\r\n");
+            pharosThreadSuspendSelf();
+        }
+
+        previousMicroseconds = microseconds;
+
+        /* only print 100 times the message */
+        if(i % (NUMBER_REPETITIONS / 100) == 0)
+        {
+            printk("Checked %d times if the time is always increasing\r\n" , i);
+        }
+    }
+
+    printk("Example finished\r\n");
+    pharosThreadSuspendSelf();
+}
+
+
+And where I suspect the code is reading the wrong hardware level is here:
+
+bool pharosCpuClockIsrIsPending(void)
+{
+    /* apparently QEMU has a bug when it comes to reading the SP804 interrupt status. It seems that we have to read
+      it multiple times in order for it to give the correct result since it does not update the interrupt status 
+      of the SP804 when it should. Qemu 2.5 did not have this problem but at least Qemu 2.12, 3.1 and 4.1.0 have this
+      problem. So we just create a work-around for it. */
+#if 0
+
+    /* number of times to read it. */
+#define N 100
+
+    uint32_t i;
+
+    /* read the interrupts status a lot of times to wait for QEMU to update the status */
+    for(i = 0; i < N; i++)
+    {
+        /* if there is an interrupt */
+        if(armSp804TimerInterruptIsPending(TIMER1_BASE_ADDRESS) == TRUE)
+        {
+            /* return right away */
+            return TRUE;
+        }
+    }
+
+    /* read the status a LOT of times, there is no interrupt pending */
+    return FALSE;
+
+    /* On a real hardware this problem should not occur so we only have to read it once */
+#else
+    /* read the SP804 timer interrupt pending info */
+    return armSp804TimerInterruptIsPending(TIMER1_BASE_ADDRESS);
+#endif
+}
+
+that is, the armSp804TimerInterruptIsPending is not correctly returning if the timer1 has a pending interrupt (even though I check the timer load value and it was reset just before and no interrupt was raised - interrupts disabled)
+
+
+Forgot to state the qemu argument, it's this one:
+
+~/cross-compiler/qemu/2.5/bin/qemu-system-arm -M versatilepb -m 128M -nographic -kernel myApplication
+
+
+Thanks for the repro case. Preliminary analysis: I added some tracepoints to the sp804 code, and you're right that the value of the interrupt status register isn't always correct:
+
+A normal attempt to read the clock looks like this:
+
+Taking exception 2 [SVC]
+...from EL0 to EL1
+...with ESR 0x11/0x4600000b
+AArch32 mode switch from svc to sys PC 0x12010
+AArch32 mode switch from sys to svc PC 0x12018
+32696@1569513406.450378:sp804_read addr 0x00000004 value 0x00000681
+32696@1569513406.450384:sp804_read addr 0x00000014 value 0x00000000
+Exception return from AArch32 svc to usr PC 0x10ff0
+
+Sometimes we might read the clock when it's exactly got down to 0 (this is more likely on QEMU than on real h/w for internal reasons of our implementation):
+Taking exception 2 [SVC]
+...from EL0 to EL1
+...with ESR 0x11/0x4600000b
+AArch32 mode switch from svc to sys PC 0x12010
+AArch32 mode switch from sys to svc PC 0x12018
+32696@1569513406.452273:sp804_read addr 0x00000004 value 0x00000000
+32696@1569513406.452279:sp804_read addr 0x00000014 value 0x00000000
+Exception return from AArch32 svc to usr PC 0x10ff0
+
+A correct handling of the rollover looks like this (we read the counter, which is rolled over, and the interrupt-status, which is 1, which causes us to reread the counter; once we're done the IRQ handler itself runs):
+
+4003@1569514474.944756:sp804_read addr 0x00000004 value 0x0000c29d
+4001@1569514474.944761:sp804_arm_timer_update level 1
+4003@1569514474.944797:sp804_read addr 0x00000014 value 0x00000001
+4003@1569514474.944828:sp804_read addr 0x00000004 value 0x0000c255
+Taking exception 5 [IRQ]
+...from EL1 to EL1
+...with ESR 0x11/0x4600000b
+AArch32 mode switch from irq to svc PC 0x2a5e4
+4003@1569514474.944943:sp804_read addr 0x00000014 value 0x00000001
+4003@1569514474.944957:sp804_read addr 0x00000034 value 0x00000000
+4003@1569514474.944962:sp804_read addr 0x00000014 value 0x00000001
+4003@1569514474.944965:sp804_write addr 0x0000000c value 0x00000000
+4003@1569514474.944966:sp804_arm_timer_update level 0
+4003@1569514474.944969:sp804_read addr 0x00000034 value 0x00000000
+AArch32 mode switch from svc to irq PC 0x2a718
+Exception return from AArch32 irq to svc PC 0x2a3bc
+Exception return from AArch32 svc to usr PC 0x10ff0
+
+But sometimes we get this, where we read the rolled-over counter value but the interrupt-status register is still 0:
+
+Taking exception 2 [SVC]
+...from EL0 to EL1
+...with ESR 0x11/0x4600000b
+AArch32 mode switch from svc to sys PC 0x12010
+AArch32 mode switch from sys to svc PC 0x12018
+4003@1569514475.794690:sp804_read addr 0x00000004 value 0x0000c2df
+4003@1569514475.794698:sp804_read addr 0x00000014 value 0x00000000
+4001@1569514475.794703:sp804_arm_timer_update level 1
+Exception return from AArch32 svc to usr PC 0x10ff0
+Taking exception 5 [IRQ]
+...from EL0 to EL1
+...with ESR 0x11/0x4600000b
+AArch32 mode switch from irq to svc PC 0x2a5e4
+4003@1569514475.794768:sp804_read addr 0x00000014 value 0x00000001
+4003@1569514475.794937:sp804_read addr 0x00000034 value 0x00000000
+4003@1569514475.794944:sp804_read addr 0x00000014 value 0x00000001
+4003@1569514475.794947:sp804_write addr 0x0000000c value 0x00000000
+4003@1569514475.794949:sp804_arm_timer_update level 0
+4003@1569514475.794952:sp804_read addr 0x00000034 value 0x00000000
+AArch32 mode switch from svc to irq PC 0x2a718
+Exception return from AArch32 irq to usr PC 0x10ff0
+
+
+
+This happens because the sp804 uses a QEMU timer abstraction "ptimer". The ptimer updates its internal state when a raw QEMU timer expires and calls the ptimer_tick() function. From this point on, a guest read of the counter value will get the rolled-over value, because the sp804 implements this as a simple ptimer_get_count(). However, the ptimer doesn't immediately call the sp804's arm_timer_tick() function (which is where we update the interrupt-status flag and arrange for an IRQ to be delivered) -- it just schedules that to happen later via a QEMU "bottom half handler". Unfortunately it's possible for the guest CPU to run between when the ptimer's ptimer_tick() happens and when the bottom-half-handler is triggered, which means that the guest can see this incorrectly out-of-sync state from the sp804 device.
+
+I'm not currently sure how best to fix this.
+
+
+Thank you for checking this issue.
+
+I looked at the ptimer code, like you said. Just one question: isn't this used by other hw as well?
+Maybe this problem is more general...
+
+I also tried (basically) the same example on a aarch64 (raspberry pi3), and I don't find any problems there. Maybe could be helpful to look how this problem is solved there.
+
+Just trying to help
+
+I sent out an initial RFC patchset which fixes this (it's just an RFC because it only converts this one device to the new ptimer API, and we should do a proper conversion of all devices); it seems to make the test case in this bug work correctly:
+https://<email address hidden>/
+
+
+Fix has been included in QEMU v4.2:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5a65f7b5f4907ca70cb6
+
diff --git a/results/classifier/118/hypervisor/1808928 b/results/classifier/118/hypervisor/1808928
new file mode 100644
index 00000000..153668e7
--- /dev/null
+++ b/results/classifier/118/hypervisor/1808928
@@ -0,0 +1,143 @@
+hypervisor: 0.838
+virtual: 0.812
+user-level: 0.788
+TCG: 0.786
+KVM: 0.774
+peripherals: 0.773
+risc-v: 0.769
+register: 0.761
+ppc: 0.749
+mistranslation: 0.745
+vnc: 0.738
+graphic: 0.714
+device: 0.692
+VMM: 0.677
+arm: 0.667
+permissions: 0.653
+boot: 0.650
+debug: 0.647
+performance: 0.639
+assembly: 0.629
+x86: 0.626
+semantic: 0.619
+architecture: 0.601
+PID: 0.581
+files: 0.569
+network: 0.562
+i386: 0.559
+kernel: 0.533
+socket: 0.503
+
+Bitmap Extra data is not supported
+
+i am using dirty bitmaps and drive-backup. It works as aspected.
+
+Lately, i encounter a disastrous error. There is not any information about that situation. I cannot reach/open/attach/info or anything with a qcow2 file.
+
+virsh version
+Compiled against library: libvirt 4.10.0
+Using library: libvirt 4.10.0
+Using API: QEMU 4.10.0
+Running hypervisor: QEMU 2.12.0
+
+"qemu-img: Could not open '/var/lib/libvirt/images/test.qcow2': Bitmap extra data is not supported"
+
+what is that mean? what should i do?
+i cannot remove bitmap. i cannot open image or query.
+
+Hi, bitmap extensions have a field that allows us to attach extra/arbitrary data to them. It is not currently used by QEMU. If this field is set, it means something corrupted your qcow2.
+
+Please make a backup of your qcow2 file first (because attempting to repair a broken qcow2 can sometimes make it worse), and then please try running qemu-img check to try and diagnose the image.
+
+What happened to cause the "disastrous error", do you recall?
+
+as far as i know nothing happened. it had worked normally while instance was running. For a reason, instance is shutdown, then it never open again. i have some backups, i tried to return previous backups. But they also gave same error. Thanks to replication i could get it back. i copied image from replication site...
+
+as i said "qemu-img" command completely unusable on that image. 
+There should be another mechanism. It blocks everything. 
+I try to edit header to remove extra data. But i could not find header information on website. 
+
+thanks
+
+OK, I think it is a bug that you cannot at least repair the image, though the cause of corruption is still unknown to me. Do you have libvirt/QEMU logs from when then VM was shut down, before it wouldn't boot properly again?
+
+Sorry, because of log time, VM logs were removed. Journalctl for libvirtd is remain.. It was like that.
+018-12-17 17:01:50.990+0000: 43198: error : qemuMonitorIORead:606 : Unable to read from monitor: Connection reset by peer
+Dec 17 20:01:50 vm-kvm09 libvirtd[43198]: 2018-12-17 17:01:50.991+0000: 43198: error : qemuProcessReportLogError:1935 : internal error: qemu unexpectedly closed the monitor: .guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio
+Dec 17 20:01:51 vm-kvm09 libvirtd[43198]: 2018-12-17T17:01:50.984315Z qemu-kvm: -drive file=/var/lib/libvirt/images/exo1-jb-h01-2.qcow2,format=qcow2,if=none,id=drive-virtio-disk1,cache=none: Bitmap extra data is not supported
+Dec 17 20:02:02 vm-kvm09 libvirtd[43198]: 2018-12-17 17:02:02.652+0000: 43203: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
+Dec 17 20:02:02 vm-kvm09 libvirtd[43198]: 2018-12-17 17:02:02.668+0000: 68990: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
+Dec 17 20:02:02 vm-kvm09 libvirtd[43198]: 2018-12-17 17:02:02.683+0000: 17099: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
+Dec 17 20:09:58 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:58.700+0000: 68889: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
+Dec 17 20:09:58 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:58.717+0000: 43200: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
+Dec 17 20:09:58 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:58.732+0000: 43202: warning : virQEMUCapsInit:923 : Failed to get host CPU cache info
+Dec 17 20:09:59 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:59.144+0000: 43198: error : qemuMonitorIORead:606 : Unable to read from monitor: Connection reset by peer
+Dec 17 20:09:59 vm-kvm09 libvirtd[43198]: 2018-12-17 17:09:59.145+0000: 43198: error : qemuProcessReportLogError:1935 : internal error: qemu unexpectedly closed the monitor: 2018-12-17T17:09:59.132340Z qemu-kvm: -drive file=/var/lib/libvirt/images/exo1-jb-h01-2.qcow2,f...
+
+I keep the broken image file. I run some qemu-img commands:
+
+> qemu-img check /var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712
+qemu-img: Could not open '/var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712': Bitmap extra data is not supported
+
+> qemu-img info /var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712
+qemu-img: Could not open '/var/lib/libvirt/images/exo1-jb-h01-2.qcow2.1712': Bitmap extra data is not supported
+
+
+
+
+
+
+For now, QEMU cannot accept images with extra bitmap data, because QEMU isn't aware of the semantics of those fields, so we cannot even allow the image to load, just in case.
+
+However, we SHOULD allow qemu-img check --repair to detect such bitmaps as corruption so that images can be scrubbed and recovered. I will add that to my TODO list.
+
+Meanwhile, I believe the root cause of your problem here is a data corruption event, but it's hard to tell exactly what it might be because of the extra_data flag ... I can try to have some patches ready for you in January that try to "ignore" the data and analyze the rest of the image as best as possible, which might help us see what else went wrong.
+
+John, did you find some spare time to work on those patches that you've mentioned? I.e. has this been addressed already?
+
+my patches went in, ultimately, and my focus was since shifted elsewhere. I just tried this by *manually* adding some extra data to a bitmap by hand.
+
+
+qemu-img create -f qcow2 foo.qcow2 64m
+qemu-img bitmap --add foo.qcow2 mybitmap
+
+This creates a bitmap extension header like this (starting at 0x1f8)
+
+000001f0  00 00 00 00 00 00 00 00  23 85 28 75 00 00 00 18  |........#.(u....|
+00000200  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 20  |............... |
+00000210  00 00 00 00 00 05 00 00                           |........        |
+
+And a bitmap table that looks like this:
+
+00050000  00 00 00 00 00 04 00 00  00 00 00 01 00 00 00 02  |................|
+00050010  01 10 00 08 00 00 00 00  6d 79 62 69 74 6d 61 70  |........mybitmap|
+
+I modified the bitmap table to add eight bytes of bad data:
+
+00050000  00 00 00 00 00 04 00 00  00 00 00 01 00 00 00 02  |................|
+00050010  01 10 00 08 00 00 00 08  62 61 64 64 61 74 61 21  |........baddata!|
+00050020  6d 79 62 69 74 6d 61 70                           |mybitmap|
+
+And modified the header accordingly to add eight bytes to the table (0x20f := 0x28):
+
+000001f0  00 00 00 00 00 00 00 00  23 85 28 75 00 00 00 18  |........#.(u....|
+00000200  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 28  |...............(|
+00000210  00 00 00 00 00 05 00 00                           |........        |
+
+And in these cases, QEMU refuses to load or work with the image even slightly, rendering you unable to remove it:
+
+> ./qemu-img bitmap --remove foo.qcow2 mybitmap
+qemu-img: Could not open 'foo.qcow2': Bitmap extra data is not supported
+
+So, it's still an open issue.
+
+Sorry, that formatted *terribly*... please see the attachment for a raw text version with arbitrarily long columns that looks nicer. :(
+
+
+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/58
+
+
diff --git a/results/classifier/118/hypervisor/1860 b/results/classifier/118/hypervisor/1860
new file mode 100644
index 00000000..04062d5d
--- /dev/null
+++ b/results/classifier/118/hypervisor/1860
@@ -0,0 +1,40 @@
+hypervisor: 0.998
+virtual: 0.948
+graphic: 0.909
+device: 0.879
+architecture: 0.865
+semantic: 0.485
+debug: 0.276
+performance: 0.263
+i386: 0.262
+register: 0.238
+x86: 0.173
+network: 0.135
+PID: 0.122
+permissions: 0.122
+files: 0.120
+mistranslation: 0.116
+arm: 0.109
+peripherals: 0.093
+vnc: 0.086
+boot: 0.086
+risc-v: 0.076
+user-level: 0.064
+socket: 0.044
+assembly: 0.031
+VMM: 0.025
+TCG: 0.024
+ppc: 0.023
+KVM: 0.015
+kernel: 0.011
+
+virtio-gpu: Only black screen observed after resuming when guest vm do S3
+Description of problem:
+On Xen hypervisor, host(dom0) is PVH, guest(domU) is hvm, config virtio-gpu for guest.
+
+##
+Steps to reproduce:
+1. In guest vm run "sudo su root" & "echo mem \> /sys/power/state"
+2. In host run "sudo xl trigger \<guest id\> s3resume"
+Additional information:
+##
diff --git a/results/classifier/118/hypervisor/1877 b/results/classifier/118/hypervisor/1877
new file mode 100644
index 00000000..84502409
--- /dev/null
+++ b/results/classifier/118/hypervisor/1877
@@ -0,0 +1,273 @@
+hypervisor: 0.915
+permissions: 0.911
+register: 0.901
+device: 0.896
+KVM: 0.893
+x86: 0.887
+graphic: 0.886
+debug: 0.882
+VMM: 0.874
+performance: 0.872
+virtual: 0.870
+TCG: 0.870
+risc-v: 0.866
+architecture: 0.861
+peripherals: 0.860
+socket: 0.860
+assembly: 0.855
+arm: 0.854
+PID: 0.848
+mistranslation: 0.842
+user-level: 0.841
+vnc: 0.838
+boot: 0.832
+semantic: 0.825
+kernel: 0.825
+ppc: 0.825
+files: 0.777
+network: 0.771
+i386: 0.697
+
+virtiofs Illegal Seek Error because of ivshmem device of looking-glass
+Description of problem:
+tl;dr: The dev "gnif" from looking-glass does not want to analyse this problem which his config from the documentation is causing. He insists someone opens a issue here at qemu's, so thats what i did now :) He also insists this problem is not caused by his config (even though the config is needed for looking-glass) and does not want to help or analyse this whole mess. Sorry if i'm a bit salty. 
+
+Please see the following issues on his and the virtio-win github : \
+https://github.com/gnif/LookingGlass/issues/1089
+
+https://github.com/gnif/LookingGlass/issues/1083
+
+[https://github.com/virtio-win/kvm-guest-drivers-windows/issues/911](https://github.com/virtio-win/kvm-guest-drivers-windows/issues/911%5C)
+
+#
+Steps to reproduce:
+1. Create a VM
+2. enable looking-glass (i used the latest Beta6 release from github) with the mentioned kernel module (i use manjaro and can use looking-glass-module-dkms from AUR)
+3. add virtiofs from virt-manager
+Additional information:
+libvirt XML
+
+```plaintext
+<domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm">
+  <name>win10</name>
+  <uuid>a026f749-3adc-4ab8-a5cf-521a4e8ec9d6</uuid>
+  <metadata>
+    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
+      <libosinfo:os id="http://microsoft.com/win/10"/>
+    </libosinfo:libosinfo>
+  </metadata>
+  <memory unit="KiB">12582912</memory>
+  <currentMemory unit="KiB">12582912</currentMemory>
+  <memoryBacking>
+    <source type="memfd"/>
+    <access mode="shared"/>
+  </memoryBacking>
+  <vcpu placement="static">10</vcpu>
+  <os>
+    <type arch="x86_64" machine="pc-q35-5.1">hvm</type>
+    <loader readonly="yes" type="pflash">/usr/share/edk2-ovmf/x64/OVMF_CODE.fd</loader>
+    <nvram>/var/lib/libvirt/qemu/nvram/win10_VARS.fd</nvram>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <hyperv mode="custom">
+      <relaxed state="on"/>
+      <vapic state="on"/>
+      <spinlocks state="on" retries="8191"/>
+      <vendor_id state="on" value="ASRock"/>
+    </hyperv>
+    <vmport state="off"/>
+  </features>
+  <cpu mode="host-passthrough" check="none" migratable="on">
+    <topology sockets="1" dies="1" cores="5" threads="2"/>
+  </cpu>
+  <clock offset="localtime">
+    <timer name="hpet" present="yes"/>
+    <timer name="hypervclock" present="yes"/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <pm>
+    <suspend-to-mem enabled="no"/>
+    <suspend-to-disk enabled="yes"/>
+  </pm>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type="file" device="cdrom">
+      <driver name="qemu" type="raw"/>
+      <target dev="sdc" bus="sata"/>
+      <readonly/>
+      <boot order="1"/>
+      <address type="drive" controller="0" bus="0" target="0" unit="2"/>
+    </disk>
+    <disk type="file" device="disk">
+      <driver name="qemu" type="qcow2" cache="none" discard="unmap"/>
+      <source file="/opt/windowsos.qcow2"/>
+      <target dev="sdd" bus="scsi"/>
+      <boot order="2"/>
+      <address type="drive" controller="0" bus="0" target="0" unit="3"/>
+    </disk>
+    <disk type="block" device="disk">
+      <driver name="qemu" type="raw" cache="none" io="native" discard="unmap"/>
+      <source dev="/dev/zvol/satassd2tb/vms/windowsdata2"/>
+      <target dev="sde" bus="scsi"/>
+      <address type="drive" controller="0" bus="0" target="0" unit="4"/>
+    </disk>
+    <controller type="usb" index="0" model="qemu-xhci" ports="15">
+      <address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
+    </controller>
+    <controller type="pci" index="0" model="pcie-root"/>
+    <controller type="pci" index="1" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="1" port="0x10"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0" multifunction="on"/>
+    </controller>
+    <controller type="pci" index="2" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="2" port="0x11"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x1"/>
+    </controller>
+    <controller type="pci" index="3" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="3" port="0x12"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x2"/>
+    </controller>
+    <controller type="pci" index="4" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="4" port="0x13"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x3"/>
+    </controller>
+    <controller type="pci" index="5" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="5" port="0x14"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x4"/>
+    </controller>
+    <controller type="pci" index="6" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="6" port="0x15"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x5"/>
+    </controller>
+    <controller type="pci" index="7" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="7" port="0x16"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x6"/>
+    </controller>
+    <controller type="pci" index="8" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="8" port="0x17"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x7"/>
+    </controller>
+    <controller type="pci" index="9" model="pcie-to-pci-bridge">
+      <model name="pcie-pci-bridge"/>
+      <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
+    </controller>
+    <controller type="pci" index="10" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="10" port="0x18"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0" multifunction="on"/>
+    </controller>
+    <controller type="pci" index="11" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="11" port="0x19"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x1"/>
+    </controller>
+    <controller type="pci" index="12" model="pcie-root-port">
+      <model name="pcie-root-port"/>
+      <target chassis="12" port="0x1a"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x2"/>
+    </controller>
+    <controller type="scsi" index="0" model="virtio-scsi">
+      <address type="pci" domain="0x0000" bus="0x08" slot="0x00" function="0x0"/>
+    </controller>
+    <controller type="sata" index="0">
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/>
+    </controller>
+    <controller type="virtio-serial" index="0">
+      <address type="pci" domain="0x0000" bus="0x0c" slot="0x00" function="0x0"/>
+    </controller>
+    <filesystem type="mount" accessmode="passthrough">
+      <driver type="virtiofs"/>
+      <source dir="/home/nemu/Downloads"/>
+      <target dir="nemu_downloads"/>
+      <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
+    </filesystem>
+    <interface type="bridge">
+      <mac address="52:54:00:cc:75:be"/>
+      <source bridge="vmbr0"/>
+      <model type="virtio"/>
+      <link state="up"/>
+      <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
+    </interface>
+    <interface type="bridge">
+      <mac address="52:54:00:b8:8d:30"/>
+      <source bridge="vmbr1"/>
+      <model type="virtio"/>
+      <address type="pci" domain="0x0000" bus="0x07" slot="0x00" function="0x0"/>
+    </interface>
+    <channel type="spicevmc">
+      <target type="virtio" name="com.redhat.spice.0"/>
+      <address type="virtio-serial" controller="0" bus="0" port="1"/>
+    </channel>
+    <input type="mouse" bus="virtio">
+      <address type="pci" domain="0x0000" bus="0x0a" slot="0x00" function="0x0"/>
+    </input>
+    <input type="keyboard" bus="virtio">
+      <address type="pci" domain="0x0000" bus="0x0b" slot="0x00" function="0x0"/>
+    </input>
+    <input type="mouse" bus="ps2"/>
+    <input type="keyboard" bus="ps2"/>
+    <graphics type="spice" port="-1" autoport="no" listen="127.0.0.1">
+      <listen type="address" address="127.0.0.1"/>
+      <image compression="off"/>
+      <gl enable="no"/>
+    </graphics>
+    <sound model="ich9">
+      <audio id="1"/>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/>
+    </sound>
+    <audio id="1" type="spice"/>
+    <video>
+      <model type="vga" vram="16384" heads="1" primary="yes">
+        <acceleration accel3d="no"/>
+      </model>
+      <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
+    </video>
+    <hostdev mode="subsystem" type="pci" managed="yes">
+      <source>
+        <address domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
+      </source>
+      <address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
+    </hostdev>
+    <hostdev mode="subsystem" type="pci" managed="yes">
+      <source>
+        <address domain="0x0000" bus="0x04" slot="0x00" function="0x1"/>
+      </source>
+      <address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/>
+    </hostdev>
+    <redirdev bus="usb" type="spicevmc">
+      <address type="usb" bus="0" port="2"/>
+    </redirdev>
+    <redirdev bus="usb" type="spicevmc">
+      <address type="usb" bus="0" port="3"/>
+    </redirdev>
+    <redirdev bus="usb" type="spicevmc">
+      <address type="usb" bus="0" port="4"/>
+    </redirdev>
+    <redirdev bus="usb" type="spicevmc">
+      <address type="usb" bus="0" port="5"/>
+    </redirdev>
+    <watchdog model="itco" action="reset"/>
+    <memballoon model="none"/>
+  </devices>
+  <qemu:commandline>
+    <qemu:arg value="-device"/>
+    <qemu:arg value="{&quot;driver&quot;:&quot;ivshmem-plain&quot;,&quot;id&quot;:&quot;shmem1&quot;,&quot;memdev&quot;:&quot;looking-glass&quot;}"/>
+    <qemu:arg value="-object"/>
+    <qemu:arg value="{&quot;qom-type&quot;:&quot;memory-backend-file&quot;,&quot;id&quot;:&quot;looking-glass&quot;,&quot;mem-path&quot;:&quot;/dev/kvmfr0&quot;,&quot;size&quot;:134217728,&quot;share&quot;:true}"/>
+  </qemu:commandline>
+</domain>
+```
+
+If more logs are needed please just ask. I will gladly provide them.
diff --git a/results/classifier/118/hypervisor/1883729 b/results/classifier/118/hypervisor/1883729
new file mode 100644
index 00000000..a25ac718
--- /dev/null
+++ b/results/classifier/118/hypervisor/1883729
@@ -0,0 +1,428 @@
+hypervisor: 0.804
+graphic: 0.726
+vnc: 0.687
+register: 0.679
+TCG: 0.678
+virtual: 0.670
+x86: 0.661
+KVM: 0.632
+risc-v: 0.630
+VMM: 0.629
+peripherals: 0.626
+user-level: 0.604
+device: 0.581
+mistranslation: 0.569
+arm: 0.568
+i386: 0.549
+ppc: 0.541
+performance: 0.536
+semantic: 0.524
+debug: 0.513
+permissions: 0.482
+assembly: 0.478
+architecture: 0.471
+network: 0.465
+files: 0.463
+boot: 0.461
+PID: 0.455
+socket: 0.452
+kernel: 0.413
+
+xhci_find_stream: Assertion `streamid != 0' failed.
+
+To reproduce run the QEMU with the following command line:
+```
+qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio
+```
+
+QEMU Version:
+```
+# qemu-5.0.0
+$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make
+$ x86_64-softmmu/qemu-system-x86_64 --version
+QEMU emulator version 5.0.0
+Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
+```
+
+
+
+Attaching a QTest reproducer.
+./i386-softmmu/qemu-system-i386 -device nec-usb-xhci -trace usb\* \
+-device usb-audio -device usb-storage,drive=mydrive \
+-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \
+-nodefaults -nographic -qtest stdio < repro
+
+
+Close to the crash:
+21000@1597111713.503068:usb_xhci_slot_configure slotid 58
+21000@1597111713.503074:usb_xhci_ep_disable slotid 58, epid 2
+21000@1597111713.503077:usb_xhci_ep_enable slotid 58, epid 2
+21000@1597111713.503085:usb_xhci_ep_disable slotid 58, epid 6
+21000@1597111713.503088:usb_xhci_ep_enable slotid 58, epid 6
+21000@1597111713.503092:usb_xhci_ep_disable slotid 58, epid 24
+21000@1597111713.503095:usb_xhci_ep_enable slotid 58, epid 24
+21000@1597111713.503099:usb_xhci_ep_disable slotid 58, epid 25
+21000@1597111713.503102:usb_xhci_ep_enable slotid 58, epid 25
+21000@1597111713.503106:usb_xhci_ep_disable slotid 58, epid 29
+21000@1597111713.503109:usb_xhci_ep_enable slotid 58, epid 29
+21000@1597111713.503113:usb_xhci_ep_disable slotid 58, epid 30
+21000@1597111713.503116:usb_xhci_ep_enable slotid 58, epid 30
+21000@1597111713.503121:usb_xhci_fetch_trb addr 0x0000000000000b20, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700
+21000@1597111713.503127:usb_xhci_slot_enable slotid 59
+21000@1597111713.503130:usb_xhci_fetch_trb addr 0x0000000000000b30, CR_SET_TR_DEQUEUE, p 0x0000000000000000, s 0x00000000, c 0x00004300
+21000@1597111713.503135:usb_xhci_fetch_trb addr 0x0000000000000b40, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700
+21000@1597111713.503140:usb_xhci_slot_enable slotid 60
+21000@1597111713.503143:usb_xhci_fetch_trb addr 0x0000000000000b50, CR_EVALUATE_CONTEXT, p 0x0000000000000000, s 0x00000000, c 0x00003600
+21000@1597111713.503149:usb_xhci_fetch_trb addr 0x0000000000000b60, CR_STOP_ENDPOINT, p 0x0000000000000000, s 0x00000000, c 0x3afd3c00
+21000@1597111713.503154:usb_xhci_ep_stop slotid 58, epid 29
+21000@1597111713.503159:usb_xhci_ep_state slotid 58, epid 29, running -> stopped
+21000@1597111713.503163:usb_xhci_fetch_trb addr 0x0000000000000b70, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700
+21000@1597111713.503168:usb_xhci_slot_enable slotid 61
+21000@1597111713.503171:usb_xhci_fetch_trb addr 0x0000000000000b80, CR_SET_TR_DEQUEUE, p 0x0000000000000000, s 0x00000000, c 0x3afd4300
+21000@1597111713.503177:usb_xhci_ep_set_dequeue slotid 58, epid 29, streamid 0, ptr 0x0000000000000000
+qemu-system-i386: hw/usb/hcd-xhci.c:1016: XHCIStreamContext *xhci_find_stream(XHCIEPContext *, unsigned int, uint32_t *): Assertion `streamid != 0' failed.
+Aborted
+
+
+Can you still reproduce this assertion with the latest version 6.0 of QEMU? ... I cannot trigger it here, so I assume this issue has been fixed?
+
+I don't think it is fixed yet.. This is https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28571#c4
+
+Bash Reproducer:
+./qemu-system-i386 -display none -machine accel=qtest, -m 512M \
+-machine q35 -nodefaults -drive \
+file=null-co://,if=none,format=raw,id=disk0 -device qemu-xhci,id=xhci \
+-device usb-tablet,bus=xhci.0 -device usb-bot -device \
+usb-storage,drive=disk0 -chardev null,id=cd0 -chardev null,id=cd1 \
+-device usb-braille,chardev=cd0 -device usb-ccid -device usb-ccid \
+-device usb-kbd -device usb-mouse -device usb-serial,chardev=cd1 -device\
+ usb-tablet -device usb-wacom-tablet -device usb-audio -qtest /dev/null \
+-qtest stdio < attachment
+
+Testcase:
+/*
+ * Autogenerated Fuzzer Test Case
+ *
+ * Copyright (c) 2021 <name of author>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+
+#include "libqos/libqtest.h"
+
+static void test_fuzz(void)
+{
+    QTestState *s = qtest_init(
+        "-display none , -m 512M -machine q35 -nodefaults -drive "
+        "file=null-co://,if=none,format=raw,id=disk0 -device qemu-xhci,id=xhci -device "
+        "usb-tablet,bus=xhci.0 -device usb-bot -device usb-storage,drive=disk0 -chardev "
+        "null,id=cd0 -chardev null,id=cd1 -device usb-braille,chardev=cd0 -device "
+        "usb-ccid -device usb-ccid -device usb-kbd -device usb-mouse -device "
+        "usb-serial,chardev=cd1 -device usb-tablet -device usb-wacom-tablet -device "
+        "usb-audio -qtest /dev/null");
+    qtest_outl(s, 0xcf8, 0x80000816);
+    qtest_outl(s, 0xcfc, 0xffff);
+    qtest_outl(s, 0xcf8, 0x80000803);
+    qtest_outl(s, 0xcfc, 0x0600);
+    qtest_outl(s, 0xcf8, 0x80000810);
+    qtest_outl(s, 0xcfc, 0x2e654000);
+    qtest_writel(s, 0xffff00002e654040, 0xffffff05);
+    qtest_bufwrite(s, 0x4d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x5d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x6d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x7d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x8d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x9d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xad, "\x04", 0x1);
+    qtest_bufwrite(s, 0xbd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xcd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xdd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xed, "\x04", 0x1);
+    qtest_bufwrite(s, 0xfd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x10d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x11d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x12d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x13d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x14d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x15d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x16d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x17d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x18d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x19d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x1ad, "\x04", 0x1);
+    qtest_bufwrite(s, 0x1bd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x1cd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x1dd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x1ed, "\x04", 0x1);
+    qtest_bufwrite(s, 0x1fd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x20d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x21d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x22d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x23d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x24d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x25d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x26d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x27d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x28d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x29d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x2ad, "\x04", 0x1);
+    qtest_bufwrite(s, 0x2bd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x2cd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x2dd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x2ed, "\x04", 0x1);
+    qtest_bufwrite(s, 0x2fd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x30d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x31d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x32d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x33d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x34d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x35d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x36d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x37d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x38d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x39d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x3ad, "\x04", 0x1);
+    qtest_bufwrite(s, 0x3bd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x3cd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x3dd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x3ed, "\x04", 0x1);
+    qtest_bufwrite(s, 0x3fd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x40d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x41d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x42d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x43d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x44d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x45d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x46d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x47d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x48d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x49d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x4ad, "\x04", 0x1);
+    qtest_bufwrite(s, 0x4bd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x4cd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x4dd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x4ed, "\x04", 0x1);
+    qtest_bufwrite(s, 0x4fd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x50d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x51d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x52d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x53d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x54d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x55d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x56d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x57d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x58d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x59d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x5ad, "\x04", 0x1);
+    qtest_bufwrite(s, 0x5bd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x5cd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x5dd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x5ed, "\x04", 0x1);
+    qtest_bufwrite(s, 0x5fd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x60d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x61d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x62d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x63d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x64d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x65d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x66d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x67d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x68d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x69d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x6ad, "\x04", 0x1);
+    qtest_bufwrite(s, 0x6bd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x6cd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x6dd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x6ed, "\x04", 0x1);
+    qtest_bufwrite(s, 0x6fd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x70d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x71d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x72d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x73d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x74d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x75d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x76d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x77d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x78d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x79d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x7ad, "\x04", 0x1);
+    qtest_bufwrite(s, 0x7bd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x7cd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x7dd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x7ed, "\x04", 0x1);
+    qtest_bufwrite(s, 0x7fd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x80d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x81d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x82d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x83d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x84d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x85d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x86d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x87d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x88d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x89d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x8ad, "\x04", 0x1);
+    qtest_bufwrite(s, 0x8bd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x8cd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x8dd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x8ed, "\x04", 0x1);
+    qtest_bufwrite(s, 0x8fd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x90d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x91d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x92d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x93d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x94d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x95d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x96d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x97d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x98d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x99d, "\x04", 0x1);
+    qtest_bufwrite(s, 0x9ad, "\x04", 0x1);
+    qtest_bufwrite(s, 0x9bd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x9cd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x9dd, "\x04", 0x1);
+    qtest_bufwrite(s, 0x9ed, "\x04", 0x1);
+    qtest_bufwrite(s, 0x9fd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa0d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa1d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa2d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa3d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa4d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa5d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa6d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa7d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa8d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xa9d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xaad, "\x04", 0x1);
+    qtest_bufwrite(s, 0xabd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xacd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xadd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xaed, "\x04", 0x1);
+    qtest_bufwrite(s, 0xafd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb0d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb1d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb2d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb3d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb4d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb5d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb6d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb7d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb8d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xb9d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xbad, "\x04", 0x1);
+    qtest_bufwrite(s, 0xbbd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xbcd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xbdd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xbed, "\x04", 0x1);
+    qtest_bufwrite(s, 0xbfd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc0d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc1d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc2d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc3d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc4d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc5d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc6d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc7d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc8d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xc9d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xcad, "\x04", 0x1);
+    qtest_bufwrite(s, 0xcbd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xccd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xcdd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xced, "\x04", 0x1);
+    qtest_bufwrite(s, 0xcfd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd0d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd1d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd2d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd3d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd4d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd5d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd6d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd7d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd8d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xd9d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xdad, "\x04", 0x1);
+    qtest_bufwrite(s, 0xdbd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xdcd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xddd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xded, "\x04", 0x1);
+    qtest_bufwrite(s, 0xdfd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe0d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe1d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe2d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe3d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe4d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe5d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe6d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe7d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe8d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xe9d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xead, "\x04", 0x1);
+    qtest_bufwrite(s, 0xebd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xecd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xedd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xeed, "\x04", 0x1);
+    qtest_bufwrite(s, 0xefd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf0d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf1d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf2d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf3d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf4d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf5d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf6d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf7d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf8d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xf9d, "\x04", 0x1);
+    qtest_bufwrite(s, 0xfad, "\x04", 0x1);
+    qtest_bufwrite(s, 0xfbd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xfcd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xfdd, "\x04", 0x1);
+    qtest_bufwrite(s, 0xfed, "\x24", 0x1);
+    qtest_bufwrite(s, 0xffd, "\x24", 0x1);
+    qtest_bufwrite(s, 0x100d, "\x24", 0x1);
+    qtest_bufwrite(s, 0x101d, "\x24", 0x1);
+    qtest_bufwrite(s, 0x102d, "\x24", 0x1);
+    qtest_bufwrite(s, 0x1041, "\x6d", 0x1);
+    qtest_bufwrite(s, 0x104d, "\x2c", 0x1);
+    qtest_bufwrite(s, 0x104f, "\x05", 0x1);
+    qtest_writel(s, 0xffff00002e656000, 0x0);
+    qtest_writel(s, 0xffff00002e656000, 0x0);
+    qtest_writel(s, 0xffff00002e656000, 0x0);
+    qtest_writel(s, 0xffff00002e656000, 0x0);
+    qtest_bufwrite(s, 0x6d04, "\x03", 0x1);
+    qtest_bufwrite(s, 0x6d26, "\x04", 0x1);
+    qtest_bufwrite(s, 0x6d41, "\x04", 0x1);
+    qtest_writel(s, 0xffff00002e656000, 0x0);
+    qtest_writel(s, 0xffff00002e656000, 0x0);
+    qtest_bufwrite(s, 0xffff00002e656014, "\x01\x00\x00\x00", 0x4);
+    qtest_quit(s);
+}
+int main(int argc, char **argv)
+{
+    const char *arch = qtest_get_arch();
+
+    g_test_init(&argc, &argv, NULL);
+
+    if (strcmp(arch, "i386") == 0) {
+        qtest_add_func("fuzz/test_fuzz", test_fuzz);
+    }
+
+    return g_test_run();
+}
+
+
+
+
+Ok, with the new attachment from comment #5, I can also reporoduce the bug again. It does not reproduce with the attachments from comment #1 or #2 anymore, so this now seems to be a different way to run into this assert. Anyway, setting the status back to Confirmed since it is reproducible again.
+
+
+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/273
+
+
diff --git a/results/classifier/118/hypervisor/1892963 b/results/classifier/118/hypervisor/1892963
new file mode 100644
index 00000000..b05d500f
--- /dev/null
+++ b/results/classifier/118/hypervisor/1892963
@@ -0,0 +1,356 @@
+hypervisor: 0.890
+peripherals: 0.886
+user-level: 0.869
+KVM: 0.838
+risc-v: 0.838
+i386: 0.827
+TCG: 0.819
+mistranslation: 0.798
+VMM: 0.785
+graphic: 0.770
+ppc: 0.759
+virtual: 0.740
+vnc: 0.722
+device: 0.718
+performance: 0.712
+register: 0.706
+x86: 0.691
+assembly: 0.682
+permissions: 0.679
+arm: 0.670
+architecture: 0.659
+semantic: 0.638
+debug: 0.626
+network: 0.615
+boot: 0.607
+socket: 0.595
+files: 0.595
+kernel: 0.586
+PID: 0.582
+
+Heap-use-after-free in put_dwords through ehci_flush_qh
+
+Hello,
+Reproducer:
+
+cat << EOF | ./qemu-system-i386 -machine q35 \
+-device ich9-usb-ehci1,bus=pcie.0,addr=1d.7,\
+multifunction=on,id=ich9-ehci-1 \
+-drive if=none,id=usbcdrom,media=cdrom \
+-device usb-storage,bus=ich9-ehci-1.0,\
+port=2,drive=usbcdrom \
+-display none -nodefaults -qtest stdio -accel qtest
+outl 0xcf8 0x8000ef02
+outl 0xcfc 0xfbff0061
+outl 0xcf8 0x8000ef11
+outl 0xcfc 0x60606060
+writeq 0x60606065 0xb70560ff84ffff7f
+writeq 0x60606065 0xff0004fe050000ff
+writeq 0x60606020 0xff015e5c057b0039
+writeq 0x60606033 0x846c8a0200000611
+write 0x2000004 0x4 0x4a606060
+write 0x8 0x4 0x97a98095
+write 0x0 0x4 0x4a606060
+write 0x4 0x4 0x97a98095
+write 0xc 0x4 0x4a606060
+write 0x10 0x4 0x97a98095
+write 0x14 0x4 0x4a606060
+write 0x18 0x4 0x97a98095
+write 0x1c 0x4 0x4a606060
+clock_step
+EOF
+
+The trace:
+797726@1598407357.169284:usb_port_claim bus 0, port 2
+797726@1598407357.169585:usb_port_attach bus 0, port 2, devspeed full+high+super, portspeed high
+797726@1598407357.169598:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD
+797726@1598407357.169608:usb_ehci_irq level 0, frindex 0x0000, sts 0x4, mask 0x0
+797726@1598407357.186943:usb_ehci_reset === RESET ===
+797726@1598407357.186960:usb_ehci_port_detach detach port #1, owner ehci
+797726@1598407357.186968:usb_ehci_irq level 0, frindex 0x0000, sts 0x4, mask 0x0
+797726@1598407357.186976:usb_ehci_irq level 0, frindex 0x0000, sts 0x1000, mask 0x0
+797726@1598407357.186984:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD
+797726@1598407357.186989:usb_ehci_irq level 0, frindex 0x0000, sts 0x1004, mask 0x0
+[R +0.073737] outl 0xcf8 0x8000ef02
+OK
+[S +0.073774] OK
+[R +0.073801] outl 0xcfc 0xfbff0061
+OK
+[S +0.075074] OK
+[R +0.075108] outl 0xcf8 0x8000ef11
+OK
+[S +0.075126] OK
+[R +0.075135] outl 0xcfc 0x60606060
+OK
+[S +0.076290] OK
+[R +0.076317] writeq 0x60606065 0xb70560ff84ffff7f
+797726@1598407357.194959:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0x560ff84
+797726@1598407357.194967:usb_ehci_port_reset reset port #1 - 1
+797726@1598407357.194971:usb_ehci_port_suspend port #1
+797726@1598407357.194975:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x601183 (old: 0x1003)
+OK
+[S +0.076363] OK
+[R +0.076377] writeq 0x60606065 0xff0004fe050000ff
+797726@1598407357.195005:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0x4fe05
+797726@1598407357.195011:usb_ehci_port_reset reset port #1 - 0
+797726@1598407357.195019:usb_ehci_port_detach detach port #1, owner ehci
+797726@1598407357.195026:usb_ehci_irq level 0, frindex 0x0000, sts 0x1004, mask 0x0
+797726@1598407357.195034:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD
+797726@1598407357.195038:usb_ehci_irq level 0, frindex 0x0000, sts 0x1004, mask 0x0
+797726@1598407357.195049:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x1005 (old: 0x601183)
+OK
+[S +0.076439] OK
+[R +0.076457] writeq 0x60606020 0xff015e5c057b0039
+797726@1598407357.195087:usb_ehci_opreg_write wr mmio 0x0020 [USBCMD] = 0x57b0039
+attempt to set frame list size -- value 8
+797726@1598407357.195097:usb_ehci_usbsts usbsts HALT 0
+797726@1598407357.195105:usb_ehci_opreg_change ch mmio 0x0020 [USBCMD] = 0x57b0031 (old: 0x80000)
+797726@1598407357.195111:usb_ehci_opreg_write wr mmio 0x0024 [USBSTS] = 0xff015e5c
+797726@1598407357.195117:usb_ehci_usbsts usbsts PCD 0
+797726@1598407357.195120:usb_ehci_usbsts usbsts FLR 0
+797726@1598407357.195124:usb_ehci_usbsts usbsts HSE 0
+797726@1598407357.195127:usb_ehci_irq level 0, frindex 0x0000, sts 0x0, mask 0x0
+797726@1598407357.195132:usb_ehci_opreg_change ch mmio 0x0024 [USBSTS] = 0x0 (old: 0x4)
+OK
+[S +0.076519] OK
+[R +0.076534] writeq 0x60606033 0x846c8a0200000611
+797726@1598407357.195164:usb_ehci_opreg_write wr mmio 0x0034 [P-LIST BASE] = 0x2000006
+ehci: PERIODIC list base register set while periodic schedule
+      is enabled and HC is enabled
+797726@1598407357.195174:usb_ehci_opreg_change ch mmio 0x0034 [P-LIST BASE] = 0x2000006 (old: 0x0)
+OK
+[S +0.076562] OK
+[R +0.076574] write 0x2000004 0x4 0x4a606060
+OK
+[S +0.076855] OK
+[R +0.076869] write 0x8 0x4 0x97a98095
+OK
+[S +0.077214] OK
+[R +0.077225] write 0x0 0x4 0x4a606060
+OK
+[S +0.077233] OK
+[R +0.077242] write 0x4 0x4 0x97a98095
+OK
+[S +0.077250] OK
+[R +0.077258] write 0xc 0x4 0x4a606060
+OK
+[S +0.077266] OK
+[R +0.077274] write 0x10 0x4 0x97a98095
+OK
+[S +0.077281] OK
+[R +0.077289] write 0x14 0x4 0x4a606060
+OK
+[S +0.077295] OK
+[R +0.077304] write 0x18 0x4 0x97a98095
+OK
+[S +0.077310] OK
+[R +0.077325] write 0x1c 0x4 0x4a606060
+OK
+[S +0.077333] OK
+[R +0.077340] clock_step
+OK 27462700
+[S +0.077415] OK 27462700
+797726@1598407357.196115:usb_ehci_state periodic schedule ACTIVE
+797726@1598407357.196123:usb_ehci_usbsts usbsts PSS 1
+797726@1598407357.196137:usb_ehci_state periodic schedule FETCH ENTRY
+797726@1598407357.196145:usb_ehci_state periodic schedule FETCH QH
+797726@1598407357.196154:usb_ehci_queue_action q 0x60d0000050b0: alloc
+797726@1598407357.196168:usb_ehci_opreg_read rd mmio 0x0040 [unknown] = 0x0
+797726@1598407357.196176:usb_ehci_opreg_read rd mmio 0x0044 [unknown] = 0x0
+797726@1598407357.196182:usb_ehci_opreg_read rd mmio 0x0048 [unknown] = 0x0
+797726@1598407357.196188:usb_ehci_opreg_read rd mmio 0x004c [unknown] = 0x0
+797726@1598407357.196195:usb_ehci_opreg_read rd mmio 0x0050 [unknown] = 0x0
+797726@1598407357.196201:usb_ehci_opreg_read rd mmio 0x0054 [unknown] = 0x0
+797726@1598407357.196206:usb_ehci_opreg_read rd mmio 0x0058 [unknown] = 0x0
+797726@1598407357.196211:usb_ehci_opreg_read rd mmio 0x005c [unknown] = 0x0
+797726@1598407357.196217:usb_ehci_opreg_read rd mmio 0x0060 [CONFIGFLAG] = 0x0
+797726@1598407357.196224:usb_ehci_portsc_read rd mmio 0x0044 [port 0] = 0x1000
+797726@1598407357.196230:usb_ehci_portsc_read rd mmio 0x0048 [port 1] = 0x1005
+797726@1598407357.196237:usb_ehci_portsc_read rd mmio 0x004c [port 2] = 0x1000
+797726@1598407357.196243:usb_ehci_qh_ptrs q 0x60d0000050b0 - QH @ 0x60606040: next 0x00000000 qtds 0x00000000,0x00000000,0x00000000
+797726@1598407357.196249:usb_ehci_qh_fields QH @ 0x60606040 - rl 0, mplen 0, eps 0, ep 0, dev 0
+797726@1598407357.196255:usb_ehci_qh_bits QH @ 0x60606040 - c 0, h 0, dtc 0, i 0
+797726@1598407357.196262:usb_ehci_queue_action q 0x60d0000050b0: reset
+797726@1598407357.196275:usb_ehci_state periodic schedule ADVANCEQUEUE
+797726@1598407357.196281:usb_ehci_state periodic schedule FETCH QTD
+797726@1598407357.196300:usb_ehci_qtd_ptrs q 0x60d0000050b0 - QTD @ 0x00000000: next 0x6060604a altnext 0x9580a997
+797726@1598407357.196306:usb_ehci_qtd_fields QTD @ 0x00000000 - tbytes 5504, cpage 2, cerr 2, pid 1
+797726@1598407357.196311:usb_ehci_qtd_bits QTD @ 0x00000000 - ioc 1, active 1, halt 0, babble 1, xacterr 0
+797726@1598407357.196323:usb_ehci_packet_action q 0x60d0000050b0 p 0x611000044380: alloc
+797726@1598407357.196327:usb_ehci_state periodic schedule EXECUTE
+797726@1598407357.196346:usb_ehci_opreg_write wr mmio 0x004c [unknown] = 0x0
+797726@1598407357.196351:usb_ehci_opreg_change ch mmio 0x004c [unknown] = 0x0 (old: 0x0)
+797726@1598407357.196359:usb_ehci_opreg_write wr mmio 0x0050 [unknown] = 0x6060604a
+797726@1598407357.196363:usb_ehci_opreg_change ch mmio 0x0050 [unknown] = 0x6060604a (old: 0x0)
+797726@1598407357.196370:usb_ehci_opreg_write wr mmio 0x0054 [unknown] = 0x9580a981
+797726@1598407357.196374:usb_ehci_opreg_change ch mmio 0x0054 [unknown] = 0x9580a981 (old: 0x0)
+797726@1598407357.196380:usb_ehci_opreg_write wr mmio 0x0058 [unknown] = 0x1580a997
+797726@1598407357.196385:usb_ehci_opreg_change ch mmio 0x0058 [unknown] = 0x1580a997 (old: 0x0)
+797726@1598407357.196392:usb_ehci_opreg_write wr mmio 0x005c [unknown] = 0x6060604a
+797726@1598407357.196396:usb_ehci_opreg_change ch mmio 0x005c [unknown] = 0x6060604a (old: 0x0)
+797726@1598407357.196403:usb_ehci_opreg_write wr mmio 0x0060 [CONFIGFLAG] = 0x9580a900
+797726@1598407357.196407:usb_ehci_opreg_change ch mmio 0x0060 [CONFIGFLAG] = 0x0 (old: 0x0)
+797726@1598407357.196415:usb_ehci_portsc_write wr mmio 0x0044 [port 0] = 0x60606040
+797726@1598407357.196422:usb_ehci_portsc_change ch mmio 0x0044 [port 0] = 0x601040 (old: 0x1000)
+797726@1598407357.196428:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0x9580a997
+797726@1598407357.196432:usb_ehci_port_reset reset port #1 - 1
+797726@1598407357.196437:usb_ehci_port_suspend port #1
+797726@1598407357.196441:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x1185 (old: 0x1005)
+797726@1598407357.196448:usb_ehci_portsc_write wr mmio 0x004c [port 2] = 0x6060604a
+797726@1598407357.196453:usb_ehci_portsc_change ch mmio 0x004c [port 2] = 0x601040 (old: 0x1000)
+797726@1598407357.196474:usb_packet_state_change bus 0, port 2, ep 0, packet 0x6110000443c0, state undef -> setup
+797726@1598407357.196505:usb_ehci_opreg_write wr mmio 0x004c [unknown] = 0xbebebebe
+797726@1598407357.196509:usb_ehci_opreg_change ch mmio 0x004c [unknown] = 0xbebebebe (old: 0x0)
+797726@1598407357.196516:usb_ehci_opreg_write wr mmio 0x0050 [unknown] = 0xbebebebe
+797726@1598407357.196520:usb_ehci_opreg_change ch mmio 0x0050 [unknown] = 0xbebebebe (old: 0x6060604a)
+797726@1598407357.196527:usb_ehci_opreg_write wr mmio 0x0054 [unknown] = 0xbebebebe
+797726@1598407357.196530:usb_ehci_opreg_change ch mmio 0x0054 [unknown] = 0xbebebebe (old: 0x9580a981)
+797726@1598407357.196540:usb_ehci_opreg_write wr mmio 0x0058 [unknown] = 0xbebebebe
+797726@1598407357.196544:usb_ehci_opreg_change ch mmio 0x0058 [unknown] = 0xbebebebe (old: 0x1580a997)
+797726@1598407357.196550:usb_ehci_opreg_write wr mmio 0x005c [unknown] = 0xbebebebe
+797726@1598407357.196554:usb_ehci_opreg_change ch mmio 0x005c [unknown] = 0xbebebebe (old: 0x6060604a)
+797726@1598407357.196560:usb_ehci_opreg_write wr mmio 0x0060 [CONFIGFLAG] = 0xbebebebe
+797726@1598407357.196563:usb_ehci_opreg_change ch mmio 0x0060 [CONFIGFLAG] = 0x0 (old: 0x0)
+797726@1598407357.196569:usb_ehci_portsc_write wr mmio 0x0044 [port 0] = 0xbebebebe
+797726@1598407357.196573:usb_ehci_port_suspend port #0
+797726@1598407357.196577:usb_ehci_port_resume port #0
+797726@1598407357.196580:usb_ehci_portsc_change ch mmio 0x0044 [port 0] = 0x301000 (old: 0x601040)
+797726@1598407357.196586:usb_ehci_portsc_write wr mmio 0x0048 [port 1] = 0xbebebebe
+797726@1598407357.196590:usb_ehci_port_reset reset port #1 - 0
+797726@1598407357.196596:usb_ehci_port_detach detach port #1, owner ehci
+797726@1598407357.196602:usb_ehci_queue_action q 0x60d0000050b0: free
+797726@1598407357.196606:usb_ehci_queue_action q 0x60d0000050b0: cancel
+797726@1598407357.196610:usb_ehci_packet_action q 0x60d0000050b0 p 0x611000044380: free
+797726@1598407357.196626:usb_ehci_irq level 0, frindex 0x0008, sts 0x4004, mask 0x0
+797726@1598407357.196636:usb_ehci_port_attach attach port #1, owner ehci, device QEMU USB MSD
+797726@1598407357.196642:usb_ehci_irq level 0, frindex 0x0008, sts 0x4004, mask 0x0
+797726@1598407357.196655:usb_ehci_port_suspend port #1
+797726@1598407357.196659:usb_ehci_portsc_change ch mmio 0x0048 [port 1] = 0x301085 (old: 0x1185)
+797726@1598407357.196669:usb_ehci_portsc_write wr mmio 0x004c [port 2] = 0xbebebebe
+797726@1598407357.196674:usb_ehci_port_suspend port #2
+797726@1598407357.196679:usb_ehci_port_resume port #2
+797726@1598407357.196684:usb_ehci_portsc_change ch mmio 0x004c [port 2] = 0x301000 (old: 0x601040)
+797726@1598407357.196694:usb_ehci_portsc_write wr mmio 0x0050 [port 3] = 0xbebebebe
+797726@1598407357.196699:usb_ehci_port_suspend port #3
+797726@1598407357.196704:usb_ehci_portsc_change ch mmio 0x0050 [port 3] = 0x301080 (old: 0x1000)
+797726@1598407357.196712:usb_ehci_portsc_write wr mmio 0x0054 [port 4] = 0xbebebebe
+797726@1598407357.196716:usb_ehci_port_suspend port #4
+797726@1598407357.196718:usb_ehci_portsc_change ch mmio 0x0054 [port 4] = 0x301080 (old: 0x1000)
+797726@1598407357.196724:usb_ehci_portsc_write wr mmio 0x0058 [port 5] = 0xbebebebe
+797726@1598407357.196729:usb_ehci_port_suspend port #5
+797726@1598407357.196733:usb_ehci_portsc_change ch mmio 0x0058 [port 5] = 0x301080 (old: 0x1000)
+=================================================================
+==797726==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110000443e8 at pc 0x5574af0ef59d bp 0x7fff5b343a00 sp 0x7fff5b3439f8
+READ of size 4 at 0x6110000443e8 thread T0
+    #0 0x5574af0ef59c in usb_packet_unmap /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:64:28
+    #1 0x5574af0ee924 in usb_packet_map /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:54:5
+    #2 0x5574ae630c2f in ehci_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1376:9
+    #3 0x5574ae619cfe in ehci_state_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1942:13
+    #4 0x5574ae60e8d9 in ehci_advance_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2083:21
+    #5 0x5574ae60c753 in ehci_advance_periodic_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2213:9
+    #6 0x5574ae5d9df3 in ehci_work_bh /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2299:17
+    #7 0x5574b21013c2 in aio_bh_call /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:136:5
+    #8 0x5574b2102dc2 in aio_bh_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:164:13
+    #9 0x5574b211a84b in aio_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/aio-posix.c:380:5
+    #10 0x5574b210c29e in aio_ctx_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:306:5
+    #11 0x7f44ce9dc5fc in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x505fc)
+    #12 0x5574b2339c67 in glib_pollfds_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9
+    #13 0x5574b2337567 in os_host_main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5
+    #14 0x5574b2336f47 in main_loop_wait /home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11
+    #15 0x5574b0b1508d in qemu_main_loop /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9
+    #16 0x5574ae4a751c in main /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5
+    #17 0x7f44ce1e5cc9 in __libc_start_main csu/../csu/libc-start.c:308:16
+    #18 0x5574ae3fccf9 in _start (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2cb0cf9)
+
+0x6110000443e8 is located 104 bytes inside of 248-byte region [0x611000044380,0x611000044478)
+freed by thread T0 here:
+    #0 0x5574ae4751bd in free (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d291bd)
+    #1 0x5574ae5e71a1 in ehci_free_packet /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:541:5
+    #2 0x5574ae5e3662 in ehci_cancel_queue /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:584:9
+    #3 0x5574ae5e174c in ehci_free_queue /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:611:17
+    #4 0x5574ae608300 in ehci_queues_rip_device /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:674:9
+    #5 0x5574ae6034ba in ehci_detach /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:732:5
+    #6 0x5574af06427f in usb_detach /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:70:5
+    #7 0x5574af064607 in usb_port_reset /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/core.c:79:5
+    #8 0x5574ae63af7a in ehci_port_write /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:993:13
+    #9 0x5574b0e31de0 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5
+    #10 0x5574b0e312bd in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18
+    #11 0x5574b0e2ef70 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16
+    #12 0x5574b0a8d8a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23
+    #13 0x5574b0a76878 in flatview_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14
+    #14 0x5574b0a763a8 in address_space_write /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18
+    #15 0x5574b0a7dff7 in address_space_unmap /home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3634:9
+    #16 0x5574af0f0262 in dma_memory_unmap /home/alxndr/Development/qemu/general-fuzz/include/sysemu/dma.h:145:5
+    #17 0x5574af0f0143 in usb_packet_unmap /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:65:9
+    #18 0x5574af0ee924 in usb_packet_map /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:54:5
+    #19 0x5574ae630c2f in ehci_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1376:9
+    #20 0x5574ae619cfe in ehci_state_execute /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1942:13
+    #21 0x5574ae60e8d9 in ehci_advance_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2083:21
+    #22 0x5574ae60c753 in ehci_advance_periodic_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2213:9
+    #23 0x5574ae5d9df3 in ehci_work_bh /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2299:17
+    #24 0x5574b21013c2 in aio_bh_call /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:136:5
+    #25 0x5574b2102dc2 in aio_bh_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:164:13
+    #26 0x5574b211a84b in aio_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/aio-posix.c:380:5
+    #27 0x5574b210c29e in aio_ctx_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:306:5
+    #28 0x7f44ce9dc5fc in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x505fc)
+
+previously allocated by thread T0 here:
+    #0 0x5574ae4755b2 in calloc (/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d295b2)
+    #1 0x7f44ce9e2210 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x56210)
+    #2 0x5574ae6175be in ehci_state_fetchqtd /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:1844:13
+    #3 0x5574ae60e7f1 in ehci_advance_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2073:21
+    #4 0x5574ae60c753 in ehci_advance_periodic_state /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2213:9
+    #5 0x5574ae5d9df3 in ehci_work_bh /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/hcd-ehci.c:2299:17
+    #6 0x5574b21013c2 in aio_bh_call /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:136:5
+    #7 0x5574b2102dc2 in aio_bh_poll /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:164:13
+    #8 0x5574b211a84b in aio_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/aio-posix.c:380:5
+    #9 0x5574b210c29e in aio_ctx_dispatch /home/alxndr/Development/qemu/general-fuzz/build/../util/async.c:306:5
+    #10 0x7f44ce9dc5fc in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x505fc)
+
+SUMMARY: AddressSanitizer: heap-use-after-free /home/alxndr/Development/qemu/general-fuzz/build/../hw/usb/libhw.c:64:28 in usb_packet_unmap
+Shadow bytes around the buggy address:
+  0x0c2280000820: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c2280000830: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c2280000840: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
+  0x0c2280000850: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+  0x0c2280000860: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
+=>0x0c2280000870: fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd
+  0x0c2280000880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
+  0x0c2280000890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c22800008a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c22800008b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+  0x0c22800008c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+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
+  Shadow gap:              cc
+==797726==ABORTING
+
+-Alex
+
+I can still reproduce this issue when compiling the current version of QEMU with Clang + asan. Marking as "Confirmed".
+
+I moved this report over to QEMU's new bug tracker on gitlab.com.
+Please continue with the discussion here:
+
+https://gitlab.com/qemu-project/qemu/-/issues/541
+
+Thanks for moving it over! ... let's close this one here on Launchpad now.
+
+
diff --git a/results/classifier/118/hypervisor/1901532 b/results/classifier/118/hypervisor/1901532
new file mode 100644
index 00000000..6606cbe5
--- /dev/null
+++ b/results/classifier/118/hypervisor/1901532
@@ -0,0 +1,61 @@
+i386: 0.961
+hypervisor: 0.947
+device: 0.886
+graphic: 0.669
+x86: 0.644
+semantic: 0.589
+network: 0.497
+PID: 0.487
+peripherals: 0.481
+ppc: 0.478
+socket: 0.461
+mistranslation: 0.443
+performance: 0.439
+architecture: 0.436
+user-level: 0.406
+files: 0.367
+virtual: 0.340
+arm: 0.335
+debug: 0.323
+boot: 0.282
+vnc: 0.257
+VMM: 0.257
+risc-v: 0.237
+permissions: 0.206
+register: 0.179
+TCG: 0.128
+kernel: 0.108
+assembly: 0.045
+KVM: 0.034
+
+Assertion failure `mr != NULL' failed through usb-ehci
+
+Hello,
+
+Using hypervisor fuzzer, hyfuzz, I found an assertion failure through usb-ehci.
+
+This was found in version 5.0.1 (stable-5.0).
+
+--------
+
+qemu-system-i386: src/qemu-repro/exec.c:3581: address_space_unmap: Assertion `mr != NULL' failed.
+[1]    14721 abort      src/qemu-repro/build/i386-softmmu/qemu-system-i386
+
+
+To reproduce the assertion failure, please run the QEMU with following command line.
+
+```
+$ qemu-system-i386 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -m 512 -drive if=none,id=stick,file=./usbdisk.img -device usb-ehci,id=ehci -device usb-storage,bus=ehci.0,drive=stick
+```
+
+
+
+Can you still reproduce this with QEMU v6.0 ? For me, qemu now does not crash anymore, so I assume this might have been fixed within the past months?
+
+This problem got fixed by this commit:
+
+  2fdb42d840400d58f2e706ecca82c142b97bcbd6
+  hw: ehci: check return value of 'usb_packet_map'
+
+Thus let's close this ticket now.
+
diff --git a/results/classifier/118/hypervisor/1906905 b/results/classifier/118/hypervisor/1906905
new file mode 100644
index 00000000..bb5b8d1d
--- /dev/null
+++ b/results/classifier/118/hypervisor/1906905
@@ -0,0 +1,415 @@
+hypervisor: 0.925
+graphic: 0.899
+peripherals: 0.879
+risc-v: 0.875
+register: 0.873
+permissions: 0.870
+virtual: 0.870
+debug: 0.859
+mistranslation: 0.856
+user-level: 0.854
+assembly: 0.846
+TCG: 0.845
+semantic: 0.844
+vnc: 0.837
+device: 0.835
+KVM: 0.831
+ppc: 0.831
+architecture: 0.828
+performance: 0.826
+VMM: 0.818
+boot: 0.816
+arm: 0.811
+PID: 0.787
+network: 0.769
+kernel: 0.755
+socket: 0.750
+x86: 0.744
+files: 0.691
+i386: 0.633
+
+qemu-system-sparc stucked while booting using ss20_v2.25_rom 
+
+I cannot boot up OBP using the current (5.1) version of qemu with ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged.  However using the previous version from 2015 I can successfully both up the OBP. 
+
+qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
+
+Power-ON Reset
+
+(*hang) 
+
+regards
+Yap KV
+
+I have just compiled a few version from source code:
+
+4.1.1  worked: able to boot up with -bios ss20_v2.25.rom 
+5.0.0  worked: able to boot up with -bios ss20_v2.25.rom 
+5.1.0  not working. Stuck after "Power-On Reset"
+
+SS5.bin worked for 5.1.0
+
+
+Per the "NCR89C105 Chip Specification" referenced in the header:
+
+                  Chip-level Address Map
+
+  ------------------------------------------------------------------
+  | 1D0 0000 ->   | Counter/Timers                        | W,D    |
+  |   1DF FFFF    |                                       |        |
+  ...
+
+  The address map indicated the allowed accesses at each address.
+  [...] W indicates a word access, and D indicates a double-word
+  access.
+
+The SLAVIO timer controller is implemented expecting 32-bit accesses.
+Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
+the device allows 64-bit accesses.
+
+This was not an issue until commit 5d971f9e67 which reverted
+("memory: accept mismatching sizes in memory_region_access_valid").
+
+Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
+access range (W -> 4, D -> 8).
+
+Since commit 21786c7e598 ("memory: Log invalid memory accesses")
+this class of bug can be quickly debugged displaying 'guest_errors'
+accesses, as:
+
+  $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
+
+  Power-ON Reset
+  Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
+
+  $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
+  (qemu) info mtree
+  address-space: memory
+    0000000000000000-ffffffffffffffff (prio 0, i/o): system
+      ...
+      0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
+             ^^^^^^^^^                                 ^^^^^^^
+                   \ memory region base address and name /
+
+  (qemu) info qtree
+  bus: main-system-bus
+    dev: slavio_timer, id ""              <-- device type name
+      gpio-out "sysbus-irq" 17
+      num_cpus = 1 (0x1)
+      mmio 0000000ff1310000/0000000000000014
+      mmio 0000000ff1300000/0000000000000010 <--- base address
+      mmio 0000000ff1301000/0000000000000010
+      mmio 0000000ff1302000/0000000000000010
+      ...
+
+Reported-by: Yap KV <email address hidden>
+Buglink: https://bugs.launchpad.net/bugs/1906905
+Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
+Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+---
+Cc: Benoit Canet <email address hidden>
+Cc: <email address hidden>
+Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+---
+ hw/timer/slavio_timer.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
+index 5b2d20cb6a5..03e33fc5926 100644
+--- a/hw/timer/slavio_timer.c
++++ b/hw/timer/slavio_timer.c
+@@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
+     .write = slavio_timer_mem_writel,
+     .endianness = DEVICE_NATIVE_ENDIAN,
+     .valid = {
++        .min_access_size = 4,
++        .max_access_size = 8,
++    },
++    .impl = {
+         .min_access_size = 4,
+         .max_access_size = 4,
+     },
+-- 
+2.26.2
+
+
+
+On 05/12/2020 15:09, Philippe Mathieu-Daudé wrote:
+
+> Per the "NCR89C105 Chip Specification" referenced in the header:
+> 
+>                    Chip-level Address Map
+> 
+>    ------------------------------------------------------------------
+>    | 1D0 0000 ->   | Counter/Timers                        | W,D    |
+>    |   1DF FFFF    |                                       |        |
+>    ...
+> 
+>    The address map indicated the allowed accesses at each address.
+>    [...] W indicates a word access, and D indicates a double-word
+>    access.
+> 
+> The SLAVIO timer controller is implemented expecting 32-bit accesses.
+> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
+> the device allows 64-bit accesses.
+> 
+> This was not an issue until commit 5d971f9e67 which reverted
+> ("memory: accept mismatching sizes in memory_region_access_valid").
+> 
+> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
+> access range (W -> 4, D -> 8).
+> 
+> Since commit 21786c7e598 ("memory: Log invalid memory accesses")
+> this class of bug can be quickly debugged displaying 'guest_errors'
+> accesses, as:
+> 
+>    $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
+> 
+>    Power-ON Reset
+>    Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
+> 
+>    $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
+>    (qemu) info mtree
+>    address-space: memory
+>      0000000000000000-ffffffffffffffff (prio 0, i/o): system
+>        ...
+>        0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
+>               ^^^^^^^^^                                 ^^^^^^^
+>                     \ memory region base address and name /
+> 
+>    (qemu) info qtree
+>    bus: main-system-bus
+>      dev: slavio_timer, id ""              <-- device type name
+>        gpio-out "sysbus-irq" 17
+>        num_cpus = 1 (0x1)
+>        mmio 0000000ff1310000/0000000000000014
+>        mmio 0000000ff1300000/0000000000000010 <--- base address
+>        mmio 0000000ff1301000/0000000000000010
+>        mmio 0000000ff1302000/0000000000000010
+>        ...
+> 
+> Reported-by: Yap KV <email address hidden>
+> Buglink: https://bugs.launchpad.net/bugs/1906905
+> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
+> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+> ---
+> Cc: Benoit Canet <email address hidden>
+> Cc: <email address hidden>
+> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+> ---
+>   hw/timer/slavio_timer.c | 4 ++++
+>   1 file changed, 4 insertions(+)
+> 
+> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
+> index 5b2d20cb6a5..03e33fc5926 100644
+> --- a/hw/timer/slavio_timer.c
+> +++ b/hw/timer/slavio_timer.c
+> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
+>       .write = slavio_timer_mem_writel,
+>       .endianness = DEVICE_NATIVE_ENDIAN,
+>       .valid = {
+> +        .min_access_size = 4,
+> +        .max_access_size = 8,
+> +    },
+> +    .impl = {
+>           .min_access_size = 4,
+>           .max_access_size = 4,
+>       },
+
+I don't really use the proprietary Sun ROMs here, but the fix looks good to me:
+
+Reviewed-by: Mark Cave-Ayland <email address hidden>
+
+It's probably also worth a CC to qemu-stable to try and also get this into 5.1.1 to 
+accompany the related TCX issues.
+
+
+ATB,
+
+Mark.
+
+
+ping?
+
+On 12/5/20 4:09 PM, Philippe Mathieu-Daudé wrote:
+> Per the "NCR89C105 Chip Specification" referenced in the header:
+> 
+>                   Chip-level Address Map
+> 
+>   ------------------------------------------------------------------
+>   | 1D0 0000 ->   | Counter/Timers                        | W,D    |
+>   |   1DF FFFF    |                                       |        |
+>   ...
+> 
+>   The address map indicated the allowed accesses at each address.
+>   [...] W indicates a word access, and D indicates a double-word
+>   access.
+> 
+> The SLAVIO timer controller is implemented expecting 32-bit accesses.
+> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
+> the device allows 64-bit accesses.
+> 
+> This was not an issue until commit 5d971f9e67 which reverted
+> ("memory: accept mismatching sizes in memory_region_access_valid").
+> 
+> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
+> access range (W -> 4, D -> 8).
+> 
+> Since commit 21786c7e598 ("memory: Log invalid memory accesses")
+> this class of bug can be quickly debugged displaying 'guest_errors'
+> accesses, as:
+> 
+>   $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
+> 
+>   Power-ON Reset
+>   Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
+> 
+>   $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
+>   (qemu) info mtree
+>   address-space: memory
+>     0000000000000000-ffffffffffffffff (prio 0, i/o): system
+>       ...
+>       0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
+>              ^^^^^^^^^                                 ^^^^^^^
+>                    \ memory region base address and name /
+> 
+>   (qemu) info qtree
+>   bus: main-system-bus
+>     dev: slavio_timer, id ""              <-- device type name
+>       gpio-out "sysbus-irq" 17
+>       num_cpus = 1 (0x1)
+>       mmio 0000000ff1310000/0000000000000014
+>       mmio 0000000ff1300000/0000000000000010 <--- base address
+>       mmio 0000000ff1301000/0000000000000010
+>       mmio 0000000ff1302000/0000000000000010
+>       ...
+> 
+> Reported-by: Yap KV <email address hidden>
+> Buglink: https://bugs.launchpad.net/bugs/1906905
+> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
+> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+> ---
+> Cc: Benoit Canet <email address hidden>
+> Cc: <email address hidden>
+> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+> ---
+>  hw/timer/slavio_timer.c | 4 ++++
+>  1 file changed, 4 insertions(+)
+> 
+> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
+> index 5b2d20cb6a5..03e33fc5926 100644
+> --- a/hw/timer/slavio_timer.c
+> +++ b/hw/timer/slavio_timer.c
+> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
+>      .write = slavio_timer_mem_writel,
+>      .endianness = DEVICE_NATIVE_ENDIAN,
+>      .valid = {
+> +        .min_access_size = 4,
+> +        .max_access_size = 8,
+> +    },
+> +    .impl = {
+>          .min_access_size = 4,
+>          .max_access_size = 4,
+>      },
+> 
+
+
+On 05/01/2021 11:06, Philippe Mathieu-Daudé wrote:
+
+> ping?
+> 
+> On 12/5/20 4:09 PM, Philippe Mathieu-Daudé wrote:
+>> Per the "NCR89C105 Chip Specification" referenced in the header:
+>>
+>>                    Chip-level Address Map
+>>
+>>    ------------------------------------------------------------------
+>>    | 1D0 0000 ->   | Counter/Timers                        | W,D    |
+>>    |   1DF FFFF    |                                       |        |
+>>    ...
+>>
+>>    The address map indicated the allowed accesses at each address.
+>>    [...] W indicates a word access, and D indicates a double-word
+>>    access.
+>>
+>> The SLAVIO timer controller is implemented expecting 32-bit accesses.
+>> Commit a3d12d073e1 restricted the memory accesses to 32-bit, while
+>> the device allows 64-bit accesses.
+>>
+>> This was not an issue until commit 5d971f9e67 which reverted
+>> ("memory: accept mismatching sizes in memory_region_access_valid").
+>>
+>> Fix by renaming .valid MemoryRegionOps as .impl, and add the valid
+>> access range (W -> 4, D -> 8).
+>>
+>> Since commit 21786c7e598 ("memory: Log invalid memory accesses")
+>> this class of bug can be quickly debugged displaying 'guest_errors'
+>> accesses, as:
+>>
+>>    $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors
+>>
+>>    Power-ON Reset
+>>    Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4)
+>>
+>>    $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S
+>>    (qemu) info mtree
+>>    address-space: memory
+>>      0000000000000000-ffffffffffffffff (prio 0, i/o): system
+>>        ...
+>>        0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1
+>>               ^^^^^^^^^                                 ^^^^^^^
+>>                     \ memory region base address and name /
+>>
+>>    (qemu) info qtree
+>>    bus: main-system-bus
+>>      dev: slavio_timer, id ""              <-- device type name
+>>        gpio-out "sysbus-irq" 17
+>>        num_cpus = 1 (0x1)
+>>        mmio 0000000ff1310000/0000000000000014
+>>        mmio 0000000ff1300000/0000000000000010 <--- base address
+>>        mmio 0000000ff1301000/0000000000000010
+>>        mmio 0000000ff1302000/0000000000000010
+>>        ...
+>>
+>> Reported-by: Yap KV <email address hidden>
+>> Buglink: https://bugs.launchpad.net/bugs/1906905
+>> Fixes: a3d12d073e1 ("slavio_timer: convert to memory API")
+>> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+>> ---
+>> Cc: Benoit Canet <email address hidden>
+>> Cc: <email address hidden>
+>> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+>> ---
+>>   hw/timer/slavio_timer.c | 4 ++++
+>>   1 file changed, 4 insertions(+)
+>>
+>> diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c
+>> index 5b2d20cb6a5..03e33fc5926 100644
+>> --- a/hw/timer/slavio_timer.c
+>> +++ b/hw/timer/slavio_timer.c
+>> @@ -331,6 +331,10 @@ static const MemoryRegionOps slavio_timer_mem_ops = {
+>>       .write = slavio_timer_mem_writel,
+>>       .endianness = DEVICE_NATIVE_ENDIAN,
+>>       .valid = {
+>> +        .min_access_size = 4,
+>> +        .max_access_size = 8,
+>> +    },
+>> +    .impl = {
+>>           .min_access_size = 4,
+>>           .max_access_size = 4,
+>>       },
+
+Looks like I did queue this to my local qemu-sparc branch, but was waiting to see if 
+there was feedback on the other outstanding SPARC patches before sending a PR. The 
+patches are all fairly minor, however I would prefer an Ack for the outstanding LEON 
+patchset first. I'll go chase that one up now.
+
+
+ATB,
+
+Mark.
+
+
+Fix has been included here:
+https://gitlab.com/qemu-project/qemu/-/commit/62a9b228b5fefe0f9e364d
+
diff --git a/results/classifier/118/hypervisor/1908626 b/results/classifier/118/hypervisor/1908626
new file mode 100644
index 00000000..bbbd6457
--- /dev/null
+++ b/results/classifier/118/hypervisor/1908626
@@ -0,0 +1,192 @@
+hypervisor: 0.818
+mistranslation: 0.800
+graphic: 0.786
+virtual: 0.771
+TCG: 0.757
+user-level: 0.757
+ppc: 0.750
+vnc: 0.747
+peripherals: 0.737
+debug: 0.728
+risc-v: 0.722
+assembly: 0.716
+x86: 0.714
+device: 0.714
+VMM: 0.713
+KVM: 0.707
+architecture: 0.705
+i386: 0.697
+register: 0.695
+performance: 0.680
+arm: 0.678
+semantic: 0.675
+PID: 0.661
+network: 0.649
+permissions: 0.638
+files: 0.586
+socket: 0.570
+boot: 0.545
+kernel: 0.538
+
+Atomic test-and-set instruction does not work on qemu-user
+
+I try to compile and run PostgreSQL/Greenplum database inside docker container/qemu-aarch64-static:
+```
+ host: CentOS7 x86_64
+ container: centos:centos7.9.2009 --platform linux/arm64/v8
+ qemu-user-static: https://github.com/multiarch/qemu-user-static/releases/
+```
+
+However, GP/PG's spinlock always gets stuck and reports PANIC errors. It seems its spinlock
+has something wrong.
+```
+https://github.com/greenplum-db/gpdb/blob/master/src/include/storage/s_lock.h
+https://github.com/greenplum-db/gpdb/blob/master/src/backend/storage/lmgr/s_lock.c
+```
+
+So I extract its spinlock implementation into one test C source file (see attachment file),
+and get reprodcued:
+
+```
+$ gcc spinlock_qemu.c
+$ ./a.out 
+C -- slock inited, lock value is: 0
+parent 139642, child 139645
+P -- slock lock before, lock value is: 0
+P -- slock locked, lock value is: 1
+P -- slock unlock after, lock value is: 0
+C -- slock lock before, lock value is: 1
+P -- slock lock before, lock value is: 1
+C -- slock locked, lock value is: 1
+C -- slock unlock after, lock value is: 0
+C -- slock lock before, lock value is: 1
+P -- slock locked, lock value is: 1
+P -- slock unlock after, lock value is: 0
+P -- slock lock before, lock value is: 1
+C -- slock locked, lock value is: 1
+C -- slock unlock after, lock value is: 0
+P -- slock locked, lock value is: 1
+C -- slock lock before, lock value is: 1
+P -- slock unlock after, lock value is: 0
+C -- slock locked, lock value is: 1
+P -- slock lock before, lock value is: 1
+C -- slock unlock after, lock value is: 0
+P -- slock locked, lock value is: 1
+C -- slock lock before, lock value is: 1
+P -- slock unlock after, lock value is: 0
+C -- slock locked, lock value is: 1
+P -- slock lock before, lock value is: 1
+C -- slock unlock after, lock value is: 0
+P -- slock locked, lock value is: 1
+C -- slock lock before, lock value is: 1
+P -- slock unlock after, lock value is: 0
+P -- slock lock before, lock value is: 1
+spin timeout, lock value is 1 (pid 139642)
+spin timeout, lock value is 1 (pid 139645)
+spin timeout, lock value is 1 (pid 139645)
+spin timeout, lock value is 1 (pid 139642)
+spin timeout, lock value is 1 (pid 139645)
+spin timeout, lock value is 1 (pid 139642)
+...
+...
+...
+```
+
+NOTE: this code always works on PHYSICAL ARM64 server.
+
+
+
+Interestingly, the spinlock test works after I change tas() implementation
+FROM
+  __sync_lock_test_and_set(lock, 1);
+TO
+  __sync_val_compare_and_swap(lock, 0, 1);
+
+## gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)
+
+====
+__sync_lock_test_and_set(lock, 1) disassembly:
+
+```
+objdump -S a.out
+
+000000000040073c <tas>:
+  40073c:	d10043ff 	sub	sp, sp, #0x10
+  400740:	f90007e0 	str	x0, [sp, #8]
+  400744:	f94007e0 	ldr	x0, [sp, #8]
+  400748:	52800021 	mov	w1, #0x1                   	// #1
+  40074c:	885f7c02 	ldxr	w2, [x0]
+  400750:	88037c01 	stxr	w3, w1, [x0]
+  400754:	35ffffc3 	cbnz	w3, 40074c <tas+0x10>
+  400758:	d5033bbf 	dmb	ish
+  40075c:	2a0203e0 	mov	w0, w2
+  400760:	910043ff 	add	sp, sp, #0x10
+  400764:	d65f03c0 	ret
+```
+
+====
+__sync_val_compare_and_swap(lock, 0, 1); disassembly:
+
+```
+objdump -S a.out
+
+000000000040073c <tas>:
+  40073c:	d10043ff 	sub	sp, sp, #0x10
+  400740:	f90007e0 	str	x0, [sp, #8]
+  400744:	f94007e0 	ldr	x0, [sp, #8]
+  400748:	52800021 	mov	w1, #0x1                   	// #1
+  40074c:	885f7c02 	ldxr	w2, [x0]
+  400750:	35000062 	cbnz	w2, 40075c <tas+0x20>
+  400754:	8803fc01 	stlxr	w3, w1, [x0]
+  400758:	35ffffa3 	cbnz	w3, 40074c <tas+0x10>
+  40075c:	7100005f 	cmp	w2, #0x0
+  400760:	d5033bbf 	dmb	ish
+  400764:	2a0203e0 	mov	w0, w2
+  400768:	910043ff 	add	sp, sp, #0x10
+  40076c:	d65f03c0 	ret
+```
+
+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.]
+
+
+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/509
+
+
+Hi taos! Could you please check whether this has been fixed already in QEMU v6.1.0-rc1 ?
+
+Thanks. Tested, the problem is gone.
+
diff --git a/results/classifier/118/hypervisor/1911075 b/results/classifier/118/hypervisor/1911075
new file mode 100644
index 00000000..f6713ab3
--- /dev/null
+++ b/results/classifier/118/hypervisor/1911075
@@ -0,0 +1,112 @@
+hypervisor: 0.882
+virtual: 0.874
+peripherals: 0.870
+debug: 0.867
+performance: 0.863
+permissions: 0.862
+risc-v: 0.857
+user-level: 0.855
+device: 0.854
+graphic: 0.851
+register: 0.842
+TCG: 0.813
+vnc: 0.793
+semantic: 0.791
+architecture: 0.790
+VMM: 0.788
+arm: 0.779
+mistranslation: 0.777
+ppc: 0.775
+x86: 0.775
+i386: 0.764
+KVM: 0.760
+boot: 0.749
+files: 0.745
+assembly: 0.733
+kernel: 0.729
+PID: 0.726
+socket: 0.689
+network: 0.670
+
+[OSS-Fuzz] ahci: stack overflow in ahci_cond_start_engines
+
+=== Reproducer ===
+while true; do cat << EOF; done | ./qemu-system-i386 -machine q35 -nodefaults -nographic -qtest stdio -accel qtest
+outl 0xcf8 0x8000fa27
+outl 0xcfc 0x37414537
+outl 0xcf8 0x8000fa01
+outl 0xcfc 0x4606ce74
+writew 0x37000f01 0x215a
+writeq 0x37000100 0xfffaf
+writeq 0x37000115 0xffff373d27004037
+outl 0xcf8 0x8000fa01
+outl 0xcfc 0x4606ce74
+writeq 0x370000ff 0x3700011500
+writeq 0x37000115 0xc41ffffff035a5a
+outl 0xcf8 0x8000ea04
+outb 0xcfc 0x15
+outl 0xcf8 0x8000ea00
+outw 0xcfc 0x5a1f
+writeq 0x37000115 0x100007765746972
+writeq 0x37000115 0xbf00000000000000
+outl 0xcf8 0x8000ea04
+outb 0xcfc 0x15
+outl 0xcf8 0x8000fa46
+outb 0xcfc 0xff
+clock_step
+writeq 0x37000115 0xaf
+writeq 0x37000115 0x6301275541af7415
+writeq 0x37000115 0xafaf5a5a743715
+outb 0x64 0xfe
+EOF
+
+=== Stack Trace ===
+==887446==ERROR: UndefinedBehaviorSanitizer: stack-overflow on address 0x7ffe567cae0c (pc 0x7fdd9100819e bp 0x7ffe567cb2b0 sp 0x7ffe567cad40 T887446)
+
+#0 vfprintf
+#1 fprintf
+#2 ahci_mem_write /src/qemu/hw/ide/ahci.c:468:9
+#3 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5
+#4 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18
+#5 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13
+#6 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23
+#7 flatview_write /src/qemu/softmmu/physmem.c:2799:14
+#8 address_space_write /src/qemu/softmmu/physmem.c:2891:18
+#9 address_space_unmap /src/qemu/softmmu/physmem.c:3217:9
+#10 dma_memory_unmap /src/qemu/include/sysemu/dma.h:226:5
+#11 map_page /src/qemu/hw/ide/ahci.c:249:9
+#12 ahci_map_clb_address /src/qemu/hw/ide/ahci.c:748:5
+#13 ahci_cond_start_engines /src/qemu/hw/ide/ahci.c:276:14
+#14 ahci_port_write /src/qemu/hw/ide/ahci.c:339:9
+#15 ahci_mem_write /src/qemu/hw/ide/ahci.c:513:9
+#16 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5
+#17 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18
+#18 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13
+#19 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23
+#20 flatview_write /src/qemu/softmmu/physmem.c:2799:14
+#21 address_space_write /src/qemu/softmmu/physmem.c:2891:18
+#22 address_space_unmap /src/qemu/softmmu/physmem.c:3217:9
+#23 dma_memory_unmap /src/qemu/include/sysemu/dma.h:226:5
+#24 map_page /src/qemu/hw/ide/ahci.c:249:9
+#25 ahci_map_clb_address /src/qemu/hw/ide/ahci.c:748:5
+#26 ahci_cond_start_engines /src/qemu/hw/ide/ahci.c:276:14
+#27 ahci_port_write /src/qemu/hw/ide/ahci.c:339:9
+#28 ahci_mem_write /src/qemu/hw/ide/ahci.c:513:9
+... Repeat until we run out of stack
+
+Having a quick look, the problem might be in ahci_cond_start_engines()
+which calls ahci_map_clb_address(), then ahci_map_fis_address() fails
+and we return without calling ahci_unmap_clb_address().
+
+And ahci_port_write(AHCI_PORT_REG_CMD) doesn't check
+ahci_cond_start_engines() return value, calling
+ahci_init_d2h() even if former failed.
+
+
+This is an automated cleanup. This bug report has been moved
+to QEMU's new bug tracker on gitlab.com and thus gets marked
+as 'expired' now. Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/62
+
+
diff --git a/results/classifier/118/hypervisor/1919036 b/results/classifier/118/hypervisor/1919036
new file mode 100644
index 00000000..a3cac68b
--- /dev/null
+++ b/results/classifier/118/hypervisor/1919036
@@ -0,0 +1,195 @@
+hypervisor: 0.822
+risc-v: 0.787
+KVM: 0.736
+mistranslation: 0.729
+peripherals: 0.728
+user-level: 0.724
+ppc: 0.712
+i386: 0.701
+x86: 0.700
+graphic: 0.689
+TCG: 0.677
+performance: 0.657
+virtual: 0.655
+VMM: 0.654
+register: 0.650
+vnc: 0.633
+permissions: 0.618
+device: 0.608
+semantic: 0.584
+architecture: 0.577
+files: 0.547
+arm: 0.533
+assembly: 0.523
+boot: 0.491
+socket: 0.489
+PID: 0.488
+kernel: 0.479
+network: 0.477
+debug: 0.472
+
+Assertion failure in fifo8_push_all() through am53c974
+
+Hello,
+
+Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator.
+
+A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service.
+
+This was found in version 5.2.0 (master, 3f8d1885e4)
+
+
+```
+qemu-system-i386: ../util/fifo8.c:43: fifo8_push_all: Assertion `fifo->num + num <= fifo->capacity' failed.
+
+#0  0x00007ffff0218fb7 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
+#1  0x00007ffff021a921 in __GI_abort () at abort.c:79
+#2  0x00007ffff020a48a in __assert_fail_base (fmt=0x7ffff0391750 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x555558ed2400 "fifo->num + num <= fifo->capacity", file=file@entry=0x555558ed2380 "../util/fifo8.c", line=line@entry=0x2b, function=function@entry=0x555558ed2560 <__PRETTY_FUNCTION__.16583> "fifo8_push_all")
+    at assert.c:92
+#3  0x00007ffff020a502 in __GI___assert_fail (assertion=assertion@entry=0x555558ed2400 "fifo->num + num <= fifo->capacity", file=file@entry=0x555558ed2380 "../util/fifo8.c", line=line@entry=0x2b, function=function@entry=0x555558ed2560 <__PRETTY_FUNCTION__.16583> "fifo8_push_all") at assert.c:101
+#4  0x00005555587749c4 in fifo8_push_all (fifo=fifo@entry=0x61f000005200, data=data@entry=0x7fff72bfa640 "", num=num@entry=0x24) at ../util/fifo8.c:43
+#5  0x00005555572bd13e in esp_do_dma (s=s@entry=0x61f000005088) at ../hw/scsi/esp.c:577
+#6  0x00005555572bfc8f in handle_ti (s=0x61f000005088) at ../hw/scsi/esp.c:845
+#7  0x00005555572c419c in esp_reg_write (s=0x61f000005088, saddr=saddr@entry=0x3, val=<optimized out>)
+    at ../hw/scsi/esp.c:987
+#8  0x0000555557bb916a in esp_pci_io_write (opaque=0x61f000004680, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at ../hw/scsi/esp-pci.c:214
+#9  0x000055555817ea28 in memory_region_write_accessor (mr=0x61f000004f70, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at ../softmmu/memory.c:491
+#10 0x0000555558176671 in access_with_adjusted_size (addr=addr@entry=0xc, value=value@entry=0x7fff72bfb2a8, size=size@entry=0x1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=
+    0x55555817e7c0 <memory_region_write_accessor>, mr=0x61f000004f70, attrs=...) at ../softmmu/memory.c:552
+#11 0x00005555581892aa in memory_region_dispatch_write (mr=mr@entry=0x61f000004f70, addr=<optimized out>, data=<optimized out>, data@entry=0xffffff90, op=op@entry=MO_8, attrs=..., attrs@entry=...) at ../softmmu/memory.c:1508
+#12 0x0000555558024b66 in address_space_stb (as=<optimized out>, addr=<optimized out>, val=<optimized out>, attrs=..., result=0x0) at /home/cwmyung/prj/hyfuzz/src/qemu-master/memory_ldst.c.inc:382
+#13 0x00007fff9323641c in code_gen_buffer ()
+#14 0x0000555557e793bb in cpu_tb_exec (tb_exit=<optimized out>, itb=<optimized out>, cpu=0x62e0000004b4)
+    at ../accel/tcg/cpu-exec.c:190
+#15 0x0000555557e793bb in cpu_loop_exec_tb (tb_exit=<optimized out>, last_tb=<optimized out>, tb=<optimized out>, cpu=0x62e0000004b4) at ../accel/tcg/cpu-exec.c:673
+#16 0x0000555557e793bb in cpu_exec (cpu=cpu@entry=0x62e000000400) at ../accel/tcg/cpu-exec.c:798
+#17 0x0000555557f5fc5a in tcg_cpus_exec (cpu=cpu@entry=0x62e000000400) at ../accel/tcg/tcg-accel-ops.c:68
+#18 0x00005555582260af in mttcg_cpu_thread_fn (arg=arg@entry=0x62e000000400) at ../accel/tcg/tcg-accel-ops-mttcg.c:70
+#19 0x0000555558777b05 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:521
+#20 0x00007ffff05d26db in start_thread (arg=0x7fff72bff700) at pthread_create.c:463
+#21 0x00007ffff02fb71f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+```
+
+
+To reproduce the assertion failure, please run the QEMU with the following command line.
+
+```
+
+$ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img
+
+```
+
+Please let me know if I can provide any further info.
+
+Thank you.
+
+- Cheolwoo, Myung (Seoul National University)
+
+
+
+Thanks for the test case - looks like the problem occurs because a command hasn't been submitted before initiating a DMA transfer, and TC is set to a value higher than the size of cmdfifo. Can you confirm that the following fix works for you?
+
+diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
+index 507ab363bc..0a26ee1dfd 100644
+--- a/hw/scsi/esp.c
++++ b/hw/scsi/esp.c
+@@ -573,6 +573,7 @@ static void esp_do_dma(ESPState *s)
+         cmdlen = fifo8_num_used(&s->cmdfifo);
+         trace_esp_do_dma(cmdlen, len);
+         if (s->dma_memory_read) {
++            len = MIN(len, fifo8_num_free(&s->cmdfifo));
+             s->dma_memory_read(s->dma_opaque, buf, len);
+             fifo8_push_all(&s->cmdfifo, buf, len);
+         } else {
+
+
+ATB,
+
+Mark.
+
+QTest Reproducer:
+/*
+ * Autogenerated Fuzzer Test Case
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later. See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+
+#include "libqos/libqtest.h"
+
+/*
+ * cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, \
+ * -m 512M -device am53c974,id=scsi -device scsi-hd,drive=disk0 -drive \
+ * id=disk0,if=none,file=null-co://,format=raw -nodefaults -qtest stdio
+ * outl 0xcf8 0x80001004
+ * outw 0xcfc 0x01
+ * outl 0xcf8 0x8000100e
+ * outl 0xcfc 0x0e000000
+ * outl 0xe40 0x03
+ * outl 0xe0b 0x4100
+ * outl 0xe0b 0x9000
+ * EOF
+ */
+static void test_fuzz(void)
+{
+    QTestState *s = qtest_init(
+        "-display none , -m 512M -device am53c974,id=scsi -device "
+        "scsi-hd,drive=disk0 -drive "
+        "id=disk0,if=none,file=null-co://,format=raw -nodefaults");
+    qtest_outl(s, 0xcf8, 0x80001004);
+    qtest_outw(s, 0xcfc, 0x01);
+    qtest_outl(s, 0xcf8, 0x8000100e);
+    qtest_outl(s, 0xcfc, 0x0e000000);
+    qtest_outl(s, 0xe40, 0x03);
+    qtest_outl(s, 0xe0b, 0x4100);
+    qtest_outl(s, 0xe0b, 0x9000);
+    qtest_quit(s);
+}
+int main(int argc, char **argv)
+{
+    const char *arch = qtest_get_arch();
+
+    g_test_init(&argc, &argv, NULL);
+
+    if (strcmp(arch, "i386") == 0) {
+        qtest_add_func("fuzz/test_fuzz", test_fuzz);
+    }
+
+    return g_test_run();
+}
+
+
+Hello Mark,
+
+I tested on fixed version, and checked that it does not trigger the assertion failure.
+
+Thanks,
+- Cheolwoo Myung
+
+Thank you both for the reproducers. Please see the proposed patchset here:
+
+https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg06063.html
+
+
+This is fixed now, thank you Mark.
+
+Patchset v4:
+https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01000.html
+
+Upstream commits:
+https://git.qemu.org/?p=qemu.git;a=commit;h=0db895361b8a82e1114372ff9f48
+https://git.qemu.org/?p=qemu.git;a=commit;h=e392255766071c8cac480da3a9ae
+https://git.qemu.org/?p=qemu.git;a=commit;h=e5455b8c1c6170c788f3c0fd577c
+https://git.qemu.org/?p=qemu.git;a=commit;h=c5fef9112b15c4b5494791cdf8bb
+https://git.qemu.org/?p=qemu.git;a=commit;h=7b320a8e67a534925048cbabfa51
+https://git.qemu.org/?p=qemu.git;a=commit;h=99545751734035b76bd372c4e721
+https://git.qemu.org/?p=qemu.git;a=commit;h=fa7505c154d4d00ad89a747be2ed
+https://git.qemu.org/?p=qemu.git;a=commit;h=fbc6510e3379fa8f8370bf71198f
+https://git.qemu.org/?p=qemu.git;a=commit;h=0ebb5fd80589835153a0c2baa1b8
+https://git.qemu.org/?p=qemu.git;a=commit;h=324c8809897c8c53ad05c3a7147d
+https://git.qemu.org/?p=qemu.git;a=commit;h=607206948cacda4a80be5b976dba
+
+I'm not able to change the status of this bug anymore. It should have been closed as "Fix committed" - QEMU 6.0.0 is not yet released.
+
diff --git a/results/classifier/118/hypervisor/1925 b/results/classifier/118/hypervisor/1925
new file mode 100644
index 00000000..8b5fa076
--- /dev/null
+++ b/results/classifier/118/hypervisor/1925
@@ -0,0 +1,41 @@
+risc-v: 0.968
+hypervisor: 0.963
+architecture: 0.933
+graphic: 0.922
+virtual: 0.887
+kernel: 0.884
+network: 0.859
+performance: 0.856
+PID: 0.855
+debug: 0.837
+device: 0.837
+semantic: 0.832
+register: 0.830
+vnc: 0.818
+mistranslation: 0.783
+socket: 0.781
+files: 0.757
+arm: 0.746
+permissions: 0.744
+boot: 0.706
+ppc: 0.695
+VMM: 0.687
+assembly: 0.663
+peripherals: 0.662
+TCG: 0.635
+x86: 0.540
+user-level: 0.496
+KVM: 0.487
+i386: 0.360
+
+RISC-V 64 System Emulator fdt imporperly created after machine init is done
+Description of problem:
+In commit 49554856 the creation of FDT is moved to `virt_machine_done()`
+However, adding guest loader device requires the presence of fdt at `hw/core/guest-loader.c:50` when the fdt ptr is still 0x0.
+Thus adding of guest loader device will fail.
+Steps to reproduce:
+1. Compile Qemu with riscv64 system emulator target
+2. Compile Xen hypervisor platform (not necessary)
+3. Instruct Qemu start with virt machine and any valid guest-loader device specification.
+Additional information:
+Commit that changes order of fdt creation: 49554856f0b6f622ab6afdcc275d4ab2ecb3625c
diff --git a/results/classifier/118/hypervisor/1926596 b/results/classifier/118/hypervisor/1926596
new file mode 100644
index 00000000..be15ac13
--- /dev/null
+++ b/results/classifier/118/hypervisor/1926596
@@ -0,0 +1,97 @@
+hypervisor: 0.974
+virtual: 0.965
+KVM: 0.961
+debug: 0.958
+graphic: 0.921
+VMM: 0.857
+user-level: 0.853
+ppc: 0.842
+device: 0.840
+performance: 0.827
+semantic: 0.807
+register: 0.802
+risc-v: 0.786
+permissions: 0.778
+PID: 0.774
+mistranslation: 0.759
+peripherals: 0.747
+kernel: 0.735
+architecture: 0.718
+x86: 0.702
+files: 0.702
+network: 0.700
+arm: 0.645
+vnc: 0.631
+socket: 0.615
+TCG: 0.574
+i386: 0.548
+assembly: 0.493
+boot: 0.457
+
+qemu-monitor-event command gets stuck randomly
+
+We are using kvm virtualization on our servers, We use "qemu-monitor-command"(drive-backup) to take qcow2 backups and to monitor them we use "qemu-monitor-event" command 
+For eg:-
+/usr/bin/virsh qemu-monitor-event VPSNAME --event "BLOCK_JOB_COMPLETED\|BLOCK_JOB_ERROR" --regex
+
+the above command stucks randomly (backup completes but still it is waiting) and because of which other vms backup are stucked until we kill that process.
+
+Can you suggest how can we debug this further to find the actual issue.
+
+
+/usr/bin/virsh version
+
+Compiled against library: libvirt 4.5.0
+Using library: libvirt 4.5.0
+Using API: QEMU 4.5.0
+Running hypervisor: QEMU 2.0.0
+
+cat /etc/os-release
+NAME="CentOS Linux"
+VERSION="7 (Core)"
+ID="centos"
+ID_LIKE="rhel fedora"
+VERSION_ID="7"
+PRETTY_NAME="CentOS Linux 7 (Core)"
+ANSI_COLOR="0;31"
+CPE_NAME="cpe:/o:centos:centos:7"
+HOME_URL="https://www.centos.org/"
+BUG_REPORT_URL="https://bugs.centos.org/"
+
+CENTOS_MANTISBT_PROJECT="CentOS-7"
+CENTOS_MANTISBT_PROJECT_VERSION="7"
+REDHAT_SUPPORT_PRODUCT="centos"
+REDHAT_SUPPORT_PRODUCT_VERSION="7"
+
+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/hypervisor/2363 b/results/classifier/118/hypervisor/2363
new file mode 100644
index 00000000..0a853916
--- /dev/null
+++ b/results/classifier/118/hypervisor/2363
@@ -0,0 +1,31 @@
+architecture: 0.945
+hypervisor: 0.924
+KVM: 0.912
+device: 0.835
+virtual: 0.693
+debug: 0.544
+network: 0.523
+user-level: 0.477
+arm: 0.431
+graphic: 0.412
+mistranslation: 0.412
+semantic: 0.360
+performance: 0.348
+boot: 0.312
+register: 0.312
+assembly: 0.302
+socket: 0.231
+files: 0.229
+PID: 0.226
+risc-v: 0.209
+ppc: 0.174
+vnc: 0.174
+kernel: 0.171
+peripherals: 0.154
+i386: 0.146
+permissions: 0.134
+TCG: 0.111
+VMM: 0.103
+x86: 0.099
+
+How can I enable MBI support in QEMU when running in KVM mode?
diff --git a/results/classifier/118/hypervisor/2862 b/results/classifier/118/hypervisor/2862
new file mode 100644
index 00000000..65a8cea9
--- /dev/null
+++ b/results/classifier/118/hypervisor/2862
@@ -0,0 +1,54 @@
+hypervisor: 0.971
+virtual: 0.951
+graphic: 0.942
+mistranslation: 0.932
+performance: 0.912
+user-level: 0.901
+assembly: 0.892
+vnc: 0.884
+architecture: 0.883
+PID: 0.870
+debug: 0.870
+device: 0.854
+peripherals: 0.844
+files: 0.837
+KVM: 0.835
+network: 0.830
+socket: 0.818
+VMM: 0.818
+semantic: 0.818
+ppc: 0.803
+arm: 0.766
+permissions: 0.752
+register: 0.740
+kernel: 0.737
+risc-v: 0.720
+i386: 0.688
+x86: 0.679
+TCG: 0.623
+boot: 0.602
+
+unable to complete install when i try to load into qemu
+Description of problem:
+when i load up a vm, i get the message Unable to complete install: 'internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found'
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install
+    installer.start_install(guest, meter=meter)
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 695, in start_install
+    domain = self._create_guest(
+             ^^^^^^^^^^^^^^^^^^^
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest
+    domain = self.conn.createXML(initial_xml or final_xml, 0)
+             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/usr/lib/python3/dist-packages/libvirt.py", line 4481, in createXML
+    raise libvirtError('virDomainCreateXML() failed')
+libvirt.libvirtError: internal error: process exited while connecting to monitor: 2025-03-14T01:54:54.436804Z qemu-system-aarch64: can't apply global host-arm-cpu.hv-relaxed=on: Property 'host-arm-cpu.hv-relaxed' not found. If it's important, vmm recognizes my windows 10 iso as a windows 11.
+Steps to reproduce:
+1.i just tried to use the vm.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/118/hypervisor/2877 b/results/classifier/118/hypervisor/2877
new file mode 100644
index 00000000..3f7e422d
--- /dev/null
+++ b/results/classifier/118/hypervisor/2877
@@ -0,0 +1,31 @@
+hypervisor: 0.905
+device: 0.808
+network: 0.587
+arm: 0.546
+architecture: 0.541
+performance: 0.541
+graphic: 0.420
+vnc: 0.332
+semantic: 0.289
+virtual: 0.282
+register: 0.280
+VMM: 0.259
+risc-v: 0.255
+permissions: 0.225
+mistranslation: 0.224
+socket: 0.223
+debug: 0.205
+user-level: 0.198
+ppc: 0.193
+files: 0.179
+PID: 0.158
+boot: 0.133
+peripherals: 0.130
+TCG: 0.118
+x86: 0.101
+kernel: 0.075
+KVM: 0.056
+i386: 0.053
+assembly: 0.047
+
+Windows Hypervisor Acceleration does not work in Qemu 9.5.20 on Windows 11 24H2 Host
diff --git a/results/classifier/118/hypervisor/2887 b/results/classifier/118/hypervisor/2887
new file mode 100644
index 00000000..690af620
--- /dev/null
+++ b/results/classifier/118/hypervisor/2887
@@ -0,0 +1,31 @@
+hypervisor: 0.917
+device: 0.852
+files: 0.804
+debug: 0.763
+virtual: 0.734
+architecture: 0.681
+boot: 0.450
+graphic: 0.418
+arm: 0.402
+semantic: 0.302
+performance: 0.287
+register: 0.211
+risc-v: 0.210
+ppc: 0.200
+VMM: 0.195
+vnc: 0.173
+mistranslation: 0.164
+permissions: 0.136
+i386: 0.128
+network: 0.126
+peripherals: 0.084
+x86: 0.075
+user-level: 0.060
+PID: 0.035
+assembly: 0.018
+socket: 0.013
+TCG: 0.012
+kernel: 0.003
+KVM: 0.001
+
+Qemu VM WHPX Startup Error with OVMF Code and VARS UEFI Files
diff --git a/results/classifier/118/hypervisor/430 b/results/classifier/118/hypervisor/430
new file mode 100644
index 00000000..d7ac5aa6
--- /dev/null
+++ b/results/classifier/118/hypervisor/430
@@ -0,0 +1,31 @@
+hypervisor: 0.990
+performance: 0.927
+device: 0.921
+virtual: 0.895
+arm: 0.668
+risc-v: 0.612
+architecture: 0.570
+debug: 0.513
+graphic: 0.466
+semantic: 0.317
+network: 0.287
+ppc: 0.229
+vnc: 0.228
+mistranslation: 0.219
+user-level: 0.218
+register: 0.198
+boot: 0.178
+VMM: 0.163
+permissions: 0.124
+files: 0.111
+i386: 0.090
+PID: 0.069
+x86: 0.064
+socket: 0.056
+peripherals: 0.056
+assembly: 0.041
+TCG: 0.036
+kernel: 0.003
+KVM: 0.000
+
+Microsoft Hyper-V acceleration not working
diff --git a/results/classifier/118/hypervisor/463 b/results/classifier/118/hypervisor/463
new file mode 100644
index 00000000..c5d02d8a
--- /dev/null
+++ b/results/classifier/118/hypervisor/463
@@ -0,0 +1,55 @@
+hypervisor: 0.877
+performance: 0.873
+peripherals: 0.868
+TCG: 0.860
+VMM: 0.853
+user-level: 0.852
+i386: 0.851
+virtual: 0.846
+debug: 0.836
+ppc: 0.832
+register: 0.825
+permissions: 0.816
+device: 0.811
+risc-v: 0.808
+architecture: 0.801
+arm: 0.791
+graphic: 0.789
+KVM: 0.788
+boot: 0.782
+vnc: 0.780
+PID: 0.762
+files: 0.748
+x86: 0.742
+socket: 0.738
+assembly: 0.737
+kernel: 0.734
+semantic: 0.732
+network: 0.712
+mistranslation: 0.647
+
+[Build][git]Build process stop in libqemuutil.a.p/qobject_json-streamer.c.o
+Description of problem:
+Hello.
+
+I tried qemu to get build with revision 9aef0954195cc592e86846dbbe7f3c2c5603690a but it stops really quick at task 238/9335.
+
+Here is the beginning of the error log:
+
+```
+[238/9335] Compiling C object libqemuutil.a.p/qobject_json-streamer.c.o
+FAILED: libqemuutil.a.p/qobject_json-streamer.c.o 
+cc -Ilibqemuutil.a.p -I. -I.. -Isubprojects/libvhost-user -I../subprojects/libvhost-user -Itrace -Iqapi -Iui -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/pixman-1 -fdiagnostics-color=auto -pipe -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /build/qemu-git/src/qemu/linux-headers -isystem linux-headers -iquote . -iquote /build/qemu-git/src/qemu -iquote /build/qemu-git/src/qemu/include -iquote /build/qemu-git/src/qemu/disas/libvixl -iquote /build/qemu-git/src/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fPIC -MD -MQ libqemuutil.a.p/qobject_json-streamer.c.o -MF libqemuutil.a.p/qobject_json-streamer.c.o.d -o libqemuutil.a.p/qobject_json-streamer.c.o -c ../qobject/json-streamer.c
+In file included from ../qobject/json-streamer.c:14:
+/build/qemu-git/src/qemu/include/qemu/osdep.h:259:58: error: operator '&&' has no right operand
+  259 | #if defined(HAVE_BROKEN_SIZE_MAX) && HAVE_BROKEN_SIZE_MAX
+      |   
+```
+Steps to reproduce:
+1. Grab qemu-git code at commit 9aef0954195cc592e86846dbbe7f3c2c5603690a
+2. use these configure options: --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libexecdir=/usr/lib/qemu --smbd=/usr/bin/smbd --enable-modules --enable-sdl --disable-werror --enable-vhost-user --enable-slirp=system --enable-xfsctl --audio-drv-list="pa alsa sdl"
+3. run building process.
+Additional information:
+Attaching full build log.
+
+I'm using gcc 11.1.0. My last complete build was based on commit 9bef7ea9
diff --git a/results/classifier/118/hypervisor/858 b/results/classifier/118/hypervisor/858
new file mode 100644
index 00000000..fa112c37
--- /dev/null
+++ b/results/classifier/118/hypervisor/858
@@ -0,0 +1,41 @@
+hypervisor: 0.963
+x86: 0.963
+device: 0.905
+debug: 0.877
+graphic: 0.854
+vnc: 0.705
+architecture: 0.656
+files: 0.649
+PID: 0.646
+virtual: 0.613
+semantic: 0.528
+permissions: 0.507
+network: 0.479
+socket: 0.427
+ppc: 0.426
+VMM: 0.424
+register: 0.372
+performance: 0.368
+boot: 0.360
+arm: 0.294
+kernel: 0.261
+mistranslation: 0.243
+i386: 0.238
+risc-v: 0.227
+TCG: 0.221
+user-level: 0.220
+peripherals: 0.207
+KVM: 0.074
+assembly: 0.032
+
+qemu-system-x86_64: WHPX: Unexpected VP exit code 4
+Description of problem:
+Qemu closes and  prints following message:
+
+WHPX: setting APIC emulation mode in the hypervisor
+Windows Hypervisor Platform accelerator is operational
+whpx: injection failed, MSI (0, 0) delivery: 0, dest_mode: 0, trigger mode: 0, vector: 0, lost (c0350005)
+qemu-system-x86_64: WHPX: Unexpected VP exit code 4
+Steps to reproduce:
+1. build OVMF firmware from edk2
+2. run cmd : qemu-system-x86_64 -accel whpx --bios D:\Projects\FW\uefi\edk2\Build\OvmfX64\DEBUG_VS2019\FV\OVMF.fd
diff --git a/results/classifier/118/hypervisor/941 b/results/classifier/118/hypervisor/941
new file mode 100644
index 00000000..73a40f84
--- /dev/null
+++ b/results/classifier/118/hypervisor/941
@@ -0,0 +1,71 @@
+hypervisor: 0.956
+risc-v: 0.947
+virtual: 0.934
+device: 0.917
+vnc: 0.861
+performance: 0.815
+ppc: 0.803
+PID: 0.760
+files: 0.751
+kernel: 0.747
+architecture: 0.746
+VMM: 0.745
+register: 0.738
+network: 0.724
+graphic: 0.711
+socket: 0.666
+boot: 0.615
+debug: 0.588
+i386: 0.574
+assembly: 0.573
+arm: 0.555
+peripherals: 0.555
+x86: 0.528
+KVM: 0.527
+semantic: 0.518
+permissions: 0.516
+user-level: 0.487
+TCG: 0.455
+mistranslation: 0.273
+
+qemu-img cannot repair a qcow2 in an LV because size is mis-detected when qcow2 is on an LV
+Description of problem:
+This is RHEV with Tb's of VMs which need to be repaired due to a datacenter-wide (the real datacenter) power outage.
+
+Each of these VMs are on individual LVs but qemu-img check fails to perform repairs:
+
+
+```
+ERROR cluster 24481205 refcount=0 reference=1
+ERROR cluster 24481206 refcount=0 reference=1
+Rebuilding refcount structure
+ERROR writing refblock: No space left on device <============
+qemu-img: Check failed: No space left on device
+```
+
+Running qemu-img check or info on the LV (/dev/dm-*) works well but repairs cannot be completed:
+
+```
+# qemu-img info /dev/cdd4e215-8c6b-4877-b2be-fdba383e7eb0/fb32333b-2334-4e10-8c42-02bc97e826cc
+image: /dev/cdd4e215-8c6b-4877-b2be-fdba383e7eb0/fb32333b-2334-4e10-8c42-02bc97e826cc
+file format: qcow2
+virtual size: 1.5 TiB (1649267441664 bytes)
+disk size: 0 B <================================
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    compression type: zlib
+    lazy refcounts: true
+    refcount bits: 16
+    corrupt: false
+    extended l2: false
+```
+Steps to reproduce:
+1. Have a damaged VM with its qcow2 in an LV
+2. run 'qemu-img check <device>' verify that it properly detects the blocks which need fixing.
+3. run 'qemu-img check -r all <device>', it exits with 'no space left on device´ after a few seconds.
+Additional information:
+https://bugzilla.redhat.com/show_bug.cgi?id=1519071
+
+
+Here is one example:
author	Christian Krinitsin <mail@krinitsin.com>	2025-06-16 16:59:00 +0000
committer	Christian Krinitsin <mail@krinitsin.com>	2025-06-16 16:59:33 +0000
commit	9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch)
tree	b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/hypervisor
parent	b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download	emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip