summary refs log tree commit diff stats
path: root/results/classifier/108/other/1821
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/182168
-rw-r--r--results/classifier/108/other/1821006128
-rw-r--r--results/classifier/108/other/182113149
-rw-r--r--results/classifier/108/other/1821430254
-rw-r--r--results/classifier/108/other/1821515103
-rw-r--r--results/classifier/108/other/1821595142
-rw-r--r--results/classifier/108/other/182188444
7 files changed, 788 insertions, 0 deletions
diff --git a/results/classifier/108/other/1821 b/results/classifier/108/other/1821
new file mode 100644
index 00000000..bdd95d3e
--- /dev/null
+++ b/results/classifier/108/other/1821
@@ -0,0 +1,68 @@
+debug: 0.900
+graphic: 0.873
+performance: 0.866
+permissions: 0.865
+other: 0.853
+network: 0.849
+vnc: 0.824
+boot: 0.815
+device: 0.814
+KVM: 0.811
+semantic: 0.810
+PID: 0.800
+files: 0.784
+socket: 0.780
+
+snapshot-save very slow in 8.1-rc2
+Description of problem:
+Before commit 813cd61669 ("migration: Use migration_transferred_bytes() to calculate rate_limit") the above script will take about 1.5 seconds to execute, after the commit, 1 minute 30 seconds. More RAM makes it take longer still.
+Steps to reproduce:
+1. Execute the script given as the command line above.
+Additional information:
+Creating the issue here, so it doesn't get lost and is documented.
+
+The following series by @juan.quintela would've avoided the regression, but seems like it never landed: https://lists.nongnu.org/archive/html/qemu-devel/2023-05/msg07971.html
+
+Logs:
+
+Before commit 813cd61669 
+```
+root@pve8a1 /home/febner/repos/qemu/build # time ~/save-snap.sh
+Formatting '/tmp/test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16
+{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 8}, "package": "v8.0.0-967-g3db9c05a90-dirty"}, "capabilities": ["oob"]}}
+VNC server running on ::1:5900
+{"return": {}}
+{"timestamp": {"seconds": 1691572701, "microseconds": 708660}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "save0"}}
+{"timestamp": {"seconds": 1691572701, "microseconds": 708731}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "save0"}}
+{"return": {}}
+{"timestamp": {"seconds": 1691572701, "microseconds": 709239}, "event": "STOP"}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939059}, "event": "RESUME"}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939565}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "save0"}}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939605}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "save0"}}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939638}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "save0"}}
+{"return": {}}
+{"timestamp": {"seconds": 1691572702, "microseconds": 939730}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}}
+{"timestamp": {"seconds": 1691572702, "microseconds": 941746}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "save0"}}
+~/save-snap.sh  1.18s user 0.09s system 85% cpu 1.476 total
+```
+
+After commit 813cd61669
+```
+root@pve8a1 /home/febner/repos/qemu/build # time ~/save-snap.sh
+Formatting '/tmp/test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16
+{"QMP": {"version": {"qemu": {"micro": 92, "minor": 0, "major": 8}, "package": "v8.1.0-rc2-102-ga8fc5165aa"}, "capabilities": ["oob"]}}
+VNC server running on ::1:5900
+{"return": {}}
+{"timestamp": {"seconds": 1691572864, "microseconds": 944026}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "save0"}}
+{"timestamp": {"seconds": 1691572864, "microseconds": 944115}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "save0"}}
+{"return": {}}
+{"timestamp": {"seconds": 1691572864, "microseconds": 944631}, "event": "STOP"}
+{"timestamp": {"seconds": 1691572954, "microseconds": 697523}, "event": "RESUME"}
+{"timestamp": {"seconds": 1691572954, "microseconds": 697962}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "save0"}}
+{"timestamp": {"seconds": 1691572954, "microseconds": 697996}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "save0"}}
+{"timestamp": {"seconds": 1691572954, "microseconds": 698020}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "save0"}}
+{"return": {}}
+{"timestamp": {"seconds": 1691572954, "microseconds": 698089}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}}
+{"timestamp": {"seconds": 1691572954, "microseconds": 701263}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "save0"}}
+~/save-snap.sh  31.81s user 41.69s system 81% cpu 1:30.03 total
+```
diff --git a/results/classifier/108/other/1821006 b/results/classifier/108/other/1821006
new file mode 100644
index 00000000..c7e050ea
--- /dev/null
+++ b/results/classifier/108/other/1821006
@@ -0,0 +1,128 @@
+other: 0.885
+permissions: 0.851
+device: 0.847
+performance: 0.824
+files: 0.790
+debug: 0.789
+boot: 0.789
+PID: 0.774
+network: 0.771
+semantic: 0.763
+socket: 0.744
+graphic: 0.678
+vnc: 0.638
+KVM: 0.604
+
+qemu: Unsupported syscall: 382
+
+I used
+
+qemu-user-static/stable,stable,now 1:2.8+dfsg-6+deb9u5 amd64 [installed]
+
+When I try to build an image of a docker for an arm, an error occurs.
+
+This affects the operation of applications.
+
+
+Dockerfile
+
+ARG ARCH
+FROM ${ARCH}/debian:buster-slim
+
+RUN \
+    printf "Install dependencies...\n" && \
+    apt-get update && \
+    apt-get install -y --no-install-recommends ca-certificates curl
+
+RUN curl https://google.com
+
+EOF
+
+The command that I run
+
+docker build --build-arg ARCH=arm32v7 --file ./Dockerfile -t test .
+
+
+root@unit6:/lib/binfmt.d# cat qemu-arm-static.conf 
+:qemu-arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:F
+
+Here is a related discussion.
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923479
+
+I don't suppose you have a testcase that doesn't require docker?
+
+Syscall 382 is renameat2 for arm. Note that messages from QEMU about unsupported syscalls are often harmless, because typically they only appear for relatively new syscalls which QEMU hasn't implemented yet. The guest code will have a fallback path so it works on older kernels which don't implement the syscall, so a message is printed but the application still runs. So if the guest program is failing then it is quite likely to be for an entirely unrelated reason to the missing syscalls.
+
+
+...that said, we should implement renameat2 provided that the host kernel does. What host kernel version are you using, and what host kernel minimum requirement was the glibc for your guest compiled to require? renameat2 was added in kernel 3.15, so if your host kernel is older than this but your guest glibc assumes it has at least 3.15 then there's no way QEMU can bridge this gap.
+
+
+Yes, you are right the application works correctly. At least the result is expected.
+
+Vesion kernel
+le9i0nx@unit6:~$ uname -a
+Linux unit6 4.9.0-8-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
+Host debian 9
+quest debian 10
+
+quest glib version
+root@ddf2245902b3:/app# apt list | grep libc
+
+WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
+
+libc-bin/now 2.28-7 armhf [installed,local]
+libc6/now 2.28-7 armhf [installed,local]
+
+Examining the build source. I found an option
+MIN_KERNEL_SUPPORTED := 3.2
+
+I also tried to repeat through chroot. a message also appears.
+https://wiki.debian.org/Arm64Qemu I use armhf.
+
+qemu-debootstrap --arch=armhf --keyring /usr/share/keyrings/debian-archive-keyring.gpg --variant=buildd --exclude=debfoster buster  debian-armhf http://ftp.debian.org/debian
+chroot debian-armhf/
+apt-get install -y --no-install-recommends ca-certificates curl
+...
+debconf: falling back to frontend: Readline
+Updating certificates in /etc/ssl/certs...
+qemu: Unsupported syscall: 382
+128 added, 0 removed; done.
+Setting up libgssapi-krb5-2:armhf (1.17-2) ...
+Setting up libcurl4:armhf (7.64.0-1) ...
+Setting up curl (7.64.0-1) ...
+Processing triggers for libc-bin (2.28-8) ...
+Processing triggers for ca-certificates (20190110) ...
+...
+
+
+
+
+
+Upgrading the kernel did not change the situation.
+
+le9i0nx@unit6:~$ uname -a
+Linux unit6 4.19.0-0.bpo.2-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.16-1~bpo9+1 (2019-02-07) x86_64 GNU/Linux
+
+...
+Updating certificates in /etc/ssl/certs...
+qemu: Unsupported syscall: 382
+0 added, 0 removed; done.
+Running hooks in /etc/ca-certificates/update.d...
+...
+
+Thanks for that repro case with qemu-debootstrap and chroot. I can confirm that I can repro this with QEMU version 2.11.1. However with current head of git QEMU this is fixed -- the "unsupported syscall" message is not printed. We added support for the renameat2 syscall in commit 95d0307cc10ca3df87 which is in QEMU version 2.12 and later -- could you try with a newer QEMU version?
+
+
+Unfortunately I was only able to check in 3.1.
+There is no problem with the call.
+
+root@unit6:/mnt/build/chroot# dpkg -l | grep qemu-user-static
+ii  qemu-user-static                                                 1:3.1+dfsg-5                                amd64        QEMU user mode emulation binaries (static version)
+
+
+Hello.
+
+As far as I can tell, this is still an issue with the latest available ubuntu, 18.04.2, which has: version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.15)
+
+Anyone know where I could get a newer version that would be compatible with Ubuntu?
+
diff --git a/results/classifier/108/other/1821131 b/results/classifier/108/other/1821131
new file mode 100644
index 00000000..a9650920
--- /dev/null
+++ b/results/classifier/108/other/1821131
@@ -0,0 +1,49 @@
+device: 0.841
+graphic: 0.819
+vnc: 0.809
+debug: 0.728
+semantic: 0.714
+socket: 0.616
+performance: 0.548
+network: 0.518
+PID: 0.515
+KVM: 0.482
+permissions: 0.395
+boot: 0.389
+other: 0.372
+files: 0.368
+
+VM running under latest Qemu receives 2, 3, 8, and = when sent the keysyms for @, #, *, and + respectively
+
+Git commit hash where bug was reproduced: 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2
+
+A user of my application bVNC reported that when he connects to his VMs running under Qemu, he cannot send @, #, and *. Instead, 2, 3, and 8 appear in the VM respectively. I built the latest Qemu from source, and reproduced the issue.
+
+bVNC converts keycodes or unicode characters that the Android keyboard sends it to corresponding keysyms. For example, it sends keysym 64 for @ rather than sending SHIFT+2.
+
+A debug log of the application sending the keysyms shows metaState == 0, indicating lack of modifier keys. 
+
+When 2 appears in place of @:
+
+03-21 00:11:21.761  8864  8864 I RemoteKeyboard: Sending key. Down: true, key: 64. keysym:64, metaState: 0
+03-21 00:11:21.763  8864  8864 I RemoteKeyboard: Sending key. Down: false, key: 64. keysym:64, metaState: 0
+
+When 3 appears in place of #:
+
+03-21 00:11:08.947  8864  8864 I RemoteKeyboard: Sending key. Down: true, key: 35. keysym:35, metaState: 0
+03-21 00:11:08.950  8864  8864 I RemoteKeyboard: Sending key. Down: false, key: 35. keysym:35, metaState: 0
+
+When 0 appears instead of *:
+
+03-21 00:11:28.586  8864  8864 I RemoteKeyboard: Sending key. Down: true, key: 42. keysym:42, metaState: 0
+03-21 00:11:28.588  8864  8864 I RemoteKeyboard: Sending key. Down: false, key: 42. keysym:42, metaState: 0
+
+When = appears instead of +:
+03-21 01:05:40.021 10061 10061 I RemoteKeyboard: Sending key. Down: true, key: 43. keysym:43, metaState: 0
+03-21 01:05:40.022 10061 10061 I RemoteKeyboard: Sending key. Down: false, key: 43. keysym:43, metaState: 0
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1821430 b/results/classifier/108/other/1821430
new file mode 100644
index 00000000..767cba52
--- /dev/null
+++ b/results/classifier/108/other/1821430
@@ -0,0 +1,254 @@
+other: 0.936
+permissions: 0.927
+performance: 0.916
+debug: 0.900
+network: 0.892
+graphic: 0.884
+semantic: 0.869
+device: 0.865
+socket: 0.852
+PID: 0.849
+files: 0.813
+boot: 0.813
+vnc: 0.789
+KVM: 0.760
+
+qemu-user-arm (4.0.0-rc0) crashes
+
+I'm using qemu-user-arm for crosscompilation needs, usually via a wrapper.
+qemu-user-arm (4.0.0-rc0) crashes with SIGILL on at least 2 instructions:
+
+first case (sadly I don't have more data handy, can reproduce at a later time if needed):
+(gdb) x/i $pc
+=> 0xfffce314:  vseleq.f64      d0, d17, d0
+
+second case (llvm-config):
+qemu cmdline:
+qemu-arm -strace -cpu max -r 5.0.0 -L /home/asavah/kross/build/rpi3/rootfs -E LD_LIBRARY_PATH=/home/asavah/kross/build/rpi3/rootfs/usr/bin:/home/asavah/kross/build/rpi3/rootfs/usr/lib /home/asavah/kross/build/rpi3/rootfs/usr/bin/llvm-config --shared-mode
+
+--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0xf9f89f80} ---
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+
+output from gdb(arm) attached to qemu-user-arm
+Program received signal SIGILL, Illegal instruction.
+0xf9f77f80 in ?? ()
+(gdb) bt
+#0  0xf9f77f80 in ?? ()
+#1  0xfffd796c in ?? ()
+Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+(gdb)  x/i $pc
+=> 0xf9f77f80:  vrintm.f64      d18, d18
+
+
+The very same binaries when run with qemu-user-arm 3.1.0 (both from ubuntu 19.04 package and self built)
+work flawlessly.
+
+This is clearly a regression.
+Please fix before releasing 4.0.0.
+
+Can you provide binaries that reproduce this, please ? Attaching them to the bug is fine.
+
+
+As requested I tarred the failing binaries.
+
+The first one (first case in the original report) is g-ir-compiler from gobjact-introspection, this one has another interesting detail:
+if compiled with -mcpu=cortex-a53 -mfpu=neon-fp-armv8 (the correct flags for raspberry pi 3) it crashes on 4.0.0-rc, but works fine even on 4.0.0 if compiled with -mcpu=cortex-a53 -mfpu=neon-vfpv4 , on 3.1.0 it runs fine with -mfpu=neon-fp-armv8 .
+
+The second one (second case in original report), I'm not sure if its the llvm-config binary itself,
+or the code from libLLVM so I attached the whole thing.
+It only crashes if called with llvm-config --shared-mode , llvm-config --version and llvm-config --ldflags works fine.
+-mfpu=neon-vfpv4 does not help here, crashes anyway, but has worked fine with 3.1.0
+
+
+
+
+asavah <email address hidden> writes:
+
+> Public bug reported:
+>
+> I'm using qemu-user-arm for crosscompilation needs, usually via a wrapper.
+> qemu-user-arm (4.0.0-rc0) crashes with SIGILL on at least 2 instructions:
+>
+> first case (sadly I don't have more data handy, can reproduce at a later time if needed):
+> (gdb) x/i $pc
+> => 0xfffce314:  vseleq.f64      d0, d17, d0
+>
+> second case (llvm-config):
+> qemu cmdline:
+> qemu-arm -strace -cpu max -r 5.0.0 -L
+> /home/asavah/kross/build/rpi3/rootfs -E
+> LD_LIBRARY_PATH=/home/asavah/kross/build/rpi3/rootfs/usr/bin:/home/asavah/kross/build/rpi3/rootfs/usr/lib
+> /home/asavah/kross/build/rpi3/rootfs/usr/bin/llvm-config --shared-mode
+
+I should point out that a rpi3 is a cortex-a53 so -cpu cortex-a53 should
+be all you need to run the binaries. -cpu max will enabled a bunch of
+features you cannot use on an actual pi.
+
+>
+> --- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0xf9f89f80} ---
+> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+>
+> output from gdb(arm) attached to qemu-user-arm
+> Program received signal SIGILL, Illegal instruction.
+> 0xf9f77f80 in ?? ()
+> (gdb) bt
+> #0  0xf9f77f80 in ?? ()
+> #1  0xfffd796c in ?? ()
+> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+> (gdb)  x/i $pc
+> => 0xf9f77f80:  vrintm.f64      d18, d18
+>
+>
+> The very same binaries when run with qemu-user-arm 3.1.0 (both from ubuntu 19.04 package and self built)
+> work flawlessly.
+>
+> This is clearly a regression.
+> Please fix before releasing 4.0.0.
+>
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+
+
+--
+Alex Bennée
+
+
+I should point that -cpu cortex-a53 is not available in qemu-arm,
+I'm building arm 32 bit stuff.
+
+qemu-arm -cpu help
+Available CPUs:
+  arm1026
+  arm1136
+  arm1136-r2
+  arm1176
+  arm11mpcore
+  arm926
+  arm946
+  cortex-a15
+  cortex-a7
+  cortex-a8
+  cortex-a9
+  cortex-m0
+  cortex-m3
+  cortex-m33
+  cortex-m4
+  cortex-r5
+  cortex-r5f
+  max
+  pxa250
+  pxa255
+  pxa260
+  pxa261
+  pxa262
+  pxa270-a0
+  pxa270-a1
+  pxa270
+  pxa270-b0
+  pxa270-b1
+  pxa270-c0
+  pxa270-c5
+  sa1100
+  sa1110
+  ti925t
+  any
+
+
+Yeah, unfortunately we don't support cortex-a53 (or other 64-bit CPUs) in qemu-arm. (We also don't support them as highest-EL-is-AArch32 config in system mode.) Ideally we should fill in that gap, but in practice most people aren't building aarch32 code for ARMv8 -- either they want the back-compat with v7 CPUs or they are using 64-bit -- so it hasn't been very high priority for us.
+
+
+
+
+Peter Maydell <email address hidden> writes:
+
+> Yeah, unfortunately we don't support cortex-a53 (or other 64-bit CPUs)
+> in qemu-arm. (We also don't support them as highest-EL-is-AArch32 config
+> in system mode.) Ideally we should fill in that gap, but in practice
+> most people aren't building aarch32 code for ARMv8 -- either they want
+> the back-compat with v7 CPUs or they are using 64-bit -- so it hasn't
+> been very high priority for us.
+
+I was going to suggest -cpu cortex-a53,aarch64=off but that seems to be
+only for KVM guests.
+
+Is there actually a v8 A profile 32 bit only CPU part?
+
+--
+Alex Bennée
+
+
+On Mon, 25 Mar 2019 at 13:29, Alex Bennée <email address hidden> wrote:
+> I was going to suggest -cpu cortex-a53,aarch64=off but that seems to be
+> only for KVM guests.
+>
+> Is there actually a v8 A profile 32 bit only CPU part?
+
+You can for instance connect up a Cortex-A53 with the
+AA64nAA32 config signals hardwired to 0 ("go into AArch32
+on power-on-reset"), which is functionally the same thing.
+
+thanks
+-- PMM
+
+
+
+Peter Maydell <email address hidden> writes:
+
+> On Mon, 25 Mar 2019 at 13:29, Alex Bennée <email address hidden> wrote:
+>> I was going to suggest -cpu cortex-a53,aarch64=off but that seems to be
+>> only for KVM guests.
+>>
+>> Is there actually a v8 A profile 32 bit only CPU part?
+>
+> You can for instance connect up a Cortex-A53 with the
+> AA64nAA32 config signals hardwired to 0 ("go into AArch32
+> on power-on-reset"), which is functionally the same thing.
+
+So would it be reasonable to have a
+
+#ifndef TARGET_AARCH64
+    { .name = "cortex-a53 (32bit)",         .initfn = aarch32_a53_initfn },
+#endif
+
+and the appropriate init function in cpu.c? That should be all we need right?
+
+>
+> thanks
+> -- PMM
+
+
+--
+Alex Bennée
+
+
+On Mon, 25 Mar 2019 at 15:25, Alex Bennée <email address hidden> wrote:
+> So would it be reasonable to have a
+>
+> #ifndef TARGET_AARCH64
+>     { .name = "cortex-a53 (32bit)",         .initfn = aarch32_a53_initfn },
+> #endif
+>
+> and the appropriate init function in cpu.c? That should be all we need right?
+
+As RTH says, for 4.0 the fix for this regression is simpler.
+For the longer term I think we should look a little more broadly
+at what would be needed for supporting system emulation mode
+CPUs which are nominally aarch64 but configured to boot into
+aarch32 on reset, to see whether the linux-user mode falls
+out as a subset of that. (It may be that it does not, but
+it would definitely be better if we can avoid having to
+duplicate the ID register and feature settings for the
+64-bit CPUs in both cpu64.c and cpu.c.)
+
+thanks
+-- PMM
+
+
+I think this bug should be fixed by commit c8877d0f2f662bf01346a (which has just landed in git master and should be in rc1 when we tag it, probably later today). Please let us know if it hasn't fixed all the regressions for you.
+
+
+qemu-user-arm 4.0.0-rc1 no longer produces any crashes for me.
+Huge thanks.
+
+
diff --git a/results/classifier/108/other/1821515 b/results/classifier/108/other/1821515
new file mode 100644
index 00000000..2f43ec3f
--- /dev/null
+++ b/results/classifier/108/other/1821515
@@ -0,0 +1,103 @@
+permissions: 0.836
+graphic: 0.800
+semantic: 0.746
+debug: 0.716
+other: 0.658
+device: 0.642
+PID: 0.616
+performance: 0.566
+files: 0.494
+boot: 0.441
+network: 0.370
+socket: 0.369
+vnc: 0.364
+KVM: 0.357
+
+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/108/other/1821595 b/results/classifier/108/other/1821595
new file mode 100644
index 00000000..4006ff40
--- /dev/null
+++ b/results/classifier/108/other/1821595
@@ -0,0 +1,142 @@
+permissions: 0.907
+other: 0.871
+semantic: 0.844
+device: 0.842
+debug: 0.819
+graphic: 0.804
+performance: 0.797
+PID: 0.755
+vnc: 0.755
+files: 0.740
+socket: 0.735
+boot: 0.698
+KVM: 0.684
+network: 0.644
+
+Failed to emulate MMIO access with EmulatorReturnStatus: 2
+
+I have compiled qemu with enable-whpx parameter for Hyper-V Platform API in Mingw64 . When I tried run with Windows 7 iso file I have faced issue with the following problem: 
+qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2
+qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor
+
+
+configuration directives:
+
+../configure --target-list=x86_64-softmmu,i386-softmmu --enable-lzo\
+ --enable-bzip2 --enable-tools --enable-sdl --enable-gtk --enable-hax\
+ --enable-vdi --enable-qcow1 --enable-whpx --disable-capstone\
+ --disable-werror --disable-stack-protector --prefix="../../QEMU-bin"
+
+
+Qemu command line:
+qemu-system-x86_64.exe -m 1024 -cdrom "C:\Users\vmcs\Documents\en_windows_7_home_premium_with_sp1_x86_dvd_u_676701.iso" -display sdl -machine q35 -accel whpx
+
+Hi,
+
+Having a similar issue here, running "QEMU emulator version 4.2.91 (v5.0.0-rc1-31-g146aa0f104-dirty)"
+
+Configuration / build command line,
+./configure --cross-prefix=x86_64-w64-mingw32- --target-list=x86_64-softmmu --enable-whpx --enable-fdt --enable-gtk --enable-vnc --disable-pie --enable-opengl && make -j16 && make -j16 installer
+
+And the QEMU command line,
+qemu-system-x86_64.exe \
+    -m 2G \
+    -machine q35 \
+    -cpu Penryn \
+    -accel whpx \
+    -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" \
+    -smbios type=2 \
+    -drive if=pflash,format=raw,readonly,file="./firmware/OVMF_CODE.fd"\
+    -drive if=pflash,format=raw,file="./firmware/OVMF_VARS-1024x768.fd" \
+    -usb -device usb-kbd -device usb-mouse \
+    -netdev user,id=net0 \
+    -device e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 \
+    -device ich9-ahci,id=sata \
+    -drive id=ESP,if=none,format=qcow2,file=ESP.qcow2 \
+    -device ide-hd,bus=sata.2,drive=ESP \
+    -drive id=InstallMedia,format=raw,if=none,file=BaseSystem.img \
+    -device ide-hd,bus=sata.3,drive=InstallMedia \
+    -drive id=SystemDisk,if=none,file=MyDisk.qcow2 \
+    -device ide-hd,bus=sata.4,drive=SystemDisk \
+
+
+If I remove (only), -accel whpx \ => Then it all runs, just very slowly ;-).
+
+Any suggestions, things to try?
+
+Thanks!
+
+FYI, I was curious if this was a Ryzen issue or not (which I am running), so I tried another machine - here are the two combos I tried,
+1) Ryzen 5 2600X, Windows 19041.172
+2) Core i5-6600K, Windows 18363.720
+
+Same issue on both.
+
+Thanks!
+
+Which OS do you try with qemu? IIRC Windows 10 should work well with WHPX. Also,this issue is qemu depended that they don't handle specific MMIO instruction/exit.
+
+Sorry for the typo. I should have mentioned that this issue is WHPX related. I have created an issue in WHPX Github page about it.
+
+As far as I can tell QEMU just hands this off to the whpx emulation sub-system:
+
+  https://docs.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatortryemulation
+
+Basically what is happening is the guest has tried to access I/O space and trapped back to QEMU which then passes the instruction back to the whpx support library to decode and emulate.
+
+Hi,
+
+I tried backing up ... nothing but startup and UEFI (i.e. no OS, just get to the EFI Shell). Can't even get there ... does that make sense?
+
+Thanks!
+
+I think WHPX can't some MMIO requests for EFI.
+
+Folks seem to think this is the fix,
+https://stackoverflow.com/questions/55197032/android-emulator-whpx-failed-to-emulate-mmio-access-exit-code-3
+
+But it's not working for me ... does it help you?
+
+Thanks!
+
+And here,
+https://www.reddit.com/r/androiddev/comments/c7u6h2/android_virtual_device_on_ryzen/
+
+
+I don't think QEMU can do anything to fix this - you need to build against a new library.
+
+Sorry, not quite following your comment - but it's likely me :-(.
+
+I assume you mean QEMU - but build against what upstream library? I ask because for QEMU to build, only the three header files from Windows are copied over, and then it calls / uses the dll's (libraries) in Windows itself ... right? FYI, I'm running Windows 19041.172, to try to make sure I do have the latest related to whpx.
+
+Thanks!
+
+Hi,
+
+I built against the latest library I could (Windows Insider Preview, SDK) - same failure.
+
+Thoughts?
+
+Thanks!
+
+Should say - I rebuilt (today). Still no joy.
+
+Hi. I didnt build Qemu but I downloaded the last version 5.1.0 from https://qemu.weilnetz.de/w64/ and the error "Failed to emulate MMIO access with EmulatorReturnStatus: 2" happens when I use -drive if=pflash or -pflash with -accel whpx.
+
+"qemu-system-x86_64.exe -pflash d:\macWIN\OVMF_CODE.fd -accel whpx
+Windows Hypervisor Platform accelerator is operational
+qemu-system-x86_64.exe: WHPX: Failed to emulate MMIO access with EmulatorReturnStatus: 2
+qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor"
+
+
+If I remove pflash and change to -bios "ovmf" the machine works.
+qemu-system-x86_64.exe -bios d:\macWIN\OVMF_CODE.fd -accel whpx
+
+If I maintain pflash but remove -accel whpx the machine works too.
+qemu-system-x86_64.exe -pflash d:\macWIN\OVMF_CODE.fd
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1821884 b/results/classifier/108/other/1821884
new file mode 100644
index 00000000..c525a5f8
--- /dev/null
+++ b/results/classifier/108/other/1821884
@@ -0,0 +1,44 @@
+other: 0.889
+device: 0.847
+files: 0.787
+socket: 0.771
+performance: 0.749
+semantic: 0.735
+PID: 0.713
+permissions: 0.712
+network: 0.679
+graphic: 0.674
+boot: 0.615
+vnc: 0.609
+KVM: 0.464
+debug: 0.356
+
+Extend uefi-test-tools to report SMBIOS location
+
+UEFI helper app exposes the pointer to RSDP ACPI table that firmware allocates in guest's RAM
+but it doesn't do so for SMBIOS tables. Hence bios table test would skip testing SMBIOS tables
+to workaround shortcoming. This bug is a request to expose two new entry point fields (one for SMBIOS 2 and another for SMBIOS 3) so test could check SMBIOS tables when guest is started a with  UEFI firmware.
+
+Discussion on qemu-devel:
+[Qemu-devel] [PATCH for 4.1 v2 09/13] tests: acpi: ignore SMBIOS tests when UEFI firmware is used
+http://mid<email address hidden>
+https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07037.html
+
+I'll work on this once Igor's above series is merged (which in turn depends on my series
+[Qemu-devel] [PATCH for-4.1 v3 00/12] bundle edk2 platform firmware with QEMU
+http://<email address hidden>
+https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06148.html
+)
+
+Posted
+[PATCH 0/2] tests/uefi-test-tools: report the SMBIOS entry point structures
+http://<email address hidden>
+
+
+Posted
+[PULL 0/2] tests/uefi-test-tools: report the SMBIOS entry point structures
+http://<email address hidden>
+
+
+Fixed in commit range 8482ff2eb3bb..24496b8d27d9.
+