From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Thu, 3 Jul 2025 19:39:53 +0200
Subject: restructure results

---
 results/classifier/118/user-level/1013    |  61 ----
 results/classifier/118/user-level/122     |  61 ----
 results/classifier/118/user-level/1259499 | 132 --------
 results/classifier/118/user-level/127     |  61 ----
 results/classifier/118/user-level/1352465 |  70 -----
 results/classifier/118/user-level/1361912 | 127 --------
 results/classifier/118/user-level/1652373 |  75 -----
 results/classifier/118/user-level/1682    |  63 ----
 results/classifier/118/user-level/1704638 | 143 ---------
 results/classifier/118/user-level/1785734 | 176 -----------
 results/classifier/118/user-level/1803160 | 236 --------------
 results/classifier/118/user-level/1821515 | 148 ---------
 results/classifier/118/user-level/1830415 |  79 -----
 results/classifier/118/user-level/1831750 | 139 ---------
 results/classifier/118/user-level/1843133 | 194 ------------
 results/classifier/118/user-level/1863025 | 493 ------------------------------
 results/classifier/118/user-level/1894361 |  81 -----
 results/classifier/118/user-level/1903833 |  86 ------
 results/classifier/118/user-level/1912    |  61 ----
 results/classifier/118/user-level/196     |  61 ----
 results/classifier/118/user-level/1964    |  67 ----
 results/classifier/118/user-level/2170    | 104 -------
 results/classifier/118/user-level/241     |  61 ----
 results/classifier/118/user-level/276     |  61 ----
 results/classifier/118/user-level/2854    |  84 -----
 results/classifier/118/user-level/326     |  61 ----
 results/classifier/118/user-level/570     |  61 ----
 results/classifier/118/user-level/697     |  61 ----
 results/classifier/118/user-level/817     |  61 ----
 results/classifier/118/user-level/872     |  61 ----
 results/classifier/118/user-level/885     |  61 ----
 31 files changed, 3290 deletions(-)
 delete mode 100644 results/classifier/118/user-level/1013
 delete mode 100644 results/classifier/118/user-level/122
 delete mode 100644 results/classifier/118/user-level/1259499
 delete mode 100644 results/classifier/118/user-level/127
 delete mode 100644 results/classifier/118/user-level/1352465
 delete mode 100644 results/classifier/118/user-level/1361912
 delete mode 100644 results/classifier/118/user-level/1652373
 delete mode 100644 results/classifier/118/user-level/1682
 delete mode 100644 results/classifier/118/user-level/1704638
 delete mode 100644 results/classifier/118/user-level/1785734
 delete mode 100644 results/classifier/118/user-level/1803160
 delete mode 100644 results/classifier/118/user-level/1821515
 delete mode 100644 results/classifier/118/user-level/1830415
 delete mode 100644 results/classifier/118/user-level/1831750
 delete mode 100644 results/classifier/118/user-level/1843133
 delete mode 100644 results/classifier/118/user-level/1863025
 delete mode 100644 results/classifier/118/user-level/1894361
 delete mode 100644 results/classifier/118/user-level/1903833
 delete mode 100644 results/classifier/118/user-level/1912
 delete mode 100644 results/classifier/118/user-level/196
 delete mode 100644 results/classifier/118/user-level/1964
 delete mode 100644 results/classifier/118/user-level/2170
 delete mode 100644 results/classifier/118/user-level/241
 delete mode 100644 results/classifier/118/user-level/276
 delete mode 100644 results/classifier/118/user-level/2854
 delete mode 100644 results/classifier/118/user-level/326
 delete mode 100644 results/classifier/118/user-level/570
 delete mode 100644 results/classifier/118/user-level/697
 delete mode 100644 results/classifier/118/user-level/817
 delete mode 100644 results/classifier/118/user-level/872
 delete mode 100644 results/classifier/118/user-level/885

(limited to 'results/classifier/118/user-level')

