6 files changed, 229 insertions, 0 deletions
diff --git a/results/classifier/108/other/268 b/results/classifier/108/other/268
new file mode 100644
index 000000000..03e139de4
--- /dev/null
+++ b/results/classifier/108/other/268
@@ -0,0 +1,16 @@
+device: 0.877
+other: 0.707
+performance: 0.603
+debug: 0.509
+vnc: 0.435
+semantic: 0.374
+graphic: 0.346
+network: 0.323
+permissions: 0.319
+boot: 0.289
+PID: 0.269
+files: 0.174
+socket: 0.125
+KVM: 0.103
+
+arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always read 0 - "N-N")
diff --git a/results/classifier/108/other/2681 b/results/classifier/108/other/2681
new file mode 100644
index 000000000..61bd990f8
--- /dev/null
+++ b/results/classifier/108/other/2681
@@ -0,0 +1,16 @@
+device: 0.804
+performance: 0.688
+network: 0.585
+PID: 0.361
+socket: 0.282
+graphic: 0.279
+permissions: 0.274
+semantic: 0.232
+debug: 0.226
+files: 0.224
+boot: 0.189
+other: 0.150
+vnc: 0.131
+KVM: 0.001
+
+QEMU build system should halt, if glib version is lower than needed
diff --git a/results/classifier/108/other/2683 b/results/classifier/108/other/2683
new file mode 100644
index 000000000..cc5ccde08
--- /dev/null
+++ b/results/classifier/108/other/2683
@@ -0,0 +1,54 @@
+performance: 0.867
+graphic: 0.841
+semantic: 0.795
+other: 0.784
+PID: 0.759
+device: 0.758
+network: 0.714
+permissions: 0.706
+vnc: 0.685
+socket: 0.632
+KVM: 0.630
+debug: 0.602
+files: 0.573
+boot: 0.479
+
+TCG: probe_access() has inconsistent behavior
+Description of problem:
+In full-system mode, probe_access() will return NULL when the flag is TLB_MMIO.
+
+accel/tcg/cputlb.c: probe_access_internal()
+```
+    if (unlikely(flags & ~(TLB_WATCHPOINT | TLB_NOTDIRTY | TLB_CHECK_ALIGNED))
+        || (access_type != MMU_INST_FETCH && force_mmio)) {
+        *phost = NULL;
+        return TLB_MMIO;
+    }
+```
+But in linux-user mode, it will return correct address when the flag is TLB_MMIO.
+
+accel/tcg/user-exec.c: probe_access()
+```
+    return size ? g2h(env_cpu(env), addr) : NULL;
+```
+This will lead to some different behaviors, like cbo.zero in RISC-V.
+
+target/riscv/op_helper.c: helper_cbo_zero()
+```
+    mem = probe_write(env, address, cbozlen, mmu_idx, ra);
+
+    if (likely(mem)) {
+        memset(mem, 0, cbozlen);
+    } else {
+        for (int i = 0; i < cbozlen; i++) {
+            cpu_stb_mmuidx_ra(env, address + i, 0, mmu_idx, ra);
+        }
+    }
+```
+When the current instruction has memory callback by plugin:
+
+Full-system mode uses slow-path(cpu_stb_mmuidx_ra) and inject mem_cbs correctly.
+
+Linux-user mode uses fast-path(memset) and doesn't inject callbacks.
+
+To ensure consistent results, probe_access() should return NULL when the flag is TLB_MMIO in linux-user mode.
diff --git a/results/classifier/108/other/2686 b/results/classifier/108/other/2686
new file mode 100644
index 000000000..203627645
--- /dev/null
+++ b/results/classifier/108/other/2686
@@ -0,0 +1,63 @@
+performance: 0.886
+graphic: 0.855
+debug: 0.843
+device: 0.803
+other: 0.763
+socket: 0.763
+network: 0.755
+PID: 0.723
+vnc: 0.714
+permissions: 0.695
+files: 0.615
+boot: 0.601
+semantic: 0.494
+KVM: 0.279
+
+rng-seed addition causing test_loongarch64_virt.py to hang in EFI startup
+Description of problem:
+Since the rng-seed addition, the test_loongarch64_virt.py test will periodically hang.
+
+git bisect blames this
+
+```
+commit d9bd1ccbf1d84d872aed684c65fec33814b8ac1b
+Author: Jason A. Donenfeld <Jason@zx2c4.com>
+Date:   Thu Sep 5 17:33:16 2024 +0200
+
+    hw/loongarch: virt: pass random seed to fdt
+    
+    If the FDT contains /chosen/rng-seed, then the Linux RNG will use it to
+    initialize early. Set this using the usual guest random number
+    generation function.
+    
+    This is the same procedure that's done in b91b6b5a2c ("hw/microblaze:
+    pass random seed to fdt"), e4b4f0b71c ("hw/riscv: virt: pass random seed
+    to fdt"), c6fe3e6b4c ("hw/openrisc: virt: pass random seed to fdt"),
+    67f7e426e5 ("hw/i386: pass RNG seed via setup_data entry"), c287941a4d
+    ("hw/rx: pass random seed to fdt"), 5e19cc68fb ("hw/mips: boston: pass
+    random seed to fdt"), 6b23a67916 ("hw/nios2: virt: pass random seed to fdt")
+    c4b075318e ("hw/ppc: pass random seed to fdt"), and 5242876f37
+    ("hw/arm/virt: dt: add rng-seed property").
+    
+    These earlier commits later were amended to rerandomize the RNG seed on
+    snapshot load, but the LoongArch code somehow already does that, despite
+    not having this patch here, presumably due to some lucky copy and
+    pasting.
+    
+    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
+    Reviewed-by: Song Gao <gaosong@loongson.cn>
+    Message-Id: <20240905153316.2038769-1-Jason@zx2c4.com>
+    Signed-off-by: Song Gao <gaosong@loongson.cn>
+```
+
+When it hangs, test_loongarch64_virt.py will get stuck waiting for serial console output from the guest.
+
+Looking at the console.log file shows it to be completely empty. 
+
+This appears to indicate it has hung before EDK has even initialized, as it has not even printed the 'Entering C environment' message
+Steps to reproduce:
+1. ./configure --target-list=loongarch64-softmmu
+2. make -j 20
+3. n=0 ; while true ; do n=$(expr $n + 1); echo $n ; QEMU_TEST_QEMU_BINARY=./build/qemu-system-loongarch64  PYTHONPATH=./python ./tests/functional/test_loongarch64_virt.py  ; done
+
+Most commonly it will hang within 10 iterations, very occasionally needing upto 25
diff --git a/results/classifier/108/other/2687 b/results/classifier/108/other/2687
new file mode 100644
index 000000000..b3a0a0af0
--- /dev/null
+++ b/results/classifier/108/other/2687
@@ -0,0 +1,64 @@
+graphic: 0.914
+performance: 0.782
+device: 0.642
+socket: 0.576
+semantic: 0.534
+debug: 0.522
+PID: 0.449
+other: 0.377
+vnc: 0.300
+network: 0.285
+files: 0.147
+permissions: 0.136
+boot: 0.131
+KVM: 0.073
+
+regression in qtest clock_set/clock_step
+Description of problem:
+As of QEMU 9.0 the script included below would increment the time via qtest, but it is now broken and time doesn't seem to be updated. I do note that the QEMU sources use clock_step extensively via qtest_clock_step, but nothing seems to be using the return value so maybe that's why it hasn't been noticed?
+ 
+It seems to have been broken in bc02be4508d8753d1f6071b77d10f4661587df6f which was trying to prevent some deadlock. You can prove that this breaks it by setting a breakpoint in `qemu_virtual_clock_set_ns` -- it never gets called.
+Steps to reproduce:
+Run this python script from your QEMU build directory:
+
+```python
+#!/usr/bin/env python3
+
+import subprocess
+import socket
+import typing
+
+qemu_path = "./qemu-system-x86_64"
+
+
+def main():
+    s1, s2 = socket.socketpair()
+
+    qemu = subprocess.Popen(
+        [
+            qemu_path,
+            "-S",
+            "-display",
+            "none",
+            "-chardev", f"socket,id=qtest,fd={s1.fileno()},nodelay=on",
+            "-qtest", "chardev:qtest",
+            "-qtest-log", "/dev/fd/2",
+            "-accel", "qtest",
+        ],
+        pass_fds=[s1.fileno()],
+    )
+
+    try:
+
+        fp = s2.makefile("rw", buffering=1)
+
+        fp.write(f"clock_set 1234\n")
+        result = fp.readline()[:-1].split(" ")
+        assert result == ["OK", "1234"], f"Unexpected result: {result}"
+    finally:
+        qemu.kill()
+
+
+if __name__ == "__main__":
+    main()
+```
diff --git a/results/classifier/108/other/2689 b/results/classifier/108/other/2689
new file mode 100644
index 000000000..391834fd6
--- /dev/null
+++ b/results/classifier/108/other/2689
@@ -0,0 +1,16 @@
+performance: 0.907
+device: 0.902
+network: 0.877
+vnc: 0.586
+socket: 0.549
+files: 0.491
+graphic: 0.473
+boot: 0.350
+debug: 0.339
+semantic: 0.313
+permissions: 0.255
+PID: 0.246
+other: 0.228
+KVM: 0.064
+
+arm64be tuxrun test is sometimes failing with I/O errors