summary refs log tree commit diff stats
path: root/results/classifier/118/user-level-risc-v
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/118/user-level-risc-v')
-rw-r--r--results/classifier/118/user-level-risc-v/1366836135
-rw-r--r--results/classifier/118/user-level-risc-v/160689
-rw-r--r--results/classifier/118/user-level-risc-v/1829148
3 files changed, 372 insertions, 0 deletions
diff --git a/results/classifier/118/user-level-risc-v/1366836 b/results/classifier/118/user-level-risc-v/1366836
new file mode 100644
index 000000000..c45929b39
--- /dev/null
+++ b/results/classifier/118/user-level-risc-v/1366836
@@ -0,0 +1,135 @@
+user-level: 0.911
+permissions: 0.888
+debug: 0.866
+semantic: 0.861
+mistranslation: 0.849
+TCG: 0.844
+register: 0.836
+VMM: 0.829
+virtual: 0.823
+KVM: 0.818
+boot: 0.817
+risc-v: 0.813
+architecture: 0.812
+device: 0.812
+PID: 0.806
+arm: 0.805
+peripherals: 0.804
+assembly: 0.801
+graphic: 0.794
+performance: 0.789
+hypervisor: 0.786
+kernel: 0.779
+ppc: 0.775
+vnc: 0.770
+files: 0.747
+socket: 0.718
+x86: 0.684
+network: 0.604
+i386: 0.509
+--------------------
+x86: 0.975
+register: 0.916
+KVM: 0.861
+kernel: 0.771
+debug: 0.696
+boot: 0.691
+hypervisor: 0.590
+virtual: 0.164
+PID: 0.044
+files: 0.042
+assembly: 0.040
+user-level: 0.030
+TCG: 0.012
+performance: 0.011
+architecture: 0.005
+socket: 0.005
+device: 0.005
+risc-v: 0.004
+semantic: 0.003
+i386: 0.002
+graphic: 0.001
+peripherals: 0.001
+VMM: 0.001
+permissions: 0.001
+network: 0.001
+vnc: 0.000
+mistranslation: 0.000
+ppc: 0.000
+arm: 0.000
+
+Core2Duo and KVM may not boot Win8 properly on 3.x kernels
+
+When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel
+3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error.
+When I dump the CPU registers via "info registers", nothing changes, that means
+the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0.
+
+But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on
+the host side it works on the Core2Duo. Also the system above but just with an
+i3 or i5 CPU it works fine.
+
+I already disabled networking and USB for the guest and changed the graphics
+card - no effect. I assume that some mean bits and bytes have to be set up
+properly to get the thing running.
+
+Seems to be related to a kvm/progressor incompatibility.
+
+Here the register dump of the stalled Win8
+QEMU 2.1.0 monitor - type 'help' for more information
+(qemu) info registers
+EAX=3e2009e3 EBX=3e2009e3 ECX=80000000 EDX=80000000
+ESI=3e2009e3 EDI=8220c108 EBP=81f9b33c ESP=81f9b2f0
+EIP=80c98d83 EFL=00010282 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0023 00000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
+CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
+SS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
+DS =0023 00000000 ffffffff 00c0f300 DPL=3 DS   [-WA]
+FS =0030 80e65000 00004280 00409300 DPL=0 DS   [-WA]
+GS =0000 00000000 ffffffff 00000000
+LDT=0000 00000000 ffffffff 00000000
+TR =0028 80353000 000020ab 00008b00 DPL=0 TSS32-busy
+GDT=     80a37000 000003ff
+IDT=     80a37400 000007ff
+CR0=8001003b CR2=8b206090 CR3=00185000 CR4=000406e9
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000500000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000800
+FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
+FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
+FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
+FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
+FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
+XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
+XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
+XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
+XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
+
+
+I found a new trace - using the ipipe patch that I have, there seems to be an issue in the 3.4 kernels, but as it looks also in the 3.10 kernels.
+http://www.xenomai.org/pipermail/xenomai/2013-March/027865.html
+
+Is there an update on that already existing? It was not completely clear if this issue is related either to KVM or to the ipipe patch.
+
+Thanks.
+
+attached the trace.dat (tar-gzipped) as recommended. Hope this helps finding the issue. The file should capture the following:
+- windows 8 with screen that shows that the last boot attempts failed
+- issued system_reset on qemu commandline
+- startup of windows 8 that stalls
+
+
+sorry for the corrupt file, this one should be fine now.
+
+Confirmed - the current kvm.git without any ipipe patch also causes the issue. Trace File attached.
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+Please close it, it's solved with this patch commit to kvm / kernel:
+Was found and fixed with great support of Paolo Bonzini
+
+From: Paolo Bonzini
+Date: Thu, 12 Feb 2015 17:04:47 +0100
+Subject: KVM: emulate: fix CMPXCHG8B on 32-bit hosts
+
+
diff --git a/results/classifier/118/user-level-risc-v/1606 b/results/classifier/118/user-level-risc-v/1606
new file mode 100644
index 000000000..605d94305
--- /dev/null
+++ b/results/classifier/118/user-level-risc-v/1606
@@ -0,0 +1,89 @@
+user-level: 0.995
+risc-v: 0.953
+ppc: 0.826
+graphic: 0.812
+VMM: 0.790
+KVM: 0.777
+device: 0.740
+vnc: 0.739
+performance: 0.728
+permissions: 0.728
+x86: 0.676
+PID: 0.623
+semantic: 0.602
+i386: 0.565
+architecture: 0.559
+virtual: 0.534
+socket: 0.527
+network: 0.516
+hypervisor: 0.479
+TCG: 0.464
+kernel: 0.424
+register: 0.402
+debug: 0.391
+files: 0.355
+peripherals: 0.344
+assembly: 0.316
+boot: 0.313
+arm: 0.294
+mistranslation: 0.266
+--------------------
+user-level: 0.985
+debug: 0.529
+x86: 0.209
+kernel: 0.158
+performance: 0.073
+files: 0.040
+i386: 0.034
+risc-v: 0.031
+virtual: 0.021
+ppc: 0.020
+TCG: 0.018
+hypervisor: 0.015
+PID: 0.013
+arm: 0.011
+device: 0.011
+register: 0.011
+assembly: 0.011
+network: 0.009
+VMM: 0.006
+semantic: 0.006
+peripherals: 0.006
+boot: 0.005
+architecture: 0.004
+socket: 0.003
+KVM: 0.003
+graphic: 0.002
+vnc: 0.002
+permissions: 0.002
+mistranslation: 0.001
+
+riscv: fence.i is not functional
+Description of problem:
+The attached user-level test is designed to do the following (in iteration):
+
+  - Thread P0 on CPU0 changes some text/code, while
+
+  - Thread P1 on CPU1 checks/reads the code, fence.i, then executes the same code.
+
+Results (in stdout) indicates that CPU1 has read the new code (1:x5=a009) but executed the old one (1:x7=1) (against the specification).
+Steps to reproduce:
+1. echo 2 > /proc/sys/vm/nr_hugepages
+2. ./CoRF+fence.i
+Additional information:
+Example output:
+```[CoRF+fence.i.c](/uploads/c150ca0910783cc4bfc3886789b64c28/CoRF+fence.i.c)
+Test CoRF+fence.i Allowed
+Histogram (4 states)
+25784  :>1:x5=0xa009; 1:x7=2;
+24207  *>1:x5=0xa009; 1:x7=1;   <--  THIS LINE
+8      :>1:x5=0xa019; 1:x7=1;
+1      :>1:x5=0xa019; 1:x7=2;
+Ok
+Witnesses
+Positive: 24207 Negative 25793
+Condition exists (1:x5=0xa009 /\ 1:x7=1) is  validated
+Observation CoRF+fence.i Sometimes 24207 25793
+Time CoRF+fence.i 0.85
+Hash=
+```
diff --git a/results/classifier/118/user-level-risc-v/1829 b/results/classifier/118/user-level-risc-v/1829
new file mode 100644
index 000000000..e8eaf6f9c
--- /dev/null
+++ b/results/classifier/118/user-level-risc-v/1829
@@ -0,0 +1,148 @@
+risc-v: 0.971
+user-level: 0.890
+vnc: 0.879
+KVM: 0.851
+debug: 0.839
+ppc: 0.834
+TCG: 0.831
+permissions: 0.831
+performance: 0.826
+network: 0.816
+architecture: 0.813
+hypervisor: 0.812
+register: 0.805
+graphic: 0.801
+VMM: 0.800
+mistranslation: 0.800
+virtual: 0.798
+assembly: 0.790
+x86: 0.789
+socket: 0.778
+peripherals: 0.776
+semantic: 0.770
+arm: 0.769
+kernel: 0.758
+i386: 0.754
+device: 0.745
+PID: 0.738
+files: 0.704
+boot: 0.642
+--------------------
+virtual: 0.965
+x86: 0.959
+TCG: 0.959
+device: 0.856
+PID: 0.805
+risc-v: 0.730
+files: 0.441
+VMM: 0.425
+vnc: 0.377
+debug: 0.147
+ppc: 0.079
+register: 0.050
+socket: 0.031
+KVM: 0.029
+graphic: 0.029
+kernel: 0.022
+assembly: 0.022
+network: 0.012
+boot: 0.011
+architecture: 0.011
+user-level: 0.010
+permissions: 0.010
+performance: 0.010
+semantic: 0.010
+mistranslation: 0.009
+hypervisor: 0.006
+i386: 0.006
+peripherals: 0.005
+arm: 0.001
+
+DoS via assert failure by guest user
+Description of problem:
+As root in guest VM user can execute special script, which crashes the whole VM with error
+
+```plaintext
+hw/display/qxl.c:1594 inside of function void qxl_set_mode(PCIQXLDevice *, unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0` failed
+```
+Steps to reproduce:
+1. This bug can be reproduced with:
+
+   ```bash
+   cat << EOF | ./build/qemu-system-x86_64 -vga qxl -m 2048 -nodefaults -qtest stdio
+   outl 0xcf8 0x8000101c
+   outl 0xcfc 0xc000
+   outl 0xcf8 0x80001001
+   outl 0xcfc 0x01000000
+   outl 0xc006 0x00
+   EOF
+   ```
+2. Also, we can execute this python3 script inside guest VM as root (to invoke VM use command: **_qemu-system-x86_64 -vga qxl -hda debian.img -m 2048 -nodefaults_**):
+
+   ```python
+   import os
+   f = os.open("/dev/port", os.O_RDWR|os.O_NDELAY)
+   l = os.lseek(f, 0xcf8, 0)
+   os.write(f, b'\x80\x00\x10\x1c')
+   l = os.lseek(f, 0xcfc, 0)
+   os.write(f, b'\xc0\x00')
+   l = os.lseek(f, 0xcf8, 0)
+   os.write(f, b'\x80\x00\x10\x01')
+   l = os.lseek(f, 0xcfc, 0)
+   os.write(f, b'\x01\x00\x00\x00')
+   l = os.lseek(f, 0xc006, 0)
+   os.write(f, b'\x00')
+   ```
+
+   This script causes VM to crash.
+
+   [PoC_qxl-vga_crash.mkv](/uploads/7ee262c20dca69aa9417812f6a93a532/PoC_qxl-vga_crash.mkv)
+Additional information:
+This issue was found by fuzzing. Here is an auto-generated C source code for a test case that will reproduce the bug.
+
+```plaintext
+/*
+ * Autogenerated Fuzzer Test Case
+ *
+ * Copyright (c) 2023 Artem Nasonov <anasonov@astralinux.ru>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+
+#include "libqtest.h"
+
+/*
+ * cat << EOF | qemu-system-x86_64 -vga qxl -hda \
+ * ~/Downloads/virtualdebian.img -m 2048 -nodefaults -qtest stdio
+ * outl 0xcf8 0x8000101c
+ * outl 0xcfc 0xc000
+ * outl 0xcf8 0x80001001
+ * outl 0xcfc 0x01000000
+ * outl 0xc006 0x00
+ * EOF
+*/
+static void test_qxl_set_mode(void)
+{
+QTestState *s = qtest_init("-vga qxl -m 2048 -nodefaults");
+qtest_outl(s, 0xcf8, 0x8000101c);
+qtest_outl(s, 0xcfc, 0xc000);
+qtest_outl(s, 0xcf8, 0x80001001);
+qtest_outl(s, 0xcfc, 0x01000000);
+qtest_outl(s, 0xc006, 0x00);
+qtest_quit(s);
+}int main(int argc, char **argv)
+{
+    const char *arch = qtest_get_arch();
+
+    g_test_init(&argc, &argv, NULL);
+
+   if (strcmp(arch, "x86_64") == 0) {
+        qtest_add_func("fuzz/test_qxl_set_mode",test_qxl_set_mode);
+   }
+
+   return g_test_run();
+}
+```