summary refs log tree commit diff stats
path: root/results/classifier/118/user-level-risc-v
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-07-03 19:39:53 +0200
committerChristian Krinitsin <mail@krinitsin.com>2025-07-03 19:39:53 +0200
commitdee4dcba78baf712cab403d47d9db319ab7f95d6 (patch)
tree418478faf06786701a56268672f73d6b0b4eb239 /results/classifier/118/user-level-risc-v
parent4d9e26c0333abd39bdbd039dcdb30ed429c475ba (diff)
downloademulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.tar.gz
emulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.zip
restructure results
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, 0 insertions, 372 deletions
diff --git a/results/classifier/118/user-level-risc-v/1366836 b/results/classifier/118/user-level-risc-v/1366836
deleted file mode 100644
index c45929b3..00000000
--- a/results/classifier/118/user-level-risc-v/1366836
+++ /dev/null
@@ -1,135 +0,0 @@
-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
deleted file mode 100644
index 605d9430..00000000
--- a/results/classifier/118/user-level-risc-v/1606
+++ /dev/null
@@ -1,89 +0,0 @@
-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
deleted file mode 100644
index e8eaf6f9..00000000
--- a/results/classifier/118/user-level-risc-v/1829
+++ /dev/null
@@ -1,148 +0,0 @@
-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();
-}
-```