diff --git a/results/classifier/118/user-level/1013 b/results/classifier/118/user-level/1013
deleted file mode 100644
index fdb093e7..00000000
--- a/results/classifier/118/user-level/1013
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.850
-device: 0.834
-network: 0.624
-socket: 0.466
-graphic: 0.456
-boot: 0.394
-arm: 0.390
-permissions: 0.388
-risc-v: 0.329
-PID: 0.312
-vnc: 0.303
-hypervisor: 0.263
-performance: 0.257
-ppc: 0.250
-i386: 0.238
-register: 0.232
-architecture: 0.231
-semantic: 0.216
-debug: 0.208
-x86: 0.196
-TCG: 0.150
-VMM: 0.133
-virtual: 0.094
-files: 0.092
-assembly: 0.077
-kernel: 0.074
-peripherals: 0.071
-mistranslation: 0.054
-KVM: 0.004
---------------------
-debug: 0.980
-user-level: 0.905
-virtual: 0.590
-hypervisor: 0.374
-x86: 0.311
-TCG: 0.033
-files: 0.026
-boot: 0.020
-semantic: 0.010
-i386: 0.008
-network: 0.007
-assembly: 0.006
-ppc: 0.006
-performance: 0.006
-register: 0.006
-arm: 0.005
-risc-v: 0.004
-device: 0.003
-graphic: 0.003
-VMM: 0.003
-kernel: 0.003
-socket: 0.002
-vnc: 0.002
-architecture: 0.001
-permissions: 0.001
-PID: 0.001
-peripherals: 0.000
-KVM: 0.000
-mistranslation: 0.000
-
-[Bug] user input is not sanitized in QEMU_Elf_init and can lead to buffer overflow
diff --git a/results/classifier/118/user-level/122 b/results/classifier/118/user-level/122
deleted file mode 100644
index a2051177..00000000
--- a/results/classifier/118/user-level/122
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.939
-permissions: 0.860
-device: 0.628
-architecture: 0.477
-performance: 0.450
-mistranslation: 0.433
-network: 0.353
-virtual: 0.327
-semantic: 0.324
-kernel: 0.305
-ppc: 0.248
-boot: 0.211
-graphic: 0.206
-peripherals: 0.201
-arm: 0.155
-i386: 0.140
-TCG: 0.117
-register: 0.102
-vnc: 0.095
-files: 0.088
-risc-v: 0.087
-x86: 0.085
-debug: 0.082
-assembly: 0.061
-socket: 0.050
-VMM: 0.046
-KVM: 0.045
-PID: 0.031
-hypervisor: 0.026
---------------------
-permissions: 0.985
-user-level: 0.961
-performance: 0.827
-kernel: 0.756
-x86: 0.081
-virtual: 0.053
-debug: 0.041
-semantic: 0.029
-files: 0.023
-boot: 0.014
-TCG: 0.006
-device: 0.006
-hypervisor: 0.006
-i386: 0.005
-VMM: 0.004
-risc-v: 0.004
-KVM: 0.004
-ppc: 0.003
-assembly: 0.003
-PID: 0.002
-network: 0.002
-graphic: 0.002
-peripherals: 0.001
-register: 0.001
-socket: 0.001
-vnc: 0.001
-architecture: 0.001
-arm: 0.001
-mistranslation: 0.000
-
-linux-user does not check PROT_EXEC
diff --git a/results/classifier/118/user-level/1259499 b/results/classifier/118/user-level/1259499
deleted file mode 100644
index 1786866c..00000000
--- a/results/classifier/118/user-level/1259499
+++ /dev/null
@@ -1,132 +0,0 @@
-user-level: 0.861
-KVM: 0.811
-permissions: 0.804
-peripherals: 0.786
-files: 0.775
-mistranslation: 0.775
-hypervisor: 0.765
-ppc: 0.753
-x86: 0.753
-register: 0.752
-VMM: 0.747
-network: 0.740
-virtual: 0.740
-device: 0.733
-arm: 0.733
-vnc: 0.720
-boot: 0.719
-risc-v: 0.719
-graphic: 0.712
-assembly: 0.709
-socket: 0.705
-PID: 0.690
-performance: 0.689
-kernel: 0.688
-TCG: 0.684
-debug: 0.680
-architecture: 0.675
-semantic: 0.636
-i386: 0.573
---------------------
-x86: 0.977
-virtual: 0.963
-hypervisor: 0.941
-user-level: 0.864
-socket: 0.419
-KVM: 0.304
-boot: 0.109
-debug: 0.049
-PID: 0.040
-TCG: 0.030
-files: 0.027
-kernel: 0.021
-VMM: 0.020
-device: 0.015
-register: 0.014
-network: 0.005
-semantic: 0.005
-assembly: 0.003
-vnc: 0.003
-risc-v: 0.002
-architecture: 0.002
-performance: 0.002
-graphic: 0.002
-peripherals: 0.002
-ppc: 0.001
-permissions: 0.001
-i386: 0.001
-mistranslation: 0.000
-arm: 0.000
-
-QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system-x86_64
-
-I have upgraded to QEmu 1.7.0 (Debian 1.7.0+dfsg-2) but now when I try to restore a live snapshot made in QEmu 1.6.0 (Debian 1.6.0+dfsg-1) I see that the VM boots from scratch instead of starting directly in the snapshot's running state.
-
-Furthermore if the VM is already running and I try to revert to the snapshot again I get the following message:
-
-$ virsh --connect qemu:///system snapshot-revert fgtbbuild wtb; echo $?
-error: operation failed: Error -22 while loading VM state
-1
-
-I have test VMs with live snapshots corresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu bug it looks like I'll have to do it again.
-
-This all sounds very much like bug 1123975 where QEmu 1.3 broke compatibility with previous versions live snapshots :-(
-
-Here is the command being run by libvirt:
-
-/usr/bin/qemu-system-x86_64 -name fgtbbuild -S -machine pc-1.1,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid f510955c-17de-9907-1e33-dfe1ef7a08b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbbuild.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbbuild.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0a:3c:e8,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -loadvm wtb
-
-ipxe-qemu 1.0.0+git-20120202.f6840ba-3
-qemu 1.7.0+dfsg-2
-qemu-keymaps 1.7.0+dfsg-2
-qemu-slof 20130430+dfsg-1
-qemu-system 1.7.0+dfsg-2
-qemu-system-arm 1.7.0+dfsg-2
-qemu-system-common 1.7.0+dfsg-2
-qemu-system-mips 1.7.0+dfsg-2
-qemu-system-misc 1.7.0+dfsg-2
-qemu-system-ppc 1.7.0+dfsg-2
-qemu-system-sparc 1.7.0+dfsg-2
-qemu-system-x86 1.7.0+dfsg-2
-qemu-user 1.7.0+dfsg-2
-qemu-utils 1.7.0+dfsg-2
-libvirt-bin 1.1.4-2
-libvirt0 1.1.4-2
-libvirtodbc0 6.1.6+dfsg-4
-
-Hi Francois,
-  I've managed to reproduce this, in my log file (/var/log/libvirt/qemu/machinename.log) I see:
-
-Unknown ramblock "0000:02.0/qxl.vram", cannot accept migration
-qemu: warning: error while loading state for instance 0x0 of device 'ram'
-qemu-system-x86_64: Error -22 while loading VM state
-
-do you also see that unknown ramblock warning?
-
-(I'm running on F20 using 1.6.0 and 1.7.0 qemu's built from source running minimal F20 guests)
-
-Dave
-
-Hi Francois,
-  I've done some more digging.
-It looks like the problem you've hit is related to the same one that's fixed by:
-
-http://lists.gnu.org/archive/html/qemu-devel/2013-11/msg00513.html
-
-however that only fixes older restores ; there is a work around which is to pass to QEMU:
-
--global i440FX-pcihost.short_root_bus=1
-
-on loading the snapshot; which can be done by editing the snapshot xml files - but is obviously a bit
-messy.
-
-Thanks for digging into this.
-I am indeed getting the same ramblock error. So it's good that there appears to be a fix for it.
-Also if I understand it correctly this particular issue only affects the 1.6.0 snapshots so given that most of my snapshots are still on 1.3.x a direct upgrade to 1.7+ will hopefully let me avoid the issue.
-
-Yes, my understanding of the bug is that 1.7+ should load your 1.3.x images and then snapshots taken on 1.7.x should be OK into the future.
-
-I don't think there's currently a way of fixing those 1.6.0 snapshots; that workaround will let you load them in 1.7, but I think if you were then to take a snapshot on 1.7 with that flag, the snapshot would have the same problem.
-
-Setting status to "Won't fix" since there is no good solution to this problem according to comment #4.
-
diff --git a/results/classifier/118/user-level/127 b/results/classifier/118/user-level/127
deleted file mode 100644
index e4092c8b..00000000
--- a/results/classifier/118/user-level/127
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.967
-kernel: 0.648
-network: 0.642
-device: 0.595
-debug: 0.577
-mistranslation: 0.491
-boot: 0.469
-performance: 0.451
-semantic: 0.357
-peripherals: 0.304
-graphic: 0.299
-ppc: 0.249
-architecture: 0.197
-register: 0.165
-permissions: 0.110
-virtual: 0.104
-TCG: 0.084
-arm: 0.078
-files: 0.052
-VMM: 0.052
-socket: 0.047
-PID: 0.032
-i386: 0.023
-vnc: 0.023
-KVM: 0.014
-assembly: 0.013
-risc-v: 0.012
-x86: 0.006
-hypervisor: 0.002
---------------------
-user-level: 0.899
-network: 0.848
-kernel: 0.126
-debug: 0.062
-semantic: 0.042
-files: 0.035
-ppc: 0.032
-virtual: 0.029
-x86: 0.028
-register: 0.018
-device: 0.011
-socket: 0.010
-KVM: 0.009
-TCG: 0.009
-i386: 0.006
-performance: 0.005
-VMM: 0.004
-assembly: 0.004
-boot: 0.003
-architecture: 0.003
-hypervisor: 0.002
-risc-v: 0.002
-peripherals: 0.002
-graphic: 0.002
-arm: 0.002
-vnc: 0.001
-permissions: 0.001
-mistranslation: 0.000
-PID: 0.000
-
-linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8")
diff --git a/results/classifier/118/user-level/1352465 b/results/classifier/118/user-level/1352465
deleted file mode 100644
index 94a9e256..00000000
--- a/results/classifier/118/user-level/1352465
+++ /dev/null
@@ -1,70 +0,0 @@
-user-level: 0.920
-mistranslation: 0.893
-semantic: 0.856
-device: 0.846
-graphic: 0.826
-peripherals: 0.815
-performance: 0.798
-architecture: 0.735
-files: 0.721
-network: 0.690
-vnc: 0.683
-permissions: 0.674
-PID: 0.644
-register: 0.642
-kernel: 0.624
-risc-v: 0.623
-debug: 0.604
-VMM: 0.596
-ppc: 0.582
-virtual: 0.553
-socket: 0.549
-TCG: 0.533
-boot: 0.525
-arm: 0.514
-hypervisor: 0.471
-assembly: 0.451
-x86: 0.376
-i386: 0.365
-KVM: 0.221
---------------------
-user-level: 0.942
-virtual: 0.545
-x86: 0.212
-hypervisor: 0.178
-TCG: 0.118
-network: 0.085
-files: 0.056
-socket: 0.051
-device: 0.031
-kernel: 0.025
-VMM: 0.020
-i386: 0.014
-debug: 0.013
-risc-v: 0.007
-PID: 0.007
-peripherals: 0.006
-semantic: 0.005
-architecture: 0.005
-register: 0.004
-ppc: 0.004
-assembly: 0.003
-boot: 0.003
-vnc: 0.003
-performance: 0.002
-KVM: 0.002
-permissions: 0.002
-arm: 0.001
-graphic: 0.001
-mistranslation: 0.000
-
-Can't install virtio block drivers during Windows setup
-
-Hi!
-Apparently there's no way to install the virtio block drivers during Windows setup, as they're simply not recognized by the installer when it looks for them on the CD drive.
-The only way to setup virtio block drivers is to first install Windows on a IDE drive, then add a dummy virtio disk, then load the drivers and swap the two disks.
-I'm using virtio-win-0.1-81.iso. I can confirm the issue with Windows Server 2012 R2 and Windows 7 Professional, 64 bit.
-Thanks!
-
-Looks like nobody replied here within the last three years ... closing this now, since this is not directly a QEMU problem. You should likely report it to the virtio-win driver folks instead if the problem still persists.
-
diff --git a/results/classifier/118/user-level/1361912 b/results/classifier/118/user-level/1361912
deleted file mode 100644
index bdcd1723..00000000
--- a/results/classifier/118/user-level/1361912
+++ /dev/null
@@ -1,127 +0,0 @@
-user-level: 0.931
-device: 0.750
-assembly: 0.717
-register: 0.700
-ppc: 0.672
-files: 0.664
-permissions: 0.566
-kernel: 0.559
-performance: 0.557
-PID: 0.543
-socket: 0.538
-architecture: 0.525
-network: 0.523
-vnc: 0.465
-risc-v: 0.463
-peripherals: 0.454
-debug: 0.399
-boot: 0.387
-x86: 0.359
-arm: 0.349
-mistranslation: 0.330
-graphic: 0.328
-TCG: 0.323
-hypervisor: 0.289
-semantic: 0.286
-VMM: 0.262
-i386: 0.232
-virtual: 0.120
-KVM: 0.087
---------------------
-user-level: 0.997
-performance: 0.288
-virtual: 0.089
-TCG: 0.070
-files: 0.046
-debug: 0.028
-register: 0.017
-hypervisor: 0.014
-network: 0.013
-x86: 0.012
-PID: 0.012
-semantic: 0.006
-ppc: 0.006
-boot: 0.005
-kernel: 0.004
-device: 0.003
-architecture: 0.003
-peripherals: 0.003
-graphic: 0.002
-socket: 0.002
-assembly: 0.001
-permissions: 0.001
-vnc: 0.001
-i386: 0.001
-mistranslation: 0.001
-arm: 0.001
-risc-v: 0.001
-VMM: 0.001
-KVM: 0.000
-
-qemu-mips64 Segmentation fault
-
-When I ran qemu-mips64 for any mips 64 executable , I got this error:
-
-$ ./qemu-mips64  ../lang
-qemu: uncaught target signal 11 (Segmentation fault) - core dumped
-Segmentation fault (core dumped)
-
-Is this a known issue?
-
-Could you please provide backtrace and give more details to reproduce the issue?
-
-This is a error in user mode, I think it should be very easy to reproduce.
-
-On Thu, Sep 11, 2014 at 4:55 AM, Leon Alrae <email address hidden> wrote:
-
-> Could you please provide backtrace and give more details to reproduce
-> the issue?
->
-> --
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1361912
->
-> Title:
->   qemu-mips64 Segmentation fault
->
-> Status in QEMU:
->   New
->
-> Bug description:
->   When I ran qemu-mips64 for any mips 64 executable , I got this error:
->
->   $ ./qemu-mips64  ../lang
->   qemu: uncaught target signal 11 (Segmentation fault) - core dumped
->   Segmentation fault (core dumped)
->
->   Is this a known issue?
->
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1361912/+subscriptions
->
-
-
-I forgot to add that qemu-mips64 works for me, that's why I asked for the details to reproduce the issue (i.e. what is "lang", what tools you used to build it, command line etc.)
-
-I can see the problem with any simple program:
-1. cat t.c
-#include <stdio.h>
-int main()
-{
-  printf("Hello QEMU.\n");
-}
-
-2. mips64-gcc -static t.c -o t
-3. qemu-mips64 t
-qemu: uncaught target signal 11 (Segmentation fault) - core dumped
-Segmentation fault (core dumped)
-
-I built QEMU on Ubuntu 12.04 with the system GCC compiler, and the commands are:
-./configure --enable-linux-user
-make
-
-
-I've just checked with current head-of-git QEMU and we can execute the attached mips executable OK, so we've clearly fixed this bug at some point in the last three years. Closing as fix-committed, since the fix will definitely be in 2.11, though it's quite likely that 2.10 would also work.
-
-
diff --git a/results/classifier/118/user-level/1652373 b/results/classifier/118/user-level/1652373
deleted file mode 100644
index bef7e1ce..00000000
--- a/results/classifier/118/user-level/1652373
+++ /dev/null
@@ -1,75 +0,0 @@
-user-level: 0.905
-graphic: 0.772
-performance: 0.760
-device: 0.707
-semantic: 0.701
-mistranslation: 0.671
-register: 0.607
-architecture: 0.582
-i386: 0.546
-vnc: 0.543
-permissions: 0.540
-files: 0.534
-socket: 0.516
-risc-v: 0.496
-network: 0.496
-VMM: 0.474
-ppc: 0.464
-PID: 0.433
-arm: 0.423
-peripherals: 0.396
-boot: 0.390
-TCG: 0.390
-kernel: 0.368
-x86: 0.368
-debug: 0.359
-assembly: 0.306
-virtual: 0.295
-KVM: 0.252
-hypervisor: 0.201
---------------------
-user-level: 0.993
-performance: 0.641
-x86: 0.249
-TCG: 0.153
-debug: 0.094
-semantic: 0.035
-files: 0.020
-virtual: 0.019
-PID: 0.017
-device: 0.010
-register: 0.009
-i386: 0.008
-architecture: 0.007
-arm: 0.005
-ppc: 0.005
-assembly: 0.005
-network: 0.003
-kernel: 0.003
-risc-v: 0.002
-hypervisor: 0.002
-boot: 0.002
-socket: 0.002
-permissions: 0.002
-peripherals: 0.002
-vnc: 0.002
-graphic: 0.001
-mistranslation: 0.001
-VMM: 0.000
-KVM: 0.000
-
-User-mode QEMU is not deterministic
-
-QEMU in user-mode (linux-user or bsd-user) has no way to get the equivalent of the "-icount" argument found in softmmu mode.
-
-It is true that some system calls in user-mode can prevent deterministic execution, but it would be very simple to patch time-related syscalls to return a number based on icount when in deterministic mode.
-
-Putting both changes together (icount + time-related syscalls) would cover the needs for deterministic execution of most benchmarks (i.e., those not interacting with the network or other programs in the system).
-
-The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to
-"Incomplete" now.
-If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/user-level/1682 b/results/classifier/118/user-level/1682
deleted file mode 100644
index b8d1bbfa..00000000
--- a/results/classifier/118/user-level/1682
+++ /dev/null
@@ -1,63 +0,0 @@
-user-level: 0.924
-device: 0.910
-arm: 0.678
-architecture: 0.566
-register: 0.456
-performance: 0.446
-network: 0.405
-hypervisor: 0.382
-boot: 0.363
-mistranslation: 0.322
-permissions: 0.297
-graphic: 0.280
-semantic: 0.268
-files: 0.223
-peripherals: 0.165
-socket: 0.133
-ppc: 0.133
-debug: 0.118
-VMM: 0.093
-vnc: 0.088
-risc-v: 0.080
-assembly: 0.076
-virtual: 0.073
-PID: 0.050
-TCG: 0.045
-kernel: 0.025
-i386: 0.024
-x86: 0.013
-KVM: 0.009
---------------------
-virtual: 0.971
-user-level: 0.941
-hypervisor: 0.132
-semantic: 0.042
-files: 0.025
-device: 0.025
-x86: 0.017
-permissions: 0.014
-boot: 0.007
-assembly: 0.004
-debug: 0.004
-network: 0.003
-arm: 0.003
-peripherals: 0.002
-register: 0.002
-PID: 0.001
-TCG: 0.001
-kernel: 0.001
-architecture: 0.001
-graphic: 0.001
-socket: 0.001
-risc-v: 0.001
-ppc: 0.001
-VMM: 0.001
-vnc: 0.000
-performance: 0.000
-i386: 0.000
-KVM: 0.000
-mistranslation: 0.000
-
-QEMU-USER macOS support
-Additional information:
-
diff --git a/results/classifier/118/user-level/1704638 b/results/classifier/118/user-level/1704638
deleted file mode 100644
index aace514e..00000000
--- a/results/classifier/118/user-level/1704638
+++ /dev/null
@@ -1,143 +0,0 @@
-user-level: 0.840
-mistranslation: 0.794
-register: 0.778
-graphic: 0.762
-performance: 0.759
-architecture: 0.755
-permissions: 0.750
-semantic: 0.749
-device: 0.748
-risc-v: 0.745
-virtual: 0.745
-debug: 0.740
-arm: 0.738
-assembly: 0.737
-KVM: 0.727
-network: 0.725
-files: 0.712
-socket: 0.712
-PID: 0.710
-kernel: 0.709
-peripherals: 0.708
-TCG: 0.700
-boot: 0.695
-hypervisor: 0.692
-VMM: 0.675
-x86: 0.656
-vnc: 0.652
-i386: 0.647
-ppc: 0.634
---------------------
-debug: 0.959
-user-level: 0.942
-x86: 0.818
-PID: 0.113
-virtual: 0.051
-semantic: 0.048
-files: 0.034
-TCG: 0.021
-assembly: 0.019
-register: 0.019
-performance: 0.011
-VMM: 0.004
-hypervisor: 0.004
-architecture: 0.004
-permissions: 0.003
-device: 0.003
-network: 0.002
-graphic: 0.002
-i386: 0.002
-socket: 0.002
-kernel: 0.001
-risc-v: 0.001
-vnc: 0.001
-peripherals: 0.001
-boot: 0.001
-KVM: 0.001
-mistranslation: 0.001
-ppc: 0.001
-arm: 0.000
-
-weak symbol access makes qemu in user mode hang for mips, mips64
-
-A program that is statically linked and invokes a weak pointer should crash (because the weak pointer evaluates to NULL).
-
-With qemu in user mode, for mips and mips64, it hangs. The process needs to be killed with "kill -9".
-
-How to reproduce for mips:
-- Compile the program: mips-linux-gnu-gcc-5 -O -Wall -static -o testpthsigmask-mips testpthsigmask.c -pthread
-- Set environment variables for running qemu-mips.
-- ~/inst-qemu/2.9.0/bin/qemu-mips testpthsigmask-mips
-
-How to reproduce for mips64:
-- Compile the program: mips64-linux-gnuabi64-gcc-5 -O -Wall -static -o testpthsigmask-mips64 testpthsigmask.c -lpthread
-- Set environment variables for running qemu-mips64.
-- ~/inst-qemu/2.9.0/bin/qemu-mips64 testpthsigmask-mips64
-
-When I attach gdb to the process, I see that it is hanging inside 'gen_intermediate_code':
-
-$ gdb /home/bruno/inst-qemu/2.9.0/bin/qemu-mips 9726
-...
-Reading symbols from /home/bruno/inst-qemu/2.9.0/bin/qemu-mips...done.
-Attaching to program: /home/bruno/inst-qemu/2.9.0/bin/qemu-mips, process 9726
-...
-(gdb) info threads
-  Id   Target Id         Frame 
-* 1    Thread 0x7f1e7e535740 (LWP 9726) "qemu-mips" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
-  2    Thread 0x7f1e7d0ad700 (LWP 9727) "qemu-mips" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
-(gdb) where
-#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
-#1  0x00007f1e7d6f1dbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) at ../nptl/pthread_mutex_lock.c:80
-#2  0x000055de1c527199 in qemu_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>)
-    at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:60
-#3  0x000055de1c435083 in tb_lock () at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:167
-#4  cpu_restore_state (cpu=cpu@entry=0x55de1e915cb0, retaddr=retaddr@entry=94412445741769) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:350
-#5  0x000055de1c4658d0 in handle_cpu_signal (old_set=0x7ffe5ffd8ea8, is_write=0, address=0, pc=94412445741767)
-    at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:124
-#6  cpu_mips_signal_handler (host_signum=host_signum@entry=11, pinfo=pinfo@entry=0x7ffe5ffd8eb0, puc=puc@entry=0x7ffe5ffd8d80)
-    at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:229
-#7  0x000055de1c4803be in host_signal_handler (host_signum=11, info=0x7ffe5ffd8eb0, puc=0x7ffe5ffd8d80)
-    at /media/develdata/devel/build/qemu-2.9.0/linux-user/signal.c:646
-#8  <signal handler called>
-#9  __bswap_32 (__bsx=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/byteswap.h:47
-#10 bswap32 (x=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:21
-#11 ldl_be_p (ptr=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:434
-#12 cpu_ldl_code (env=0x55de1e91df48, ptr=0) at /media/develdata/devel/build/qemu-2.9.0/include/exec/cpu_ldst_useronly_template.h:68
-#13 gen_intermediate_code (env=env@entry=0x55de1e91df48, tb=tb@entry=0x7f1e7b288e58)
-    at /media/develdata/devel/build/qemu-2.9.0/target/mips/translate.c:19962
-#14 0x000055de1c4352e6 in tb_gen_code (cpu=cpu@entry=0x55de1e915cb0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=162, cflags=<optimized out>, 
-    cflags@entry=0) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:1295
-#15 0x000055de1c436a7a in tb_find (tb_exit=0, last_tb=0x0, cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:365
-#16 cpu_exec (cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:673
-#17 0x000055de1c466278 in cpu_loop (env=0x55de1e91df48) at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:2236
-#18 0x000055de1c433103 in main (argc=<optimized out>, argv=0x7ffe5ffd9de8, envp=<optimized out>)
-    at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:4860
-(gdb) thread 2
-[Switching to thread 2 (Thread 0x7f1e7d0ad700 (LWP 9727))]
-#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
-38      ../sysdeps/unix/sysv/linux/x86_64/syscall.S: Datei oder Verzeichnis nicht gefunden.
-(gdb) where
-#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
-#1  0x000055de1c527605 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/futex.h:26
-#2  qemu_event_wait (ev=ev@entry=0x55de1e82c124 <rcu_call_ready_event>) at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:399
-#3  0x000055de1c52d41e in call_rcu_thread (opaque=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/util/rcu.c:249
-#4  0x00007f1e7d6ef6ba in start_thread (arg=0x7f1e7d0ad700) at pthread_create.c:333
-#5  0x00007f1e7d4253dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
-
-
-
-
-
-
-
-The behaviour in qemu-2.10 is the same as in qemu-2.9.
-
-This is fixed in qemu-2.11:
-$ ~/inst-qemu/2.11.0/bin/qemu-mips testpthsigmask-mips
-qemu: uncaught target signal 11 (Segmentation fault) - core dumped
-Segmentation fault (core dumped)
-$ ~/inst-qemu/2.11.0/bin/qemu-mips64 testpthsigmask-mips64
-qemu: uncaught target signal 11 (Segmentation fault) - core dumped
-Segmentation fault (core dumped)
-
-
diff --git a/results/classifier/118/user-level/1785734 b/results/classifier/118/user-level/1785734
deleted file mode 100644
index 25fce13b..00000000
--- a/results/classifier/118/user-level/1785734
+++ /dev/null
@@ -1,176 +0,0 @@
-user-level: 0.843
-TCG: 0.842
-peripherals: 0.804
-ppc: 0.795
-vnc: 0.771
-VMM: 0.769
-KVM: 0.765
-mistranslation: 0.764
-hypervisor: 0.760
-register: 0.734
-i386: 0.716
-x86: 0.712
-debug: 0.710
-risc-v: 0.704
-performance: 0.688
-device: 0.674
-graphic: 0.667
-arm: 0.652
-virtual: 0.640
-permissions: 0.632
-assembly: 0.629
-socket: 0.621
-architecture: 0.620
-PID: 0.616
-semantic: 0.612
-files: 0.611
-kernel: 0.599
-boot: 0.579
-network: 0.578
---------------------
-i386: 0.984
-TCG: 0.958
-x86: 0.947
-assembly: 0.864
-debug: 0.129
-kernel: 0.060
-hypervisor: 0.050
-performance: 0.048
-architecture: 0.044
-files: 0.038
-virtual: 0.028
-device: 0.021
-PID: 0.017
-register: 0.015
-semantic: 0.015
-boot: 0.012
-peripherals: 0.011
-VMM: 0.006
-ppc: 0.005
-permissions: 0.005
-graphic: 0.004
-network: 0.004
-user-level: 0.004
-risc-v: 0.003
-socket: 0.003
-arm: 0.002
-KVM: 0.002
-vnc: 0.001
-mistranslation: 0.001
-
-movdqu partial write at page boundary
-
-In TCG mode, when a 16-byte write instruction (such as movdqu) is executed at a page boundary and causes a page fault, a partial write is executed in the first page. See the attached code for an example.
-
-Tested on the qemu-3.0.0-rc1 release.
-
-
-% gcc -m32 qemu-bug2.c && ./a.out && echo && qemu-i386 ./a.out
-*(0x70000ff8+ 0) = aa
-*(0x70000ff8+ 1) = aa
-*(0x70000ff8+ 2) = aa
-*(0x70000ff8+ 3) = aa
-*(0x70000ff8+ 4) = aa
-*(0x70000ff8+ 5) = aa
-*(0x70000ff8+ 6) = aa
-*(0x70000ff8+ 7) = aa
-*(0x70000ff8+ 8) = 55
-*(0x70000ff8+ 9) = 55
-*(0x70000ff8+10) = 55
-*(0x70000ff8+11) = 55
-*(0x70000ff8+12) = 55
-*(0x70000ff8+13) = 55
-*(0x70000ff8+14) = 55
-*(0x70000ff8+15) = 55
-page fault: addr=0x70001000 err=0x7
-*(0x70000ff8+ 0) = aa
-*(0x70000ff8+ 1) = aa
-*(0x70000ff8+ 2) = aa
-*(0x70000ff8+ 3) = aa
-*(0x70000ff8+ 4) = aa
-*(0x70000ff8+ 5) = aa
-*(0x70000ff8+ 6) = aa
-*(0x70000ff8+ 7) = aa
-*(0x70000ff8+ 8) = 55
-*(0x70000ff8+ 9) = 55
-*(0x70000ff8+10) = 55
-*(0x70000ff8+11) = 55
-*(0x70000ff8+12) = 55
-*(0x70000ff8+13) = 55
-*(0x70000ff8+14) = 55
-*(0x70000ff8+15) = 55
-
-*(0x70000ff8+ 0) = aa
-*(0x70000ff8+ 1) = aa
-*(0x70000ff8+ 2) = aa
-*(0x70000ff8+ 3) = aa
-*(0x70000ff8+ 4) = aa
-*(0x70000ff8+ 5) = aa
-*(0x70000ff8+ 6) = aa
-*(0x70000ff8+ 7) = aa
-*(0x70000ff8+ 8) = 55
-*(0x70000ff8+ 9) = 55
-*(0x70000ff8+10) = 55
-*(0x70000ff8+11) = 55
-*(0x70000ff8+12) = 55
-*(0x70000ff8+13) = 55
-*(0x70000ff8+14) = 55
-*(0x70000ff8+15) = 55
-page fault: addr=0x70001000 err=0x6
-*(0x70000ff8+ 0) = 77
-*(0x70000ff8+ 1) = 66
-*(0x70000ff8+ 2) = 55
-*(0x70000ff8+ 3) = 44
-*(0x70000ff8+ 4) = 33
-*(0x70000ff8+ 5) = 22
-*(0x70000ff8+ 6) = 11
-*(0x70000ff8+ 7) = 0
-*(0x70000ff8+ 8) = 55
-*(0x70000ff8+ 9) = 55
-*(0x70000ff8+10) = 55
-*(0x70000ff8+11) = 55
-*(0x70000ff8+12) = 55
-*(0x70000ff8+13) = 55
-*(0x70000ff8+14) = 55
-*(0x70000ff8+15) = 55
-
-
-
-This is a part of a class of related problems for qemu linux-user, in that any non-atomic store is not validated before initiating a partial write.
-
-For instance, qemu-x86_64, built for arm32, would show this same partial store problem for any 64-bit write crossing a page boundary because we are forced by the limits of the host to split the store into two 32-bit pieces.
-
-While we could probably fix this specific case fairly easily, because it is implemented with an external helper in the first place, we would need some new infrastructure to handle the more general problem.  Exactly what form that should take would need some thought and discussion.
-
-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/user-level/1803160 b/results/classifier/118/user-level/1803160
deleted file mode 100644
index fdfad0de..00000000
--- a/results/classifier/118/user-level/1803160
+++ /dev/null
@@ -1,236 +0,0 @@
-user-level: 0.802
-permissions: 0.790
-register: 0.771
-hypervisor: 0.760
-performance: 0.754
-ppc: 0.753
-graphic: 0.738
-device: 0.736
-KVM: 0.734
-files: 0.731
-network: 0.731
-semantic: 0.731
-PID: 0.728
-arm: 0.722
-peripherals: 0.721
-virtual: 0.720
-VMM: 0.719
-TCG: 0.719
-vnc: 0.708
-assembly: 0.706
-debug: 0.705
-architecture: 0.705
-socket: 0.693
-kernel: 0.674
-x86: 0.668
-i386: 0.660
-risc-v: 0.652
-boot: 0.600
-mistranslation: 0.581
---------------------
-TCG: 0.970
-i386: 0.955
-x86: 0.875
-debug: 0.872
-virtual: 0.428
-files: 0.166
-hypervisor: 0.072
-PID: 0.067
-register: 0.035
-kernel: 0.025
-semantic: 0.017
-performance: 0.015
-assembly: 0.008
-device: 0.008
-architecture: 0.007
-user-level: 0.007
-network: 0.004
-graphic: 0.003
-socket: 0.003
-boot: 0.002
-permissions: 0.002
-peripherals: 0.002
-ppc: 0.002
-VMM: 0.002
-risc-v: 0.001
-vnc: 0.001
-KVM: 0.001
-mistranslation: 0.001
-arm: 0.000
-
-qemu-3.1.0-rc0: tcg.c crash in temp_load
-
-QEMU version:
--------------
-
-qemu-3.1.0-rc0 compiled from sources (earlier versions also affected)
-
-Summary:
---------
-
-TCG crashes in i386 and x86_64 when it tries to execute some specific illegal instructions. When running full OS emulation, both the guest system and QEMU crash.
-
-The issue has been reproduced in two scenarios:
-
-Ubuntu x64 host running Debian x86 guest with the following command line: qemu-system-x86_64 -m 4G debian.qcow
-
-When the attached ELF file is executed inside the guest, QEMU crashes.
-
-It can also be reproduced from the command line:
-
-$ qemu-i386 tcg_crash.elf
-/home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:2863: tcg fatal error
-qemu: uncaught target signal 11 (Segmentation fault) - core dumped
-zsh: segmentation fault (core dumped)  ../qemu-3.1.0-rc0/build/i386-linux-user/qemu-i386 tcg_crash.elf
-
-GDB backtrace:
-
-(gdb) bt
-#0  0x0000000060206488 in raise ()
-#1  0x0000000060206b8a in abort ()
-#2  0x0000000060007016 in temp_load (s=s@entry=0x607a2780 <tcg_init_ctx>, ts=ts@entry=0x607a3178 <tcg_init_ctx+2552>, desired_regs=<optimized out>, allocated_regs=allocated_regs@entry=16400)
-    at /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:2863
-#3  0x000000006000a4d9 in tcg_reg_alloc_op (op=0x62808c20, s=<optimized out>) at /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:3070
-#4  tcg_gen_code (s=<optimized out>, tb=tb@entry=0x607ac040 <static_code_gen_buffer+4144>) at /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:3598
-#5  0x000000006003ef9a in tb_gen_code (cpu=cpu@entry=0x627e0010, pc=pc@entry=134512724, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=cflags@entry=0)
-    at /home/alberto/Documents/qemu-3.1.0-rc0/accel/tcg/translate-all.c:1752
-#6  0x000000006003d979 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0x0) at /home/alberto/Documents/qemu-3.1.0-rc0/accel/tcg/cpu-exec.c:404
-#7  cpu_exec (cpu=cpu@entry=0x627e0010) at /home/alberto/Documents/qemu-3.1.0-rc0/accel/tcg/cpu-exec.c:724
-#8  0x000000006006e1a0 in cpu_loop (env=env@entry=0x627e82c0) at /home/alberto/Documents/qemu-3.1.0-rc0/linux-user/i386/cpu_loop.c:93
-#9  0x00000000600037c5 in main (argc=2, argv=0x7fffffffdd28, envp=<optimized out>) at /home/alberto/Documents/qemu-3.1.0-rc0/linux-user/main.c:819
-(gdb)
-
-Testcase:
----------
-
-Find ELF file attached, and also in the following hexdump:
-
-$ hexdump -C tcg_crash.elf
-00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
-00000010  02 00 03 00 01 00 00 00  54 80 04 08 34 00 00 00  |........T...4...|
-00000020  00 00 00 00 00 00 00 00  34 00 20 00 01 00 00 00  |........4. .....|
-00000030  00 00 00 00 01 00 00 00  00 00 00 00 00 80 04 08  |................|
-00000040  00 80 04 08 64 00 00 00  64 00 00 00 05 00 00 00  |....d...d.......|
-00000050  00 10 00 00 d2 dc a8 45  31 ca f0 35 d9 4d 8f 18  |.......E1..5.M..|
-00000060  05 2e 6f 9f                                       |..o.|
-
-
-
-Can you please re-test on the current master, I think this was fixed by:
-
-commit e84fcd7f662a0d8198703f6f89416d7ac2c32767
-Author: Richard Henderson <email address hidden>
-Date:   Tue Nov 13 20:35:10 2018 +0100
-
-    target/i386: Generate #UD when applying LOCK to a register destination
-
-Testing on my box:
-
-12:14:20 [alex@idun:~/l/qemu.git] master + ./i386-linux-user/qemu-i386 ~/tcg_crash.elf
-qemu: uncaught target signal 4 (Illegal instruction) - core dumped
-fish: “./i386-linux-user/qemu-i386 ~/t…” terminated by signal SIGILL (Illegal instruction)
-
-
-I've tested this again and I haven't been able to reproduce it anymore on the current master, it looks fixed.
-
-Thanks! :)
-
-Hello again,
-
-After more testing I've been able to trigger this bug again using qemu from git master. Find attached a new ELF that will reproduce the problem:
-
-$ qemu-i386 tcg_crash1.elf
-/home/alberto/Documents/qemu/tcg/tcg.c:2863: tcg fatal error
-qemu: uncaught target signal 11 (Segmentation fault) - core dumped
-zsh: segmentation fault (core dumped)  ./qemu/build/i386-linux-user/qemu-i386 tcg_crash1.elf
-
-Invalid instructions:
-
-f0 invalid
-40 inc eax
-a7 cmpsd dword [esi], dword ptr es:[edi]
-48 dec eax
-
-GDB backtrace is the same as before.
-
-This second crash is of course a different bug.
-
-Hi Alberto,
-
-Can you open another ticket for your new bug?
-
-Thanks.
-
-On Fri, Dec 7, 2018 at 6:22 PM Richard Henderson <email address hidden> wrote:
->
-> This second crash is of course a different bug.
->
-> --
-> You received this bug notification because you are a member of qemu-
-> devel-ml, which is subscribed to QEMU.
-> https://bugs.launchpad.net/bugs/1803160
->
-> Title:
->   qemu-3.1.0-rc0: tcg.c crash in temp_load
->
-> Status in QEMU:
->   Fix Committed
->
-> Bug description:
->   QEMU version:
->   -------------
->
->   qemu-3.1.0-rc0 compiled from sources (earlier versions also affected)
->
->   Summary:
->   --------
->
->   TCG crashes in i386 and x86_64 when it tries to execute some specific
->   illegal instructions. When running full OS emulation, both the guest
->   system and QEMU crash.
->
->   The issue has been reproduced in two scenarios:
->
->   Ubuntu x64 host running Debian x86 guest with the following command
->   line: qemu-system-x86_64 -m 4G debian.qcow
->
->   When the attached ELF file is executed inside the guest, QEMU crashes.
->
->   It can also be reproduced from the command line:
->
->   $ qemu-i386 tcg_crash.elf
->   /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:2863: tcg fatal error
->   qemu: uncaught target signal 11 (Segmentation fault) - core dumped
->   zsh: segmentation fault (core dumped)  ../qemu-3.1.0-rc0/build/i386-linux-user/qemu-i386 tcg_crash.elf
->
->   GDB backtrace:
->
->   (gdb) bt
->   #0  0x0000000060206488 in raise ()
->   #1  0x0000000060206b8a in abort ()
->   #2  0x0000000060007016 in temp_load (s=s@entry=0x607a2780 <tcg_init_ctx>, ts=ts@entry=0x607a3178 <tcg_init_ctx+2552>, desired_regs=<optimized out>, allocated_regs=allocated_regs@entry=16400)
->       at /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:2863
->   #3  0x000000006000a4d9 in tcg_reg_alloc_op (op=0x62808c20, s=<optimized out>) at /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:3070
->   #4  tcg_gen_code (s=<optimized out>, tb=tb@entry=0x607ac040 <static_code_gen_buffer+4144>) at /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:3598
->   #5  0x000000006003ef9a in tb_gen_code (cpu=cpu@entry=0x627e0010, pc=pc@entry=134512724, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=cflags@entry=0)
->       at /home/alberto/Documents/qemu-3.1.0-rc0/accel/tcg/translate-all.c:1752
->   #6  0x000000006003d979 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0x0) at /home/alberto/Documents/qemu-3.1.0-rc0/accel/tcg/cpu-exec.c:404
->   #7  cpu_exec (cpu=cpu@entry=0x627e0010) at /home/alberto/Documents/qemu-3.1.0-rc0/accel/tcg/cpu-exec.c:724
->   #8  0x000000006006e1a0 in cpu_loop (env=env@entry=0x627e82c0) at /home/alberto/Documents/qemu-3.1.0-rc0/linux-user/i386/cpu_loop.c:93
->   #9  0x00000000600037c5 in main (argc=2, argv=0x7fffffffdd28, envp=<optimized out>) at /home/alberto/Documents/qemu-3.1.0-rc0/linux-user/main.c:819
->   (gdb)
->
->   Testcase:
->   ---------
->
->   Find ELF file attached.
->
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1803160/+subscriptions
->
-
-
-I've just opened #1807675 for the new bug.
-
-Thanks!
-
diff --git a/results/classifier/118/user-level/1821515 b/results/classifier/118/user-level/1821515
deleted file mode 100644
index f2dbc11d..00000000
--- a/results/classifier/118/user-level/1821515
+++ /dev/null
@@ -1,148 +0,0 @@
-user-level: 0.838
-permissions: 0.836
-graphic: 0.800
-virtual: 0.796
-semantic: 0.746
-debug: 0.716
-register: 0.709
-assembly: 0.693
-device: 0.642
-arm: 0.620
-PID: 0.616
-hypervisor: 0.607
-architecture: 0.587
-peripherals: 0.582
-TCG: 0.582
-mistranslation: 0.567
-performance: 0.566
-kernel: 0.538
-ppc: 0.535
-risc-v: 0.524
-files: 0.494
-x86: 0.452
-boot: 0.441
-VMM: 0.397
-network: 0.370
-socket: 0.369
-vnc: 0.364
-KVM: 0.357
-i386: 0.234
---------------------
-user-level: 0.976
-ppc: 0.816
-debug: 0.097
-files: 0.072
-TCG: 0.017
-hypervisor: 0.016
-virtual: 0.010
-PID: 0.007
-assembly: 0.007
-kernel: 0.005
-register: 0.005
-semantic: 0.004
-device: 0.004
-graphic: 0.003
-VMM: 0.002
-performance: 0.002
-architecture: 0.001
-network: 0.001
-peripherals: 0.001
-x86: 0.001
-boot: 0.001
-vnc: 0.001
-socket: 0.001
-mistranslation: 0.001
-permissions: 0.001
-risc-v: 0.000
-KVM: 0.000
-arm: 0.000
-i386: 0.000
-
-qemu-ppc (user) incorrectly converts float(nan)->double(non-nan)
-
-Noticed on qemu-3.1.0 on GHC test suite where float32 comparisons didn't work on NaNs.
-Here is the minimal reproducer:
-
-```c
-// cat a.c
-#include <stdio.h>
-#include <math.h>
-#include <stdint.h>
-
-int main() {
-    volatile float f1 = NAN;
-    volatile float f2 = NAN;
-    printf ("f1 (%e, %#x) >= f2 (%e, %#x): %s\n",
-        f1, *(volatile uint32_t*)&f1,
-        f2, *(volatile uint32_t*)&f2,
-        (f1 >= f2) ? "True"
-                   : "False");
-    volatile double d = f1;
-    printf ("d (%e, %#llx)\n",
-        d, *(volatile uint64_t*)&d);
-}
-```
-
-```
-# incorrect execution:
-$ powerpc-unknown-linux-gnu-gcc -O2 a.c -o a -static && qemu-ppc ./a 
-f1 (5.104236e+38, 0x7fc00000) >= f2 (5.104236e+38, 0x7fc00000): True
-d (5.104236e+38, 0x47f8000000000000)
-
-# correct execution
-$ scp a timberdoodle.ppc64.dev.gentoo.org:~/;  ssh timberdoodle.ppc64.dev.gentoo.org ./a
-f1 (nan, 0x7fc00000) >= f2 (nan, 0x7fc00000): False
-d (nan, 0x7ff8000000000000)
-```
-
-Note: qemu-ppc handled float32 extension as it was not a NaN (exp=111..1111) but a normalized number.
-
-
-
-The bug is in the same area as https://bugs.launchpad.net/qemu/+bug/1821444 but in another branch of 'uint64_t helper_todouble(uint32_t arg=0x1)'.
-
-We also hit this regression when testing CompCert for e5500 with qemu 3.1.0.
-
-The minimal example
-> #include <stdio.h>
-> #include <math.h>
->  
-> union C { float f; unsigned long l; };
-> int main (void) {
->     union C c;
->     c.f = NAN;
->     printf("Float: %f\n  Hex: 0x%x\n", c.f, c.l);
->     printf("The above float is %s NAN\n", c.f == NAN ? "==" : "!=");                                                      
->     return 0;
-> }
-
-does not exhibit the error with GCC 6.3.0, since that statically optimizes the c.f == NAN to always be false. But CompCert doesn't do this optimization and thus triggers the regression in the float compare.
-
-With qemu 3.0.0 the example outputs (whether built with compcert or gcc):
-> Float: nan
->   Hex: 0x7fc00000
-> The above float is != NAN
-
-The example works well with qemu 3.0.0 and we stumbled over this with qemu 3.1.0; both build from the released source tarballs. My native system is a x86_64 GNU/Linux (openSUSE Tumbleweed with Kernel 4.20.13-1-default).
-
-Output with qemu 3.1.0 and built with GCC:
-> $ ./qemu-ppc64abi32-3.1.0 bug25310.gcc.elf 
-> Float: 510423550381407695195061911147652317184.000000
->   Hex: 0x7fc00000
-> The above float is != NAN
-
-qemu 3.1.0 and example built with CompCert:
-> $ ./qemu-ppc64abi32-3.1.0 bug25310.ccomp.elf 
-> Float: 510423550381407695195061911147652317184.000000
->   Hex: 0x7fc00000
-> The above float is == NAN
-
-I attached example binaries (statically built):
-> $ ../../compcert_internal_ppc/bin/ccomp --version
-> The CompCert C verified compiler, Release: 18.10i, Build: 4503984, Tag: auto/2019/02/11/1924
-> $ ../../compcert_internal_ppc/bin/ccomp -target e5500-linux -g -static bug25310.c -o bug25310.ccomp.elf 
-> 
-> $ ../../compcert_internal_ppc/gcc/bin/powerpc-unknown-linux-gnu-gcc --version
-> powerpc-unknown-linux-gnu-gcc (crosstool-NG crosstool-ng-1.23.0) 6.3.0
-> $ ../../compcert_internal_ppc/gcc/bin/powerpc-unknown-linux-gnu-gcc bug25310.c -g -static -O0 -o bug25310.gcc.elf -mcpu=e5500
-
diff --git a/results/classifier/118/user-level/1830415 b/results/classifier/118/user-level/1830415
deleted file mode 100644
index c0f2d0f3..00000000
--- a/results/classifier/118/user-level/1830415
+++ /dev/null
@@ -1,79 +0,0 @@
-user-level: 0.910
-mistranslation: 0.671
-files: 0.646
-graphic: 0.569
-semantic: 0.512
-ppc: 0.508
-device: 0.505
-performance: 0.495
-TCG: 0.404
-kernel: 0.313
-architecture: 0.293
-network: 0.288
-x86: 0.260
-boot: 0.247
-i386: 0.232
-vnc: 0.215
-PID: 0.203
-socket: 0.195
-register: 0.177
-debug: 0.169
-risc-v: 0.152
-permissions: 0.133
-arm: 0.115
-peripherals: 0.100
-VMM: 0.093
-assembly: 0.078
-KVM: 0.071
-virtual: 0.027
-hypervisor: 0.019
---------------------
-user-level: 0.993
-files: 0.650
-x86: 0.170
-TCG: 0.070
-register: 0.067
-debug: 0.059
-assembly: 0.041
-virtual: 0.023
-i386: 0.016
-PID: 0.015
-kernel: 0.007
-performance: 0.006
-semantic: 0.005
-arm: 0.003
-hypervisor: 0.002
-network: 0.002
-device: 0.002
-VMM: 0.002
-boot: 0.002
-architecture: 0.001
-ppc: 0.001
-graphic: 0.001
-KVM: 0.001
-permissions: 0.001
-vnc: 0.001
-socket: 0.001
-peripherals: 0.001
-mistranslation: 0.000
-risc-v: 0.000
-
-linux-user elf loader issue
-
-all versions up to 4.0 (I didn't test others)
-file affected linux-user/elfload.c
-function load_elf_image
-
-if (phdr[i].p_type == PT_LOAD) {
-           
--            abi_ulong a = phdr[i].p_vaddr - phdr[i].p_offset; 
-+            abi_ulong a = phdr[i].p_vaddr ; // - phdr[i].p_offset; 
-            if (a < loaddr) {
-                loaddr = a;
-
-To the best of my understanding of the elf format p_offset is not a virtual offset. In fact, when I load statically compiled applications, the load fails because the libc before main is trying to access phdr in the executable image but that memory is not mapped -- this is caused by the wrong loaddr above.
-
-Have you got a test case? The check-tcg tests all pass and they are statically linked elfs.
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/user-level/1831750 b/results/classifier/118/user-level/1831750
deleted file mode 100644
index a58f0cae..00000000
--- a/results/classifier/118/user-level/1831750
+++ /dev/null
@@ -1,139 +0,0 @@
-user-level: 0.821
-mistranslation: 0.794
-risc-v: 0.789
-x86: 0.752
-peripherals: 0.742
-hypervisor: 0.733
-KVM: 0.727
-ppc: 0.696
-vnc: 0.693
-VMM: 0.678
-TCG: 0.651
-graphic: 0.646
-arm: 0.642
-virtual: 0.639
-i386: 0.623
-register: 0.613
-device: 0.611
-network: 0.605
-permissions: 0.597
-debug: 0.594
-performance: 0.579
-files: 0.559
-semantic: 0.556
-boot: 0.532
-architecture: 0.525
-socket: 0.515
-assembly: 0.500
-PID: 0.498
-kernel: 0.493
---------------------
-virtual: 0.967
-user-level: 0.859
-debug: 0.831
-performance: 0.709
-hypervisor: 0.339
-x86: 0.183
-kernel: 0.078
-VMM: 0.066
-TCG: 0.066
-files: 0.051
-PID: 0.030
-KVM: 0.029
-device: 0.029
-risc-v: 0.023
-ppc: 0.022
-register: 0.020
-semantic: 0.014
-assembly: 0.012
-architecture: 0.009
-socket: 0.008
-i386: 0.008
-vnc: 0.005
-boot: 0.003
-peripherals: 0.003
-network: 0.002
-arm: 0.002
-graphic: 0.001
-permissions: 0.001
-mistranslation: 0.000
-
-virtual machine cpu soft lockup when qemu attach disk
-
-Hi,  I found a problem that virtual machine cpu soft lockup when I attach a disk to the vm in the case that
-
-backend storage network has a large delay or IO pressure is too large.
-
-1) The disk xml which I attached is:
-
-    <disk type='block' device='lun' rawio='yes'>
-      <driver name='qemu' type='raw' cache='none' io='native'/>
-      <source dev='/dev/mapper/360022a11000c1e0a0787c23a000001cb'/>
-      <backingStore/>
-      <target dev='sdb' bus='scsi'/>
-      <alias name='scsi0-0-1-0'/>
-      <address type='drive' controller='0' bus='0' target='1' unit='0'/>
-    </disk>
-
-2) The bt of qemu main thread:
-
-#0 0x0000ffff9d78402c in pread64 () from /lib64/libpthread.so.0
-#1 0x0000aaaace3357d8 in pread64 (__offset=0, __nbytes=4096, __buf=0xaaaad47a5200, __fd=202) at /usr/include/bits/unistd.h:99
-#2 raw_is_io_aligned (fd=fd@entry=202, buf=buf@entry=0xaaaad47a5200, len=len@entry=4096) at block/raw_posix.c:294
-#3 0x0000aaaace33597c in raw_probe_alignment (bs=bs@entry=0xaaaad32ea920, fd=202, errp=errp@entry=0xfffffef7a330) at block/raw_posix.c:349
-#4 0x0000aaaace335a48 in raw_refresh_limits (bs=0xaaaad32ea920, errp=0xfffffef7a330) at block/raw_posix.c:811
-#5 0x0000aaaace3404b0 in bdrv_refresh_limits (bs=0xaaaad32ea920, errp=0xfffffef7a330, errp@entry=0xfffffef7a360) at block/io.c:122
-#6 0x0000aaaace340504 in bdrv_refresh_limits (bs=bs@entry=0xaaaad09ce800, errp=errp@entry=0xfffffef7a3b0) at block/io.c:97
-#7 0x0000aaaace2eb9f0 in bdrv_open_common (bs=bs@entry=0xaaaad09ce800, file=file@entry=0xaaaad0e89800, options=<optimized out>, errp=errp@entry=0xfffffef7a450)
-at block.c:1194
-#8 0x0000aaaace2eedec in bdrv_open_inherit (filename=<optimized out>, filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d",
-reference=reference@entry=0x0, options=<optimized out>, options@entry=0xaaaad3d0f4b0, flags=<optimized out>, flags@entry=128, parent=parent@entry=0x0,
-child_role=child_role@entry=0x0, errp=errp@entry=0xfffffef7a710) at block.c:1895
-#9 0x0000aaaace2ef510 in bdrv_open (filename=filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", reference=reference@entry=0x0,
-options=options@entry=0xaaaad3d0f4b0, flags=flags@entry=128, errp=errp@entry=0xfffffef7a710) at block.c:1979
-#10 0x0000aaaace331ef0 in blk_new_open (filename=filename@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", reference=reference@entry=0x0,
-options=options@entry=0xaaaad3d0f4b0, flags=128, errp=errp@entry=0xfffffef7a710) at block/block_backend.c:213
-#11 0x0000aaaace0da1f4 in blockdev_init (file=file@entry=0xaaaad25f92d0 "/dev/mapper/36384c4f100630193359db7a80000011d", bs_opts=bs_opts@entry=0xaaaad3d0f4b0,
-errp=errp@entry=0xfffffef7a710) at blockdev.c:603
-#12 0x0000aaaace0dc478 in drive_new (all_opts=all_opts@entry=0xaaaad4dc31d0, block_default_type=<optimized out>) at blockdev.c:1116
-#13 0x0000aaaace0e3ee0 in add_init_drive (
-optstr=optstr@entry=0xaaaad0872ec0 "file=/dev/mapper/36384c4f100630193359db7a80000011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native")
-at device_hotplug.c:46
-#14 0x0000aaaace0e3f78 in hmp_drive_add (mon=0xfffffef7a810, qdict=0xaaaad0c8f000) at device_hotplug.c:67
-#15 0x0000aaaacdf7d688 in handle_hmp_command (mon=0xfffffef7a810, cmdline=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:3199
-#16 0x0000aaaacdf7d778 in qmp_human_monitor_command (
-command_line=0xaaaacfc8e3c0 "drive_add dummy file=/dev/mapper/36384c4f100630193359db7a80000011d,format=raw,if=none,id=drive-scsi0-0-0-3,cache=none,aio=native",
-has_cpu_index=false, cpu_index=0, errp=errp@entry=0xfffffef7a968) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:660
-#17 0x0000aaaace0fdb30 in qmp_marshal_human_monitor_command (args=<optimized out>, ret=0xfffffef7a9e0, errp=0xfffffef7a9d8) at qmp-marshal.c:2223
-#18 0x0000aaaace3b6ad0 in do_qmp_dispatch (request=<optimized out>, errp=0xfffffef7aa20, errp@entry=0xfffffef7aa40) at qapi/qmp_dispatch.c:115
-#19 0x0000aaaace3b6d58 in qmp_dispatch (request=<optimized out>) at qapi/qmp_dispatch.c:142
-#20 0x0000aaaacdf79398 in handle_qmp_command (parser=<optimized out>, tokens=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4010
-#21 0x0000aaaace3bd6c0 in json_message_process_token (lexer=0xaaaacf834c80, input=<optimized out>, type=JSON_RCURLY, x=214, y=274) at qobject/json_streamer.c:105
-#22 0x0000aaaace3f3d4c in json_lexer_feed_char (lexer=lexer@entry=0xaaaacf834c80, ch=<optimized out>, flush=flush@entry=false) at qobject/json_lexer.c:319
-#23 0x0000aaaace3f3e6c in json_lexer_feed (lexer=0xaaaacf834c80, buffer=<optimized out>, size=<optimized out>) at qobject/json_lexer.c:369
-#24 0x0000aaaacdf77c64 in monitor_qmp_read (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) at /usr/src/debug/qemu-kvm-2.8.1/monitor.c:4040
-#25 0x0000aaaace0eab18 in tcp_chr_read (chan=<optimized out>, cond=<optimized out>, opaque=0xaaaacf90b280) at qemu_char.c:3260
-#26 0x0000ffff9dadf200 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
-#27 0x0000aaaace3c4a00 in glib_pollfds_poll () at util/main_loop.c:230
---Type <RET> for more, q to quit, c to continue without paging--
-#28 0x0000aaaace3c4a88 in os_host_main_loop_wait (timeout=<optimized out>) at util/main_loop.c:278
-#29 0x0000aaaace3c4bf0 in main_loop_wait (nonblocking=<optimized out>) at util/main_loop.c:534
-#30 0x0000aaaace0f5d08 in main_loop () at vl.c:2120
-#31 0x0000aaaacdf3a770 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:5017
-
-
-From the bt we can see,  when do qmp sush as drive_add,  qemu main thread locks the qemu_global_mutex  and do pread in raw_probe_alignmen. Pread is a synchronous operation. If backend storage network has a large delay or IO pressure is too large,  the pread operation will not return for a long time, which make vcpu thread can't acquire qemu_global_mutex for a long time and make the vcpu thread unable to be scheduled for a long time.  So virtual machine cpu soft lockup happened.
-
-
-I thank  qemu main thread should not hold qemu_global_mutex for a long time when do qmp that involving IO synchronous operation sush pread , ioctl, etc.
-
-Do you have any solutions or good ideas about it? Thanks for your reply!
-
-
-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/176
-
-
diff --git a/results/classifier/118/user-level/1843133 b/results/classifier/118/user-level/1843133
deleted file mode 100644
index e6d1bde8..00000000
--- a/results/classifier/118/user-level/1843133
+++ /dev/null
@@ -1,194 +0,0 @@
-user-level: 0.872
-permissions: 0.854
-debug: 0.851
-device: 0.820
-mistranslation: 0.798
-semantic: 0.788
-peripherals: 0.783
-arm: 0.780
-register: 0.778
-architecture: 0.776
-files: 0.775
-vnc: 0.770
-risc-v: 0.769
-performance: 0.768
-ppc: 0.752
-hypervisor: 0.740
-VMM: 0.740
-network: 0.740
-PID: 0.730
-graphic: 0.729
-kernel: 0.717
-assembly: 0.716
-socket: 0.715
-TCG: 0.713
-virtual: 0.707
-boot: 0.699
-KVM: 0.630
-x86: 0.599
-i386: 0.569
---------------------
-x86: 0.980
-assembly: 0.947
-debug: 0.887
-hypervisor: 0.201
-register: 0.180
-virtual: 0.163
-files: 0.057
-TCG: 0.051
-semantic: 0.042
-performance: 0.026
-PID: 0.026
-risc-v: 0.022
-kernel: 0.018
-device: 0.017
-boot: 0.015
-VMM: 0.015
-socket: 0.013
-i386: 0.010
-vnc: 0.007
-user-level: 0.007
-peripherals: 0.006
-permissions: 0.005
-ppc: 0.005
-architecture: 0.004
-network: 0.003
-graphic: 0.002
-mistranslation: 0.002
-KVM: 0.001
-arm: 0.000
-
-Possibly incorrect branch in qemu-system-hppa
-
-I plan to release a new GNU Lightning soon.
-I no longer have access to any physical HPPA, but code that
-was tested some years ago did work on HPPA/HP-UX, and now it
-appears qemu-system-hppa incorrectly branches in code generated
-by GNU Lightning. Currently only 32 bit hppa jit generation
-supported.
-
-In the lightning check/test tool, the code would be:
-
-.code
-    prolog
-    movi %r0 0x7fffffff
-    movi %r1 1
-    boaddr L0 %r0 %r1
-    calli @abort
-L0:
-    ret
-    epilog
-
-The code/debug information looks like this:
-            movi r4 0x7fffffff
-            0xf8ef5018      ldil L%7ffff800,r4
-            0xf8ef501c      ldo 7ff(r4),r4
-            movi r5 0x1
-            0xf8ef5020      ldi 1,r5
-        boaddr L1 r4 r5
-            0xf8ef5024      addb,sv,n r5,r4,0xf8ef5044 :a.tst:291
-            0xf8ef5028      nop
-        calli 0xf8eeb68a
-            [...]
-    L1:
-
-Apparently it is not understanding 0x7fffffff + 1 is a signed overflow.
-
-Tested in Fedora with qemu-system-hppa-3.1.1-2.fc30.x86_64 and using
-the debian-10 image.
-
-To make it a bit easier to test (partially transformed the
-not so optimized code generated by lightning to gcc -S output):
-# cat a.s
-	.LEVEL 1.1
-	.text
-	.align 4
-.globl main
-	.type	main, @function
-main:
-	.PROC
-	.CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3
-	.ENTRY
-	copy %r3,%r1
-	copy %r30,%r3
-	stwm %r1,64(%r30)
-	zdepi -1,31,31,%r23
-	ldi 1,%r24
-	addb,sv,n %r24,%r23,.L0
-	nop
-	ldi 1,%r28
-	b,n .L1
-	nop
-.L0:
-	ldi 0,%r28
-.L1:
-	ldo 64(%r3),%r30
-	ldwm -64(%r30),%r3
-	bv,n %r0(%r2)
-	.EXIT
-	.PROCEND
-	.size	main, .-main
-
-# gcc a.s
-# ./a.out; echo $?
-1
-
-It should have returned 0.
-
-As a side note, the branch is correct if testing 0xffffffe + 2
-or other combinations to cause a signed overflow. The only
-special pattern that fails is '0x7ffffff + 1'.
-
-
-This test case works for me.
-
-$ ./hppa-linux-user/qemu-hppa ~/a.out
-$ echo $?
-0
-
-From -d in_asm,cpu logs:
-
-IN: main
-0x000112d0:  addb,*<,n r24,r23,0x112e4
-
-IA_F 000112d3 IA_B 000112d7
-PSW  0000bf00 CB   11111111 ------------------
-GR00 00000000 GR01 00000000 GR02 0001162b GR03 ff7fe9c0
-GR04 00011b94 GR05 00011c6c GR06 00000000 GR07 00000000
-GR08 00000000 GR09 00000000 GR10 00000000 GR11 00000000
-GR12 00000000 GR13 00000000 GR14 00000000 GR15 00000000
-GR16 00000000 GR17 00000000 GR18 00000000 GR19 ff7fe888
-GR20 00000000 GR21 00000000 GR22 000112bc GR23 7fffffff
-GR24 00000001 GR25 ff7fe674 GR26 00000001 GR27 0009a0e0
-GR28 0009f080 GR29 00000001 GR30 ff7fea00 GR31 0001162b
-
-About to execute the addb; r23 and r24 as expected.
-
-----------------
-IN: main
-0x000112e4:  ldi 0,ret0
-
-IA_F 000112e7 IA_B 000112eb
-PSW  0000bf00 CB   11111111 ------------------
-GR00 00000000 GR01 00000000 GR02 0001162b GR03 ff7fe9c0
-GR04 00011b94 GR05 00011c6c GR06 00000000 GR07 00000000
-GR08 00000000 GR09 00000000 GR10 00000000 GR11 00000000
-GR12 00000000 GR13 00000000 GR14 00000000 GR15 00000000
-GR16 00000000 GR17 00000000 GR18 00000000 GR19 ff7fe888
-GR20 00000000 GR21 00000000 GR22 000112bc GR23 80000000
-GR24 00000001 GR25 ff7fe674 GR26 00000001 GR27 0009a0e0
-GR28 0009f080 GR29 00000001 GR30 ff7fea00 GR31 0001162b
-
-The branch has been taken, correctly.
-We can see the expected result in r23.
-
-I've also tested this in system mode, though getting logs
-from that is significantly more difficult.
-
-I am testing git master, not v3.1.1.  Can you please try
-the development version?
-
-I built qemu 4.1.0, and the problem no longer happens.
-It is good enough for me.
-
-
diff --git a/results/classifier/118/user-level/1863025 b/results/classifier/118/user-level/1863025
deleted file mode 100644
index 797ed7e0..00000000
--- a/results/classifier/118/user-level/1863025
+++ /dev/null
@@ -1,493 +0,0 @@
-user-level: 0.869
-mistranslation: 0.853
-permissions: 0.839
-semantic: 0.797
-register: 0.766
-risc-v: 0.766
-graphic: 0.764
-architecture: 0.733
-performance: 0.728
-peripherals: 0.717
-ppc: 0.716
-TCG: 0.713
-assembly: 0.709
-virtual: 0.702
-hypervisor: 0.700
-device: 0.696
-vnc: 0.668
-debug: 0.659
-arm: 0.649
-PID: 0.646
-files: 0.606
-VMM: 0.597
-x86: 0.589
-KVM: 0.586
-boot: 0.583
-kernel: 0.550
-network: 0.527
-socket: 0.523
-i386: 0.504
---------------------
-TCG: 0.963
-kernel: 0.625
-assembly: 0.167
-virtual: 0.108
-hypervisor: 0.084
-x86: 0.077
-VMM: 0.058
-PID: 0.055
-KVM: 0.049
-files: 0.048
-debug: 0.047
-ppc: 0.038
-user-level: 0.037
-risc-v: 0.037
-vnc: 0.033
-device: 0.031
-register: 0.030
-i386: 0.029
-socket: 0.027
-permissions: 0.025
-semantic: 0.015
-architecture: 0.014
-arm: 0.013
-network: 0.012
-peripherals: 0.010
-performance: 0.008
-boot: 0.006
-graphic: 0.004
-mistranslation: 0.002
-
-Use-after-free after flush in TCG accelerator
-
-I believe I found a UAF in TCG that can lead to a guest VM escape. The security 
-list informed me "This can not be treated as a security issue." and to post it 
-here. I am looking at the 4.2.0 source code. The issue requires a race and I 
-will try to describe it in terms of three concurrent threads.
-
-I am looking 
-at the 4.2.0 source code. The issue requires a race and I will try to describe 
-it in terms of three concurrent threads.
-
-Thread A:
-
-A1. qemu_tcg_cpu_thread_fn runs work loop
-A2. qemu_wait_io_event => qemu_wait_io_event_common => process_queued_cpu_work
-A3. start_exclusive critical section entered
-A4. do_tb_flush is called, TB memory freed/re-allocated
-A5. end_exclusive exits critical section
-
-Thread B:
-
-B1. qemu_tcg_cpu_thread_fn runs work loop
-B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code
-B3. tcg_tb_alloc obtains a new TB
-
-Thread C:
-
-C1. qemu_tcg_cpu_thread_fn runs work loop
-C2. cpu_exec_step_atomic executes
-C3. TB obtained with tb_lookup__cpu_state or tb_gen_code
-C4. start_exclusive critical section entered
-C5. cpu_tb_exec executes the TB code
-C6. end_exclusive exits critical section
-
-Consider the following sequence of events:
-  B2 => B3 => C3 (same TB as B2) => A3 => A4 (TB freed) => A5 => B2 => 
-  B3 (re-allocates TB from B2) => C4 => C5 (freed/reused TB now executing) => C6
-
-In short, because thread C uses the TB in the critical section, there is no 
-guarantee that the pointer has not been "freed" (rather the memory is marked as 
-re-usable) and therefore a use-after-free occurs.
-
-Since the TCG generated code can be in the same memory as the TB data structure,
-it is possible for an attacker to overwrite the UAF pointer with code generated
-from TCG. This can overwrite key pointer values and could lead to code 
-execution on the host outside of the TCG sandbox.
-
-The bug describes a race whereby cpu_exec_step_atomic can acquire a TB
-which is invalidated by a tb_flush before we execute it. This doesn't
-affect the other cpu_exec modes as a tb_flush by it's nature can only
-occur on a quiescent system. The race was described as:
-
-  B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code
-  B3. tcg_tb_alloc obtains a new TB
-
-      C3. TB obtained with tb_lookup__cpu_state or tb_gen_code
-          (same TB as B2)
-
-          A3. start_exclusive critical section entered
-          A4. do_tb_flush is called, TB memory freed/re-allocated
-          A5. end_exclusive exits critical section
-
-  B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code
-  B3. tcg_tb_alloc reallocates TB from B2
-
-      C4. start_exclusive critical section entered
-      C5. cpu_tb_exec executes the TB code that was free in A4
-
-The simplest fix is to widen the exclusive period to include the TB
-lookup. As a result we can drop the complication of checking we are in
-the exclusive region before we end it.
-
-Signed-off-by: Alex Bennée <email address hidden>
-Cc: Yifan <email address hidden>
-Cc: Bug 1863025 <email address hidden>
----
- accel/tcg/cpu-exec.c | 21 +++++++++++----------
- 1 file changed, 11 insertions(+), 10 deletions(-)
-
-diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
-index 2560c90eec7..d95c4848a47 100644
---- a/accel/tcg/cpu-exec.c
-+++ b/accel/tcg/cpu-exec.c
-@@ -240,6 +240,8 @@ void cpu_exec_step_atomic(CPUState *cpu)
-     uint32_t cf_mask = cflags & CF_HASH_MASK;
- 
-     if (sigsetjmp(cpu->jmp_env, 0) == 0) {
-+        start_exclusive();
-+
-         tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, cf_mask);
-         if (tb == NULL) {
-             mmap_lock();
-@@ -247,8 +249,6 @@ void cpu_exec_step_atomic(CPUState *cpu)
-             mmap_unlock();
-         }
- 
--        start_exclusive();
--
-         /* Since we got here, we know that parallel_cpus must be true.  */
-         parallel_cpus = false;
-         cc->cpu_exec_enter(cpu);
-@@ -271,14 +271,15 @@ void cpu_exec_step_atomic(CPUState *cpu)
-         qemu_plugin_disable_mem_helpers(cpu);
-     }
- 
--    if (cpu_in_exclusive_context(cpu)) {
--        /* We might longjump out of either the codegen or the
--         * execution, so must make sure we only end the exclusive
--         * region if we started it.
--         */
--        parallel_cpus = true;
--        end_exclusive();
--    }
-+
-+    /*
-+     * As we start the exclusive region before codegen we must still
-+     * be in the region if we longjump out of either the codegen or
-+     * the execution.
-+     */
-+    g_assert(cpu_in_exclusive_context(cpu));
-+    parallel_cpus = true;
-+    end_exclusive();
- }
- 
- struct tb_desc {
--- 
-2.20.1
-
-
-
-I've attached a variant of the suggested patch which simply expands the exclusive period. It's hard to test extensively as not many things use the EXCP_ATOMIC mechanism. Can I ask how you found the bug and if you can re-test with the suggested patch?
-
-I found it just by launching Ubuntu 19.10 live cd with QXL driver. I will re-test this weekend.
-
-The workaround I had is to check the number of TLB flushes and to re-try obtaining the TB if the number changes. There is a penalty for the case where TLB is flushed but should not degrade performance in most cases. I think obtaining the lock earlier will slow down the VM if EXCP_ATOMIC is used often.
-
-Of course, I am assuming TLB flush is the only way to cause this bug.
-
-diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
-index d1c2b6ea1fd..d83b578299b 100644
---- a/accel/tcg/cpu-exec.c
-+++ b/accel/tcg/cpu-exec.c
-@@ -250,8 +250,11 @@ void cpu_exec_step_atomic(CPUState *cpu)
-     uint32_t flags;
-     uint32_t cflags = 1;
-     uint32_t cf_mask = cflags & CF_HASH_MASK;
-+    unsigned flush_count;
- 
-     if (sigsetjmp(cpu->jmp_env, 0) == 0) {
-+retry:
-+        flush_count = tb_flush_count();
-         tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, cf_mask);
-         if (tb == NULL) {
-             mmap_lock();
-@@ -260,6 +263,11 @@ void cpu_exec_step_atomic(CPUState *cpu)
-         }
- 
-         start_exclusive();
-+        /* do_tb_flush() might run and make tb invalid */
-+        if (flush_count != tb_flush_count()) {
-+            end_exclusive();
-+            goto retry;
-+        }
- 
-         /* Since we got here, we know that parallel_cpus must be true.  */
-         parallel_cpus = false;
-diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
-index 4ed9d0abaf2..ecf7d3b53ff 100644
---- a/accel/tcg/translate-all.c
-+++ b/accel/tcg/translate-all.c
-@@ -2696,6 +2696,11 @@ void tcg_flush_softmmu_tlb(CPUState *cs)
- #endif
- }
- 
-+unsigned tb_flush_count(void)
-+{
-+    return atomic_read(&tb_ctx.tb_flush_count);
-+}
-+
- #if defined(CONFIG_NO_RWX)
- void tb_exec_memory_lock(void)
- {
-diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
-index 5ccc9485812..1bc61fa6d76 100644
---- a/include/exec/exec-all.h
-+++ b/include/exec/exec-all.h
-@@ -584,6 +584,7 @@ void tlb_set_dirty(CPUState *cpu, target_ulong vaddr);
- void tb_flush_jmp_cache(CPUState *cpu, target_ulong addr);
- 
- /* translate-all.c */
-+unsigned tb_flush_count(void);
- #if defined(CONFIG_NO_RWX)
- void tb_exec_memory_lock(void);
- bool tb_is_exec(const TranslationBlock *tb);
-
-Apologies, the patch got messed up.
-
-diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
-index c01f59c743..7a9e8c94bd 100644
---- a/accel/tcg/cpu-exec.c
-+++ b/accel/tcg/cpu-exec.c
-@@ -238,8 +238,11 @@ void cpu_exec_step_atomic(CPUState *cpu)
-     uint32_t flags;
-     uint32_t cflags = 1;
-     uint32_t cf_mask = cflags & CF_HASH_MASK;
-+    unsigned flush_count;
- 
-     if (sigsetjmp(cpu->jmp_env, 0) == 0) {
-+retry:
-+        flush_count = tb_flush_count();
-         tb = tb_lookup__cpu_state(cpu, &pc, &cs_base, &flags, cf_mask);
-         if (tb == NULL) {
-             mmap_lock();
-@@ -248,6 +251,11 @@ void cpu_exec_step_atomic(CPUState *cpu)
-         }
- 
-         start_exclusive();
-+        /* do_tb_flush() might run and make tb invalid */
-+        if (flush_count != tb_flush_count()) {
-+            end_exclusive();
-+            goto retry;
-+        }
- 
-         /* Since we got here, we know that parallel_cpus must be true.  */
-         parallel_cpus = false;
-diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
-index 9f48da9472..2fb7da9b51 100644
---- a/accel/tcg/translate-all.c
-+++ b/accel/tcg/translate-all.c
-@@ -2674,3 +2674,8 @@ void tcg_flush_softmmu_tlb(CPUState *cs)
-     tlb_flush(cs);
- #endif
- }
-+
-+unsigned tb_flush_count(void)
-+{
-+    return atomic_read(&tb_ctx.tb_flush_count);
-+}
-diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
-index d85e610e85..aa3c2d219a 100644
---- a/include/exec/exec-all.h
-+++ b/include/exec/exec-all.h
-@@ -579,6 +579,9 @@ void tlb_set_dirty(CPUState *cpu, target_ulong vaddr);
- /* exec.c */
- void tb_flush_jmp_cache(CPUState *cpu, target_ulong addr);
- 
-+/* translate-all.c */
-+unsigned tb_flush_count(void);
-+
- MemoryRegionSection *
- address_space_translate_for_iotlb(CPUState *cpu, int asidx, hwaddr addr,
-                                   hwaddr *xlat, hwaddr *plen,
-
-What race are you thinking of in my patch? The obvious race I can
-think of is benign:
-
-Case 1:
-A: does TB flush
-B: read tb_flush_count
-A: increment tb_flush_count
-A: end_exclusive
-B: tb_lookup__cpu_state/tb_gen_code
-B: start_exclusive
-B: read tb_flush_count again (increment seen)
-B: retries
-
-Case 2:
-B: read tb_flush_count
-A: does TB flush
-A: increment tb_flush_count
-A: end_exclusive
-B: tb_lookup__cpu_state/tb_gen_code
-B: start_exclusive
-B: read tb_flush_count again (increment seen)
-B: retries
-
-Case 3:
-A: does TB flush
-A: increment tb_flush_count
-A: end_exclusive
-B: read tb_flush_count
-B: tb_lookup__cpu_state/tb_gen_code
-B: start_exclusive
-B: read tb_flush_count again (no increment seen)
-B: proceeds
-
-Case 1 is the expected case. Case 2, we thought TB was stale but it
-wasn't so we get it again with tb_lookup__cpu_state with minimal extra
-overhead.
-
-Case 3 seems to be bad because we could read tb_flush_count and find
-it already incremented. But if so that means thread A is at the end of
-do_tb_flush and the lookup tables are already cleared and the TCG
-context is already reset. So it should be safe for thread B to call
-tb_lookup__cpu_state or tb_gen_code.
-
-Yifan
-
-On Fri, Feb 14, 2020 at 3:31 PM Richard Henderson
-<email address hidden> wrote:
->
-> On 2/14/20 6:49 AM, Alex Bennée wrote:
-> > The bug describes a race whereby cpu_exec_step_atomic can acquire a TB
-> > which is invalidated by a tb_flush before we execute it. This doesn't
-> > affect the other cpu_exec modes as a tb_flush by it's nature can only
-> > occur on a quiescent system. The race was described as:
-> >
-> >   B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code
-> >   B3. tcg_tb_alloc obtains a new TB
-> >
-> >       C3. TB obtained with tb_lookup__cpu_state or tb_gen_code
-> >           (same TB as B2)
-> >
-> >           A3. start_exclusive critical section entered
-> >           A4. do_tb_flush is called, TB memory freed/re-allocated
-> >           A5. end_exclusive exits critical section
-> >
-> >   B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code
-> >   B3. tcg_tb_alloc reallocates TB from B2
-> >
-> >       C4. start_exclusive critical section entered
-> >       C5. cpu_tb_exec executes the TB code that was free in A4
-> >
-> > The simplest fix is to widen the exclusive period to include the TB
-> > lookup. As a result we can drop the complication of checking we are in
-> > the exclusive region before we end it.
->
-> I'm not 100% keen on having the tb_gen_code within the exclusive region.  It
-> implies a much larger delay on (at least) the first execution of the atomic
-> operation.
->
-> But I suppose until recently we had a global lock around code generation, and
-> this is only slightly worse.  Plus, it has the advantage of being dead simple,
-> and without the races vs tb_ctx.tb_flush_count that exist in Yifan's patch.
->
-> Applied to tcg-next.
->
->
-> r~
-
-
-Fixed here:
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=886cc68943eb
-
-CVE-2020-24165 was assigned to this:
-https://nvd.nist.gov/vuln/detail/CVE-2020-24165
-
-I had no involvement in the assignment, posting here for reference only.
-
-On Thu, Aug 31, 2023 at 03:40:25PM +0200, Philippe Mathieu-Daudé wrote:
-> Hi Samuel,
-> 
-> On 31/8/23 14:48, Samuel Henrique wrote:
-> > CVE-2020-24165 was assigned to this:
-> > https://nvd.nist.gov/vuln/detail/CVE-2020-24165
-> > 
-> > I had no involvement in the assignment, posting here for reference only.
-> > 
-> > ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-24165
-> 
-> QEMU 4.2.0 was released in 2019. The issue you report
-> has been fixed in commit 886cc68943 ("accel/tcg: fix race
-> in cpu_exec_step_atomic (bug 1863025)") which is included
-> in QEMU v5.0, released in April 2020, more than 3 years ago.
-> 
-> What do you expect us to do here? I'm not sure whether assigning
-> CVE for 3 years old code is a good use of engineering time.
-
-In any case per our stated security policy, we do not consider TCG to
-be providing a security boundary between host and guest, and thus bugs
-in TCG aren't considered security flaws:
-
- https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case
-
-With regards,
-Daniel
--- 
-|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
-|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
-|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
-
-
-On Thu, Aug 31, 2023 at 3:57 PM Daniel P. Berrangé <email address hidden> wrote:
->
-> On Thu, Aug 31, 2023 at 03:40:25PM +0200, Philippe Mathieu-Daudé wrote:
-> > Hi Samuel,
-> >
-> > On 31/8/23 14:48, Samuel Henrique wrote:
-> > > CVE-2020-24165 was assigned to this:
-> > > https://nvd.nist.gov/vuln/detail/CVE-2020-24165
-> > >
-> > > I had no involvement in the assignment, posting here for reference only.
-> > >
-> > > ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-24165
-> >
-> > QEMU 4.2.0 was released in 2019. The issue you report
-> > has been fixed in commit 886cc68943 ("accel/tcg: fix race
-> > in cpu_exec_step_atomic (bug 1863025)") which is included
-> > in QEMU v5.0, released in April 2020, more than 3 years ago.
-> >
-> > What do you expect us to do here? I'm not sure whether assigning
-> > CVE for 3 years old code is a good use of engineering time.
->
-> In any case per our stated security policy, we do not consider TCG to
-> be providing a security boundary between host and guest, and thus bugs
-> in TCG aren't considered security flaws:
->
->  https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case
-
-Right, and it is clearly indicated in the referenced launchpad bug:
-'The security list informed me "This can not be treated as a security
-issue"'.
-
-This adds up to CVE-2022-36648, which is also a mystery to me in terms
-of CVE assignment and CVSS scoring (rated as Critical). I don't know
-what's going on with NVD, there must be something wrong on their side.
-
-I disputed both CVEs via https://cveform.mitre.org/.
-
-> With regards,
-> Daniel
-> --
-> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
-> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
-> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
->
-
--- 
-Mauro Matteo Cascella
-Red Hat Product Security
-PGP-Key ID: BB3410B0
-
-
diff --git a/results/classifier/118/user-level/1894361 b/results/classifier/118/user-level/1894361
deleted file mode 100644
index 6cf28a90..00000000
--- a/results/classifier/118/user-level/1894361
+++ /dev/null
@@ -1,81 +0,0 @@
-user-level: 0.952
-arm: 0.779
-risc-v: 0.746
-graphic: 0.743
-semantic: 0.734
-mistranslation: 0.726
-device: 0.663
-architecture: 0.632
-vnc: 0.614
-ppc: 0.604
-files: 0.578
-VMM: 0.563
-network: 0.557
-performance: 0.548
-socket: 0.545
-kernel: 0.538
-permissions: 0.528
-PID: 0.502
-register: 0.495
-boot: 0.457
-i386: 0.438
-virtual: 0.423
-peripherals: 0.421
-x86: 0.378
-KVM: 0.366
-hypervisor: 0.352
-TCG: 0.350
-debug: 0.303
-assembly: 0.248
---------------------
-user-level: 0.863
-arm: 0.828
-kernel: 0.699
-virtual: 0.053
-files: 0.048
-TCG: 0.035
-register: 0.027
-hypervisor: 0.020
-debug: 0.015
-semantic: 0.008
-network: 0.008
-x86: 0.007
-PID: 0.007
-device: 0.003
-risc-v: 0.003
-i386: 0.003
-architecture: 0.003
-ppc: 0.002
-assembly: 0.002
-performance: 0.002
-socket: 0.001
-graphic: 0.001
-VMM: 0.001
-permissions: 0.001
-boot: 0.001
-peripherals: 0.001
-KVM: 0.001
-vnc: 0.001
-mistranslation: 0.000
-
-linux-user: syscall.c lacks pselect6_time64
-
-in commit 50efc69586388a975c1ebd90cb8cc8e4a7328bc4 legacy pselect6 definition
-for riscv32 was removed in favour of pselect6_time64, but pselect6_time64 is
-not available in syscall.c, thus leaving riscv32 without pselect syscall.
-
-pselect6_time64() has been implemented but it has not been merged because during the test I've seen it breaks ARM target.
-
-https://<email address hidden><email address hidden>/
-
-I try to fix that and merge that soon.
-
-Fix available in my branch:
-
-https://github.com/vivier/qemu/commits/linux-user-for-5.2
-
-Fixed here:
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e5ce9688b47a8f60337ce1e4108f35577494a46a
-
-Released with QEMU v5.2.0.
-
diff --git a/results/classifier/118/user-level/1903833 b/results/classifier/118/user-level/1903833
deleted file mode 100644
index 445e2bd6..00000000
--- a/results/classifier/118/user-level/1903833
+++ /dev/null
@@ -1,86 +0,0 @@
-user-level: 0.923
-x86: 0.778
-graphic: 0.619
-device: 0.618
-architecture: 0.609
-semantic: 0.533
-performance: 0.518
-ppc: 0.385
-boot: 0.358
-network: 0.350
-permissions: 0.344
-assembly: 0.337
-socket: 0.330
-mistranslation: 0.286
-debug: 0.273
-PID: 0.265
-i386: 0.264
-register: 0.239
-vnc: 0.230
-peripherals: 0.220
-VMM: 0.191
-virtual: 0.185
-risc-v: 0.175
-arm: 0.163
-files: 0.148
-KVM: 0.119
-hypervisor: 0.104
-kernel: 0.103
-TCG: 0.095
---------------------
-user-level: 0.989
-virtual: 0.820
-debug: 0.406
-arm: 0.100
-architecture: 0.047
-performance: 0.039
-TCG: 0.024
-files: 0.021
-register: 0.015
-PID: 0.009
-semantic: 0.006
-network: 0.006
-device: 0.004
-hypervisor: 0.004
-assembly: 0.004
-boot: 0.003
-socket: 0.002
-VMM: 0.002
-kernel: 0.002
-risc-v: 0.002
-peripherals: 0.001
-permissions: 0.001
-ppc: 0.001
-x86: 0.001
-KVM: 0.001
-vnc: 0.001
-graphic: 0.000
-mistranslation: 0.000
-i386: 0.000
-
-User mode qemu-aarch: SIGGSEGV signal handler works wrong
-
-I have a user mode qemu-aarch issue. Program with SIGSEGV signal handler works wrong under qemu-aarch: 
-once the progam handles the SEGV signal, qemu marks the program's page protected, and signal handler gets SEGV on each subsequent memory access instruction within a program.
-
-The issue is reproduced on WSL Ubuntu 20.04 under Windows 10, qemu-aarch64 version 5.1.50
-The issue is also reproducible on the latest upstream qemu-aarch build.
-
-The following workaround disables mprotect call and fixes the issue: https://github.com/BorisUlasevich/qemu/commit/3063d9a64f8395185d65c6b6710d28ee92cd8be5
-
-The issue can be reproduced on OpenJDK which reports SIGSEGV immediately after start. The small reproducer program is attached.
-
-
-
-The patch is most definitely wrong.  The page protection
-is required to implement self-modifying code, of which a
-signal trampoline is a subset.
-
-Moreover, your test case works for me using both
-x86_64-linux and aarch64-linux as hosts.
-
-There may be a bug, but I suspect it to be within WSL.
-I have no way to test that one way or another.
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/user-level/1912 b/results/classifier/118/user-level/1912
deleted file mode 100644
index 8f8dd417..00000000
--- a/results/classifier/118/user-level/1912
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.941
-device: 0.726
-ppc: 0.654
-debug: 0.631
-performance: 0.571
-architecture: 0.434
-graphic: 0.406
-peripherals: 0.377
-network: 0.365
-boot: 0.355
-semantic: 0.348
-register: 0.286
-arm: 0.242
-mistranslation: 0.192
-assembly: 0.184
-TCG: 0.158
-permissions: 0.154
-PID: 0.152
-files: 0.115
-virtual: 0.059
-kernel: 0.057
-i386: 0.057
-VMM: 0.046
-vnc: 0.039
-risc-v: 0.038
-KVM: 0.030
-socket: 0.028
-x86: 0.018
-hypervisor: 0.002
---------------------
-user-level: 0.952
-kernel: 0.413
-debug: 0.253
-files: 0.056
-x86: 0.031
-register: 0.024
-PID: 0.021
-virtual: 0.019
-TCG: 0.015
-performance: 0.015
-semantic: 0.009
-VMM: 0.005
-peripherals: 0.004
-ppc: 0.004
-device: 0.004
-assembly: 0.003
-KVM: 0.003
-boot: 0.003
-i386: 0.003
-socket: 0.002
-graphic: 0.002
-architecture: 0.002
-network: 0.001
-hypervisor: 0.001
-permissions: 0.001
-risc-v: 0.001
-arm: 0.001
-vnc: 0.000
-mistranslation: 0.000
-
-linux-user: (recursive) segfault when built with -static -disable-pie
diff --git a/results/classifier/118/user-level/196 b/results/classifier/118/user-level/196
deleted file mode 100644
index 376b899d..00000000
--- a/results/classifier/118/user-level/196
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.926
-device: 0.913
-arm: 0.695
-PID: 0.496
-permissions: 0.465
-boot: 0.461
-mistranslation: 0.442
-graphic: 0.413
-register: 0.406
-assembly: 0.404
-risc-v: 0.392
-ppc: 0.391
-semantic: 0.389
-network: 0.324
-socket: 0.323
-VMM: 0.306
-files: 0.301
-vnc: 0.251
-TCG: 0.248
-KVM: 0.213
-architecture: 0.150
-performance: 0.137
-i386: 0.123
-kernel: 0.111
-peripherals: 0.074
-virtual: 0.068
-debug: 0.060
-hypervisor: 0.043
-x86: 0.005
---------------------
-user-level: 0.883
-boot: 0.103
-virtual: 0.092
-device: 0.071
-semantic: 0.045
-performance: 0.038
-files: 0.029
-PID: 0.024
-register: 0.022
-assembly: 0.013
-debug: 0.011
-graphic: 0.010
-kernel: 0.009
-x86: 0.009
-arm: 0.006
-VMM: 0.004
-hypervisor: 0.004
-TCG: 0.003
-risc-v: 0.003
-peripherals: 0.002
-socket: 0.002
-network: 0.002
-KVM: 0.001
-architecture: 0.001
-i386: 0.001
-permissions: 0.000
-vnc: 0.000
-ppc: 0.000
-mistranslation: 0.000
-
-Improve UX for macOS when launching from a fullscreen app
diff --git a/results/classifier/118/user-level/1964 b/results/classifier/118/user-level/1964
deleted file mode 100644
index 627b0371..00000000
--- a/results/classifier/118/user-level/1964
+++ /dev/null
@@ -1,67 +0,0 @@
-user-level: 0.969
-TCG: 0.967
-debug: 0.855
-architecture: 0.835
-device: 0.833
-graphic: 0.778
-risc-v: 0.726
-socket: 0.630
-permissions: 0.607
-vnc: 0.598
-x86: 0.516
-boot: 0.515
-register: 0.500
-PID: 0.466
-semantic: 0.449
-arm: 0.427
-ppc: 0.422
-network: 0.394
-performance: 0.385
-kernel: 0.354
-files: 0.335
-VMM: 0.280
-mistranslation: 0.254
-hypervisor: 0.244
-peripherals: 0.231
-i386: 0.189
-virtual: 0.179
-KVM: 0.131
-assembly: 0.041
---------------------
-debug: 0.920
-TCG: 0.878
-x86: 0.569
-virtual: 0.441
-user-level: 0.428
-graphic: 0.272
-KVM: 0.198
-files: 0.095
-i386: 0.065
-register: 0.046
-hypervisor: 0.045
-device: 0.030
-PID: 0.022
-risc-v: 0.020
-performance: 0.019
-architecture: 0.015
-ppc: 0.011
-socket: 0.011
-semantic: 0.011
-arm: 0.010
-network: 0.010
-assembly: 0.006
-vnc: 0.006
-kernel: 0.004
-peripherals: 0.003
-VMM: 0.003
-permissions: 0.002
-boot: 0.001
-mistranslation: 0.000
-
-QEMU TCG faulted in RUNDLL32 at Windows 98SE Display Properties
-Description of problem:
-QEMU TCG faulted in RUNDLL32 at Windows 98SE Display Properties. 100% consistently reproducible across multiple host operating systems and CPU architectures and all types of QEMU emulated display controllers supported by Windows 98SE (`VGA, cirrus-vga and vmware-svga`). It is a user-mode fault so the OS simply terminated the faulting process, OS remains fully functional after the fault and the same fault can be repeated. Should be extremely helpful in debugging. Last known good QEMU version without this bug is 7.1.0. For x86_64, KVM and WHPX do not have the issue and can be used to gain access to Display Properties. On AArch64, last known good QEMU version is the only way to gain access to Display Properties.
-Steps to reproduce:
-See attached recorded video.
-
-![Screen_Recording_2023-10-27_at_2.44.18_AM](/uploads/0b8cff9b70606532312593d48b7df79a/Screen_Recording_2023-10-27_at_2.44.18_AM.mov)
diff --git a/results/classifier/118/user-level/2170 b/results/classifier/118/user-level/2170
deleted file mode 100644
index 8f483848..00000000
--- a/results/classifier/118/user-level/2170
+++ /dev/null
@@ -1,104 +0,0 @@
-user-level: 0.813
-graphic: 0.758
-KVM: 0.730
-TCG: 0.726
-x86: 0.714
-register: 0.710
-performance: 0.705
-semantic: 0.690
-i386: 0.686
-device: 0.686
-ppc: 0.685
-arm: 0.683
-mistranslation: 0.681
-permissions: 0.675
-debug: 0.672
-vnc: 0.667
-architecture: 0.667
-virtual: 0.654
-VMM: 0.652
-PID: 0.636
-peripherals: 0.634
-assembly: 0.627
-hypervisor: 0.614
-socket: 0.602
-network: 0.599
-kernel: 0.594
-risc-v: 0.582
-boot: 0.568
-files: 0.515
---------------------
-x86: 0.990
-user-level: 0.896
-debug: 0.745
-TCG: 0.528
-virtual: 0.091
-files: 0.079
-performance: 0.072
-PID: 0.053
-register: 0.029
-assembly: 0.026
-kernel: 0.021
-hypervisor: 0.018
-semantic: 0.009
-architecture: 0.008
-device: 0.007
-ppc: 0.005
-network: 0.004
-risc-v: 0.004
-socket: 0.003
-VMM: 0.002
-graphic: 0.002
-permissions: 0.002
-boot: 0.002
-peripherals: 0.002
-vnc: 0.001
-KVM: 0.001
-mistranslation: 0.001
-arm: 0.000
-i386: 0.000
-
-qemu-x86_64 crashes when the application calls pthread_getattr_np()
-Description of problem:
-QEMU user emulation crashes with this program:
-```
-#define _GNU_SOURCE
-#include <stdio.h>
-#include <pthread.h>
-
-int main()
-{
-        pthread_attr_t attr;
-        int error = pthread_getattr_np(pthread_self(), &attr);
-
-        printf("%d\n", error);
-        return 0;
-}
-```
-Steps to reproduce:
-1. Compile the program above
-2. Run QEMU
-Additional information:
-QEMU crashes with:
-```
-qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20}
-Segmentation fault (core dumped)
-
-```
-
-In gdb I get this backtrace:
-```
-#0  0x0000555555627d6d in open_self_maps_2 (opaque=0x7fffffffc020, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089
-#1  0x000055555560ce67 in walk_memory_regions (priv=priv@entry=0x7fffffffc020, fn=fn@entry=0x555555627d30 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176
-#2  0x0000555555628b3a in open_self_maps_1 (smaps=<optimized out>, fd=<optimized out>, env=<optimized out>) at ../linux-user/syscall.c:8112
-#3  open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122
-#4  0x0000555555631e24 in do_guest_openat (cpu_env=cpu_env@entry=0x55555583ae20, dirfd=dirfd@entry=-100, fname=fname@entry=0x2aaaab496eb4 "/proc/self/maps", flags=524288, mode=mode@entry=0, safe=safe@entry=true) at ../linux-user/syscall.c:8381
-#5  0x0000555555638f71 in do_syscall1 (cpu_env=cpu_env@entry=0x55555583ae20, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=46912506523316, arg3=arg3@entry=524288, arg4=arg4@entry=0, arg5=<optimized out>, arg6=<optimized out>, arg8=0, arg7=0) at ../linux-user/syscall.c:9075
-#6  0x000055555563b659 in do_syscall (cpu_env=cpu_env@entry=0x55555583ae20, num=257, arg1=4294967196, arg2=46912506523316, arg3=524288, arg4=0, arg5=8, arg6=1, arg7=0, arg8=0) at ../linux-user/syscall.c:13658
-#7  0x000055555558db19 in cpu_loop (env=env@entry=0x55555583ae20) at ../linux-user/x86_64/../i386/cpu_loop.c:242
-#8  0x00005555555898d8 in main (argc=<optimized out>, argv=0x7fffffffdd38, envp=<optimized out>) at ../linux-user/main.c:1012
-
-```
-
-This bug was introduced in the rewrite of `open_self_maps` in 7b7a3366e142d3baeb3fd1d3660a50e7956c19eb.
-The current master (5767815218efd3cbfd409505ed824d5f356044ae) is still affected.
diff --git a/results/classifier/118/user-level/241 b/results/classifier/118/user-level/241
deleted file mode 100644
index 58b02991..00000000
--- a/results/classifier/118/user-level/241
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.945
-performance: 0.889
-peripherals: 0.887
-mistranslation: 0.613
-semantic: 0.465
-graphic: 0.435
-device: 0.403
-ppc: 0.346
-virtual: 0.227
-architecture: 0.174
-files: 0.156
-VMM: 0.115
-arm: 0.111
-TCG: 0.067
-debug: 0.045
-boot: 0.039
-vnc: 0.038
-risc-v: 0.034
-assembly: 0.023
-PID: 0.023
-i386: 0.021
-network: 0.019
-register: 0.017
-socket: 0.013
-hypervisor: 0.012
-x86: 0.012
-kernel: 0.011
-KVM: 0.010
-permissions: 0.007
---------------------
-user-level: 0.898
-files: 0.806
-x86: 0.445
-kernel: 0.361
-i386: 0.034
-virtual: 0.024
-TCG: 0.020
-PID: 0.014
-semantic: 0.011
-VMM: 0.011
-KVM: 0.009
-performance: 0.009
-boot: 0.004
-arm: 0.004
-graphic: 0.004
-hypervisor: 0.002
-architecture: 0.002
-ppc: 0.002
-device: 0.002
-register: 0.002
-assembly: 0.001
-risc-v: 0.001
-socket: 0.001
-debug: 0.001
-permissions: 0.001
-network: 0.001
-vnc: 0.000
-peripherals: 0.000
-mistranslation: 0.000
-
-Please refactor linux-user/mips/cpu_loop.c
diff --git a/results/classifier/118/user-level/276 b/results/classifier/118/user-level/276
deleted file mode 100644
index bd28c1ff..00000000
--- a/results/classifier/118/user-level/276
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.808
-device: 0.701
-debug: 0.605
-arm: 0.603
-performance: 0.585
-graphic: 0.487
-risc-v: 0.323
-network: 0.237
-architecture: 0.201
-boot: 0.194
-vnc: 0.182
-semantic: 0.172
-kernel: 0.162
-ppc: 0.158
-permissions: 0.155
-i386: 0.111
-virtual: 0.102
-KVM: 0.079
-mistranslation: 0.078
-x86: 0.077
-TCG: 0.075
-socket: 0.072
-register: 0.057
-files: 0.057
-VMM: 0.045
-peripherals: 0.041
-PID: 0.038
-hypervisor: 0.013
-assembly: 0.003
---------------------
-user-level: 0.989
-boot: 0.845
-debug: 0.271
-virtual: 0.052
-x86: 0.050
-register: 0.049
-files: 0.033
-assembly: 0.032
-TCG: 0.009
-semantic: 0.007
-performance: 0.006
-device: 0.006
-i386: 0.005
-PID: 0.005
-kernel: 0.004
-architecture: 0.004
-peripherals: 0.004
-ppc: 0.003
-risc-v: 0.002
-VMM: 0.002
-graphic: 0.002
-network: 0.001
-arm: 0.001
-KVM: 0.001
-hypervisor: 0.001
-mistranslation: 0.001
-socket: 0.000
-vnc: 0.000
-permissions: 0.000
-
-Error in user-mode calculation of ELF program's brk
diff --git a/results/classifier/118/user-level/2854 b/results/classifier/118/user-level/2854
deleted file mode 100644
index 7b05caa9..00000000
--- a/results/classifier/118/user-level/2854
+++ /dev/null
@@ -1,84 +0,0 @@
-user-level: 0.939
-graphic: 0.820
-device: 0.751
-semantic: 0.745
-network: 0.686
-permissions: 0.588
-arm: 0.580
-performance: 0.496
-register: 0.471
-vnc: 0.469
-socket: 0.447
-PID: 0.442
-files: 0.433
-debug: 0.417
-mistranslation: 0.414
-ppc: 0.362
-architecture: 0.321
-boot: 0.297
-i386: 0.277
-virtual: 0.254
-risc-v: 0.254
-x86: 0.221
-VMM: 0.218
-TCG: 0.196
-hypervisor: 0.187
-assembly: 0.172
-kernel: 0.156
-KVM: 0.124
-peripherals: 0.064
---------------------
-user-level: 0.969
-hypervisor: 0.365
-TCG: 0.149
-VMM: 0.082
-virtual: 0.062
-network: 0.057
-semantic: 0.052
-x86: 0.022
-boot: 0.010
-files: 0.009
-device: 0.009
-debug: 0.007
-risc-v: 0.006
-PID: 0.006
-i386: 0.006
-register: 0.005
-arm: 0.004
-ppc: 0.004
-kernel: 0.003
-socket: 0.002
-architecture: 0.001
-vnc: 0.001
-performance: 0.001
-permissions: 0.001
-peripherals: 0.001
-assembly: 0.001
-graphic: 0.000
-KVM: 0.000
-mistranslation: 0.000
-
-https://www.qemu.org/ is missing chance to provide (or at least link) some starting guide
-Description of problem:
-as a completely new (potential) user https://www.qemu.org/ main page is missing chance to easily link some hello world documentation
-Steps to reproduce:
-1. open https://www.qemu.org/
-2. try to click "Full-system emulation" with hope that it will link some starting hello world how to do so
-Additional information:
-On https://www.qemu.org/ you can click "support"
-
-Then you can click "documentation"
-
-Then "main documentation section"
-
-Then "system emulation"
-
-Then "introduction"
-
-At this point you have something that sort-of is viable as hello world.
-
-Maybe link https://www.qemu.org/docs/master/system/introduction.html from main page ("Full-system emulation")?
-
-Unless there is a better documentation?
-
-Though maybe someone who will not go through this link maze should not try to use QEMU at all?
diff --git a/results/classifier/118/user-level/326 b/results/classifier/118/user-level/326
deleted file mode 100644
index de81b55e..00000000
--- a/results/classifier/118/user-level/326
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.948
-device: 0.912
-mistranslation: 0.873
-network: 0.661
-semantic: 0.640
-performance: 0.508
-virtual: 0.444
-hypervisor: 0.419
-permissions: 0.375
-boot: 0.301
-architecture: 0.284
-arm: 0.243
-vnc: 0.217
-graphic: 0.202
-register: 0.195
-socket: 0.165
-peripherals: 0.158
-assembly: 0.147
-ppc: 0.144
-debug: 0.131
-i386: 0.101
-files: 0.098
-kernel: 0.091
-risc-v: 0.061
-VMM: 0.033
-TCG: 0.030
-PID: 0.026
-x86: 0.018
-KVM: 0.018
---------------------
-user-level: 0.996
-virtual: 0.946
-permissions: 0.157
-network: 0.027
-device: 0.026
-semantic: 0.024
-hypervisor: 0.017
-files: 0.015
-x86: 0.015
-assembly: 0.006
-kernel: 0.004
-peripherals: 0.003
-performance: 0.003
-i386: 0.003
-arm: 0.003
-debug: 0.003
-boot: 0.002
-VMM: 0.002
-mistranslation: 0.002
-socket: 0.001
-architecture: 0.001
-ppc: 0.001
-PID: 0.001
-TCG: 0.001
-graphic: 0.001
-risc-v: 0.001
-vnc: 0.000
-KVM: 0.000
-register: 0.000
-
-QEMU-user ignores MADV_DONTNEED
diff --git a/results/classifier/118/user-level/570 b/results/classifier/118/user-level/570
deleted file mode 100644
index 2909d392..00000000
--- a/results/classifier/118/user-level/570
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.923
-performance: 0.685
-architecture: 0.675
-device: 0.613
-network: 0.549
-hypervisor: 0.490
-mistranslation: 0.450
-kernel: 0.408
-semantic: 0.383
-peripherals: 0.341
-graphic: 0.331
-TCG: 0.329
-vnc: 0.284
-boot: 0.269
-debug: 0.240
-arm: 0.235
-ppc: 0.216
-register: 0.207
-risc-v: 0.183
-VMM: 0.168
-socket: 0.149
-virtual: 0.132
-permissions: 0.127
-files: 0.116
-PID: 0.113
-KVM: 0.105
-x86: 0.057
-assembly: 0.052
-i386: 0.046
---------------------
-user-level: 0.954
-debug: 0.463
-files: 0.187
-x86: 0.046
-virtual: 0.044
-TCG: 0.037
-kernel: 0.022
-semantic: 0.017
-network: 0.015
-register: 0.009
-KVM: 0.008
-i386: 0.007
-VMM: 0.007
-socket: 0.006
-device: 0.005
-hypervisor: 0.004
-permissions: 0.003
-ppc: 0.003
-performance: 0.003
-boot: 0.003
-vnc: 0.002
-risc-v: 0.002
-assembly: 0.002
-graphic: 0.002
-PID: 0.002
-arm: 0.001
-architecture: 0.001
-peripherals: 0.001
-mistranslation: 0.000
-
-linux-user/sh4/termbits.h:276: warning: "TIOCSER_TEMT" redefined
diff --git a/results/classifier/118/user-level/697 b/results/classifier/118/user-level/697
deleted file mode 100644
index f28277c6..00000000
--- a/results/classifier/118/user-level/697
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.984
-kernel: 0.617
-device: 0.517
-architecture: 0.489
-i386: 0.477
-performance: 0.439
-boot: 0.423
-x86: 0.416
-semantic: 0.378
-debug: 0.321
-ppc: 0.253
-graphic: 0.230
-virtual: 0.189
-register: 0.176
-arm: 0.156
-socket: 0.154
-VMM: 0.147
-TCG: 0.139
-KVM: 0.125
-files: 0.112
-mistranslation: 0.111
-vnc: 0.108
-risc-v: 0.103
-PID: 0.065
-network: 0.057
-hypervisor: 0.049
-permissions: 0.043
-assembly: 0.037
-peripherals: 0.005
---------------------
-user-level: 0.981
-kernel: 0.595
-register: 0.143
-architecture: 0.134
-files: 0.039
-semantic: 0.039
-virtual: 0.037
-PID: 0.031
-x86: 0.017
-boot: 0.008
-i386: 0.007
-debug: 0.005
-performance: 0.005
-assembly: 0.004
-device: 0.003
-VMM: 0.003
-ppc: 0.002
-KVM: 0.002
-graphic: 0.002
-TCG: 0.002
-arm: 0.002
-peripherals: 0.001
-hypervisor: 0.001
-risc-v: 0.001
-socket: 0.001
-vnc: 0.000
-permissions: 0.000
-network: 0.000
-mistranslation: 0.000
-
-linux-user create default CPU type before parsing the ELF header for specific CPU type
diff --git a/results/classifier/118/user-level/817 b/results/classifier/118/user-level/817
deleted file mode 100644
index f5bf6d64..00000000
--- a/results/classifier/118/user-level/817
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.947
-mistranslation: 0.544
-performance: 0.514
-PID: 0.512
-device: 0.478
-semantic: 0.402
-architecture: 0.390
-network: 0.362
-graphic: 0.246
-peripherals: 0.234
-arm: 0.214
-debug: 0.196
-virtual: 0.182
-permissions: 0.163
-TCG: 0.118
-boot: 0.115
-kernel: 0.098
-VMM: 0.097
-i386: 0.088
-ppc: 0.085
-socket: 0.076
-register: 0.067
-files: 0.059
-vnc: 0.048
-KVM: 0.045
-assembly: 0.043
-x86: 0.024
-risc-v: 0.009
-hypervisor: 0.002
---------------------
-user-level: 0.867
-PID: 0.365
-debug: 0.191
-kernel: 0.187
-TCG: 0.090
-performance: 0.050
-x86: 0.020
-assembly: 0.017
-virtual: 0.016
-files: 0.013
-semantic: 0.009
-boot: 0.008
-KVM: 0.003
-hypervisor: 0.002
-device: 0.002
-ppc: 0.002
-VMM: 0.002
-i386: 0.002
-network: 0.002
-graphic: 0.001
-register: 0.001
-risc-v: 0.001
-architecture: 0.001
-permissions: 0.001
-socket: 0.001
-arm: 0.001
-peripherals: 0.000
-vnc: 0.000
-mistranslation: 0.000
-
-linux-user: waitid leaves target siginfo uninitialized when info.si_pid is zero
diff --git a/results/classifier/118/user-level/872 b/results/classifier/118/user-level/872
deleted file mode 100644
index 414279ca..00000000
--- a/results/classifier/118/user-level/872
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.977
-socket: 0.913
-network: 0.728
-architecture: 0.700
-performance: 0.688
-device: 0.618
-kernel: 0.426
-debug: 0.384
-boot: 0.373
-graphic: 0.269
-VMM: 0.265
-PID: 0.259
-TCG: 0.255
-semantic: 0.248
-ppc: 0.205
-vnc: 0.196
-arm: 0.196
-i386: 0.164
-peripherals: 0.155
-virtual: 0.122
-KVM: 0.113
-permissions: 0.105
-mistranslation: 0.099
-files: 0.089
-register: 0.048
-risc-v: 0.038
-x86: 0.038
-hypervisor: 0.030
-assembly: 0.007
---------------------
-network: 0.973
-socket: 0.949
-user-level: 0.907
-debug: 0.171
-kernel: 0.067
-TCG: 0.037
-semantic: 0.025
-permissions: 0.023
-x86: 0.011
-virtual: 0.011
-files: 0.006
-performance: 0.005
-VMM: 0.005
-register: 0.005
-assembly: 0.004
-hypervisor: 0.003
-device: 0.003
-i386: 0.002
-boot: 0.002
-PID: 0.002
-risc-v: 0.002
-KVM: 0.002
-ppc: 0.002
-graphic: 0.001
-vnc: 0.001
-architecture: 0.001
-peripherals: 0.001
-arm: 0.001
-mistranslation: 0.001
-
-linux-user getsockopt(fd, SOL_SOCKET, SO_ERROR) returns host errno to target
diff --git a/results/classifier/118/user-level/885 b/results/classifier/118/user-level/885
deleted file mode 100644
index f9863e3e..00000000
--- a/results/classifier/118/user-level/885
+++ /dev/null
@@ -1,61 +0,0 @@
-user-level: 0.972
-device: 0.883
-network: 0.812
-mistranslation: 0.788
-kernel: 0.748
-performance: 0.710
-debug: 0.589
-peripherals: 0.576
-boot: 0.534
-socket: 0.527
-architecture: 0.461
-graphic: 0.419
-permissions: 0.409
-register: 0.361
-risc-v: 0.302
-files: 0.291
-semantic: 0.262
-VMM: 0.256
-TCG: 0.225
-vnc: 0.203
-virtual: 0.197
-arm: 0.148
-ppc: 0.146
-hypervisor: 0.111
-i386: 0.109
-PID: 0.058
-KVM: 0.041
-x86: 0.022
-assembly: 0.018
---------------------
-user-level: 0.978
-socket: 0.948
-network: 0.889
-permissions: 0.372
-debug: 0.248
-virtual: 0.034
-kernel: 0.031
-risc-v: 0.030
-TCG: 0.022
-x86: 0.015
-files: 0.012
-register: 0.009
-semantic: 0.009
-performance: 0.008
-VMM: 0.006
-PID: 0.004
-device: 0.004
-KVM: 0.003
-assembly: 0.003
-vnc: 0.003
-hypervisor: 0.002
-boot: 0.002
-ppc: 0.002
-i386: 0.002
-architecture: 0.001
-peripherals: 0.001
-graphic: 0.001
-arm: 0.001
-mistranslation: 0.000
-
-linux-user: `getsockopt` on `SO_RCVTIMEO_NEW`/`SO_SNDTIMEO_NEW` writes unexpected `int`
-- 
cgit 1.4.1