7 files changed, 288 insertions, 0 deletions
diff --git a/results/classifier/108/other/238 b/results/classifier/108/other/238
new file mode 100644
index 000000000..8369742d5
--- /dev/null
+++ b/results/classifier/108/other/238
@@ -0,0 +1,16 @@
+network: 0.708
+device: 0.537
+graphic: 0.486
+performance: 0.456
+debug: 0.326
+vnc: 0.214
+semantic: 0.208
+boot: 0.192
+PID: 0.141
+permissions: 0.118
+other: 0.049
+files: 0.046
+KVM: 0.044
+socket: 0.031
+
+capstone link failure building linux-user static
diff --git a/results/classifier/108/other/2380 b/results/classifier/108/other/2380
new file mode 100644
index 000000000..3814e8264
--- /dev/null
+++ b/results/classifier/108/other/2380
@@ -0,0 +1,120 @@
+other: 0.858
+permissions: 0.829
+device: 0.828
+KVM: 0.821
+debug: 0.800
+vnc: 0.792
+performance: 0.792
+semantic: 0.787
+boot: 0.779
+graphic: 0.778
+files: 0.753
+network: 0.752
+socket: 0.741
+PID: 0.709
+
+Crash on x86_64 vm launch
+Description of problem:
+When I started using QEMU for x86 OS programming about a year or 2 ago it ran fine until about a year ago where it just does not launch for more than a few seconds, it always crashes with no output at all, even when running with debug options enabled, it still outputs normal values before just crashing or exiting, this happens when running with an OS image or not, I have tried everything possible (wiping the whole system of anything including "qemu" including the registry, disabling all AV including windows defender, using SFC and DISM to repair corrupt files, installing the oldest versions of qemu up to the newest, running the program in different compatibility modes, running as admin, changing install directories, disabling overclocking, and many more) the only way it runs is if I use a VM to run qemu or reinstall windows, I am not reinstalling windows and im not running a vm to run another vm, my OS is very stable apart from this one program, I need to use QEMU as it is very important for my OS builds as it allows me to automate many things.
+Steps to reproduce:
+1. launch qemu-system-x86_64
+
+unable to reproduce on other clean OS installs
+Additional information:
+upon clean building QEMU from latest build using MSYS2 and running GDB here is the output
+
+```
+(gdb) run
+Starting program: C:\qemu\build\qemu-system-x86_64.exe
+[New Thread 22292.0x250c]
+[New Thread 22292.0x2004]
+[New Thread 22292.0x1d2c]
+[New Thread 22292.0x5614]
+[New Thread 22292.0x5b3c]
+[New Thread 22292.0x5ae8]
+[New Thread 22292.0x2d04]
+[New Thread 22292.0x5588]
+[New Thread 22292.0x3ce8]
+gdb: unknown target exception 0xc0000409 at 0x7ffac8f83e74
+
+Thread 8 received signal ?, Unknown signal.
+[Switching to Thread 22292.0x2d04]
+0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll
+
+```
+
+the error code leads to STATUS_STACK_BUFFER_OVERRUN
+
+upon back tracing this it leads to this output
+
+```
+(gdb) bt
+#0  0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll
+#1  0x00007ffac8f82c04 in msvcrt!longjmp () from C:\Windows\System32\msvcrt.dll
+#2  0x00007ff670af2b8e in advance_pc (env=0x34d3c60, s=0x4beff8d0, num_bytes=4)
+    at ../target/i386/tcg/translate.c:2131
+#3  0x00007ff670af2d33 in x86_ldl_code (env=0x34d3c60, s=0x4beff8d0)
+    at ../target/i386/tcg/translate.c:2169
+#4  0x00007ff670af3939 in insn_get (env=0x34d3c60, s=0x4beff8d0, ot=MO_32)
+    at ../target/i386/tcg/translate.c:2454
+#5  0x00007ff670b0c4ca in disas_insn (s=0x4beff8d0, cpu=0x34d1450)
+    at ../target/i386/tcg/translate.c:5148
+#6  0x00007ff670b1253f in i386_tr_translate_insn (dcbase=0x4beff8d0, cpu=0x34d1450)
+    at ../target/i386/tcg/translate.c:7023
+#7  0x00007ff670ba30b2 in translator_loop (cpu=0x34d1450, tb=0x3b3a280, max_insns=0x4beffba4,
+    pc=954352, host_pc=0x43de8ff0, ops=0x7ff671a9b480 <i386_tr_ops>, db=0x4beff8d0)
+    at ../accel/tcg/translator.c:164
+#8  0x00007ff670b127ef in gen_intermediate_code (cpu=0x34d1450, tb=0x3b3a280,
+    max_insns=0x4beffba4, pc=954352, host_pc=0x43de8ff0) at ../target/i386/tcg/translate.c:7099
+#9  0x00007ff670ba1abd in setjmp_gen_code (env=0x34d3c60, tb=0x3b3a280, pc=954352,
+    host_pc=0x43de8ff0, max_insns=0x4beffba4, ti=0x4beffbc0) at ../accel/tcg/translate-all.c:278
+#10 0x00007ff670ba1de3 in tb_gen_code (cpu=0x34d1450, pc=954352, cs_base=0, flags=176,
+    cflags=-16646144) at ../accel/tcg/translate-all.c:358
+#11 0x00007ff670b96508 in cpu_exec_loop (cpu=0x34d1450, sc=0x4beffd60)
+    at ../accel/tcg/cpu-exec.c:989
+#12 0x00007ff670b96689 in cpu_exec_setjmp (cpu=0x34d1450, sc=0x4beffd60)
+    at ../accel/tcg/cpu-exec.c:1035
+#13 0x00007ff670b96728 in cpu_exec (cpu=0x34d1450) at ../accel/tcg/cpu-exec.c:1061
+--Type <RET> for more, q to quit, c to continue without paging--
+#14 0x00007ff670bc1fb7 in tcg_cpu_exec (cpu=0x34d1450) at ../accel/tcg/tcg-accel-ops.c:76
+#15 0x00007ff670bc28a2 in mttcg_cpu_thread_fn (arg=0x34d1450)
+    at ../accel/tcg/tcg-accel-ops-mttcg.c:95
+#16 0x00007ff670de8587 in win32_start_routine (arg=0x3537c60) at ../util/qemu-thread-win32.c:411
+#17 0x00007ffac8f8e634 in msvcrt!_beginthreadex () from C:\Windows\System32\msvcrt.dll
+#18 0x00007ffac8f8e70c in msvcrt!_endthreadex () from C:\Windows\System32\msvcrt.dll
+#19 0x00007ffac901257d in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll
+#20 0x00007ffacae0aa48 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
+#21 0x0000000000000000 in ?? ()
+
+```
+
+if I am reading the output correctly   qemu/target/i386/tcg/translate.c:2131     is the last file (in source) it accesses before moving to msvcrt.dll,  inside of the advance_pc function
+
+
+this is the function
+
+```
+static uint64_t advance_pc(CPUX86State *env, DisasContext *s, int num_bytes) {
+    uint64_t pc = s->pc;
+
+    if (s->base.num_insns > 1 && !is_same_page(&s->base, s->pc + num_bytes - 1)) {
+        siglongjmp(s->jmpbuf, 2);   <--------------------------------------------------   The line is the last function call
+    }
+
+    s->pc += num_bytes;
+
+    if (unlikely(cur_insn_len(s) > X86_MAX_INSN_LENGTH)) {
+        if (((s->pc - 1) ^ (pc - 1)) & TARGET_PAGE_MASK) {
+            volatile uint8_t unused = cpu_ldub_code(env, (s->pc - 1) & TARGET_PAGE_MASK);
+            (void)unused;
+        }
+        siglongjmp(s->jmpbuf, 1);
+    }
+
+    return pc;
+}
+```
+
+if I had to guess this problem could be caused by some windows configuration, something to do with memory, or maybe some corrupt files, but I am unsure
+
+I am not a c programmer so I don't know much about the code but I can debug more if needed
diff --git a/results/classifier/108/other/2381 b/results/classifier/108/other/2381
new file mode 100644
index 000000000..dfed821f2
--- /dev/null
+++ b/results/classifier/108/other/2381
@@ -0,0 +1,18 @@
+device: 0.876
+graphic: 0.776
+other: 0.626
+semantic: 0.505
+boot: 0.481
+network: 0.474
+socket: 0.389
+performance: 0.353
+permissions: 0.315
+vnc: 0.233
+PID: 0.225
+debug: 0.205
+files: 0.101
+KVM: 0.028
+
+Modern x86 TSC features under TCG
+Additional information:
+I may be able to find a volunteer to implement this. If this feature does not appear to be a good first task, please let me know.
diff --git a/results/classifier/108/other/2383 b/results/classifier/108/other/2383
new file mode 100644
index 000000000..b0d9d96bd
--- /dev/null
+++ b/results/classifier/108/other/2383
@@ -0,0 +1,18 @@
+device: 0.726
+network: 0.483
+performance: 0.470
+boot: 0.340
+graphic: 0.277
+socket: 0.270
+other: 0.237
+semantic: 0.178
+permissions: 0.176
+files: 0.170
+PID: 0.117
+vnc: 0.093
+KVM: 0.077
+debug: 0.049
+
+Support SMRR for x86 emulation
+Additional information:
+
diff --git a/results/classifier/108/other/2386 b/results/classifier/108/other/2386
new file mode 100644
index 000000000..d9b85e813
--- /dev/null
+++ b/results/classifier/108/other/2386
@@ -0,0 +1,58 @@
+graphic: 0.899
+performance: 0.895
+files: 0.834
+socket: 0.812
+device: 0.808
+vnc: 0.803
+PID: 0.762
+network: 0.759
+permissions: 0.697
+debug: 0.684
+semantic: 0.624
+other: 0.616
+boot: 0.615
+KVM: 0.565
+
+RISCV - Incorrect behaviour of the SLL instruction
+Description of problem:
+`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view):
+
+> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register
+rs1 by the shift amount held in the lower 5 bits of register rs2.
+
+This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left:
+
+```python
+correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1)
+incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1)
+```
+Steps to reproduce:
+1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf`
+
+```c
+#include <stdint.h>
+#include <stdio.h>
+
+int main() {
+  uint64_t a = 0x69C99AB9B9401024;
+  uint64_t b = 0xDB4D6868655C3585;
+  uint64_t c;
+
+  asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a));
+
+  printf("s8      : %lx\n", c);
+  printf("expected: %lx\n", 0xb4d6868655c35850);
+
+  return 0;
+}
+```
+
+2. Run qemu: `./qemu-riscv64 ./repro.elf`
+3. You will see the output and what the result of the computation should really be:
+
+```
+s8      : 55c3585000000000
+expected: b4d6868655c35850
+```
+Additional information:
+
diff --git a/results/classifier/108/other/2387 b/results/classifier/108/other/2387
new file mode 100644
index 000000000..4cf1067a1
--- /dev/null
+++ b/results/classifier/108/other/2387
@@ -0,0 +1,26 @@
+graphic: 0.907
+device: 0.847
+boot: 0.794
+semantic: 0.658
+performance: 0.650
+socket: 0.562
+files: 0.543
+debug: 0.479
+vnc: 0.446
+permissions: 0.399
+other: 0.395
+PID: 0.346
+network: 0.239
+KVM: 0.008
+
+Segmentation fault on booting from ISO when using GTK display with OpenGL enabled
+Description of problem:
+When trying to boot from the ISO mounted in the `-cdrom` argument, using a GTK display with OpenGL enabled gives a segmentation fault error. If using SDL instead, the whole application kinda freezes most of the times. I managed to get it working once, but I don't know how or why, seemed completely random. After installing it, I can boot from the disk normally with no errors.
+Steps to reproduce:
+1. Install QEMU for MSYS2 / UCRT64 as described [here](https://www.qemu.org/download/#windows)
+2. Download ISO from EndeavourOS website
+3. Run `qemu-img create -f qcow2 EndeavourOS.qcow2 64G` to create a disk file
+4. Run the script as described above in a `.sh` file
+5. See error
+Additional information:
+I have multiple VMs, included but not limited to Manjaro, Pop!\_OS and Debian, none of them gives this specific error. I also usually avoid SDL because I had multiple issues with the application window completely freezing in the past with "Not responding", and that does not happen with GTK.
diff --git a/results/classifier/108/other/2388 b/results/classifier/108/other/2388
new file mode 100644
index 000000000..ff4f0552f
--- /dev/null
+++ b/results/classifier/108/other/2388
@@ -0,0 +1,32 @@
+graphic: 0.784
+device: 0.653
+semantic: 0.477
+performance: 0.415
+files: 0.408
+boot: 0.312
+vnc: 0.306
+socket: 0.188
+permissions: 0.165
+PID: 0.162
+network: 0.152
+debug: 0.068
+other: 0.056
+KVM: 0.006
+
+NVMe SQ processing gets stuck when IO queue size is small (for example 4)
+Steps to reproduce:
+1. Get OSv repo with the NVMe driver and build OSv with the 'Hello World' example:
+```
+git clone https://github.com/wkozaczuk/osv.git
+cd osv
+git checkout nvme_refined
+git submodule update --init --recursive 
+./scripts/setup.py
+./scripts/build image=native-example fs=zfs -j$(nproc)
+```
+2. Run OSv with NVme on and point to your version of QEMU built with tracing enabled:
+```
+./scripts/run.py --qemu-path /home/wkozaczuk/projects/qemu/build/qemu-system-x86_64 --nics=0 --nvme -c 1  --pass-arg "--trace pci_nvme_*"
+```
+Additional information:
+I am adding both full QEMU logs with NVMe tracing enabled and diff of my changes to QEMU code to add extra logging.