8 files changed, 230 insertions, 0 deletions
diff --git a/results/classifier/108/other/282 b/results/classifier/108/other/282
new file mode 100644
index 00000000..b470de09
--- /dev/null
+++ b/results/classifier/108/other/282
@@ -0,0 +1,16 @@
+network: 0.829
+device: 0.699
+performance: 0.688
+socket: 0.567
+other: 0.458
+vnc: 0.359
+files: 0.291
+graphic: 0.290
+PID: 0.258
+KVM: 0.255
+boot: 0.250
+semantic: 0.212
+permissions: 0.150
+debug: 0.118
+
+[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation)
diff --git a/results/classifier/108/other/2820 b/results/classifier/108/other/2820
new file mode 100644
index 00000000..275a1ba8
--- /dev/null
+++ b/results/classifier/108/other/2820
@@ -0,0 +1,42 @@
+performance: 0.912
+permissions: 0.902
+semantic: 0.882
+graphic: 0.848
+debug: 0.822
+vnc: 0.800
+other: 0.786
+network: 0.773
+device: 0.745
+files: 0.697
+PID: 0.645
+socket: 0.645
+KVM: 0.569
+boot: 0.509
+
+STOPI CSR Incorrect Value for Virtual Supervisor External Interrupt in QEMU (AIA Extension)
+Description of problem:
+We are developing a RISC-V core and have implemented tests for the AIA extension. One of these tests reveals a bug when running in QEMU in a bare-metal environment. The issue relates to the value of the STOPI CSR. Although the CSR behaves correctly in most cases, when a virtual supervisor external interrupt is generated using the IMSIC (i.e., both hip.vseip and hie.vseip are set to 1) while executing in supervisor mode with hideleg.vseip set to 0, the STOPI CSR always returns the value 0. However, according to the specifications, it should return 10, which is the major identity number for the virtual supervisor external interrupt.
+
+According to the RISC-V specs:
+
+> The value of stopi is zero unless: (a) there is an interrupt that is both pending in sip and enabled in
+sie, or, if the hypervisor extension is implemented, both pending in hip and enabled in hie; and (b)
+the interrupt is not delegated to a lower privilege level (by hideleg, if the hypervisor extension is
+implemented). When there is a pending-and-enabled major interrupt for supervisor level, field IID is
+the major identity number of the highest-priority interrupt, and field IPRIO indicates its priority.
+
+Upon reviewing the QEMU AIA code, I found the following snippet in `qemu/target/riscv/cpu_helper.c` that might be causing the problem:
+```
+int riscv_cpu_sirq_pending(CPURISCVState *env)
+{
+    uint64_t irqs = riscv_cpu_all_pending(env) & env->mideleg &
+                    ~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP);
+    uint64_t irqs_f = env->mvip & env->mvien & ~env->mideleg & env->sie;
+
+    return riscv_cpu_pending_to_irq(env, IRQ_S_EXT, IPRIO_DEFAULT_S,
+                                    irqs | irqs_f, env->siprio);
+}
+```
+It appears that virtual supervisor (VS) interrupts are being masked (via the `~(MIP_VSSIP | MIP_VSTIP | MIP_VSEIP)` operation) when they likely should not be, which could explain why the STOPI CSR does not reflect the correct value.
+
+Thank you for your time, and please let me know if any details require further clarification or if my interpretation is incorrect.
diff --git a/results/classifier/108/other/2821 b/results/classifier/108/other/2821
new file mode 100644
index 00000000..e92912d2
--- /dev/null
+++ b/results/classifier/108/other/2821
@@ -0,0 +1,38 @@
+performance: 0.801
+graphic: 0.774
+KVM: 0.731
+device: 0.568
+network: 0.455
+files: 0.434
+other: 0.404
+PID: 0.394
+vnc: 0.328
+semantic: 0.319
+socket: 0.287
+permissions: 0.272
+debug: 0.249
+boot: 0.237
+
+Emulated newer x86 chipsets are noticably slower on cpu-bound loads than "-cpu qemu64"
+Description of problem:
+I noticed that "-cpu qemu64" is much faster than "-cpu max" or "-cpu Icelake-Server-noTSX" for cpu bound loads, and with more than one cpu under load.
+Steps to reproduce:
+1. Run a guest as per "qemu-system-x86_64 -cpu max [..]" command from above. Any linux distro should do.
+2. run through the setup questions if you use Fedora-Server-KVM-41-1.4.x86_64.qcow2 from the example command line above
+3. log into the guest via ssh, i.e. "ssh chris@amd64" here
+4. cd /dev/shm; wget http://archive.apache.org/dist/httpd/httpd-2.4.57.tar.bz2; wget https://fluxcoil.net/files/tmp/job_httpd_extract_cpu.sh
+6. bash ./job_httpd_extract_cpu.sh 4 300
+8. cat /tmp/counter
+
+Step 6 is executing a script which simply uses 4 parallel loops, where each loop runs "bzcat httpd-2.4.57.tar.bz2" constantly. After 300sec, the successful uncompressions over all 4 loops are summed up and stored in /tmp/counter.
+
+- result with "-cpu qemu64": 96
+- result with "-cpu max": 84
+- result with "-cpu Icelake-Server-noTSX": 44
+Additional information:
+- For "-cpu Icelake-Server-noTSX" on this Thinkpad T590 I get these warnings, I think they are not relevant:
+  qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
+  qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
+  [..]
+- I also looked at Broadwell etc, and all of them seem in the same ballpark.
+  Graph over some emulated architectures: https://fluxcoil.net/files/tmp/gnuplot_cpu-performance-emulated-only.png
diff --git a/results/classifier/108/other/2822 b/results/classifier/108/other/2822
new file mode 100644
index 00000000..ec93c982
--- /dev/null
+++ b/results/classifier/108/other/2822
@@ -0,0 +1,26 @@
+graphic: 0.858
+performance: 0.799
+device: 0.793
+debug: 0.562
+files: 0.551
+vnc: 0.511
+boot: 0.434
+semantic: 0.428
+permissions: 0.385
+PID: 0.319
+socket: 0.127
+network: 0.073
+other: 0.059
+KVM: 0.020
+
+Data race with state field of ThreadPoolElement
+Description of problem:
+A data race in the access of `ThreadPoolElement` state field in `util/thread-pool.c` was identified using TSAN.
+Steps to reproduce:
+```sh
+QEMU_BUILD_DIR=<path to the QEMU build directory>
+QEMU_DIR=<path to the QEMU repository directory>
+configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp
+make tests/unit/test-thread-pool
+MALLOC_PERTURB_=111 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-thread-pool --tap -k
+```
diff --git a/results/classifier/108/other/2823 b/results/classifier/108/other/2823
new file mode 100644
index 00000000..8a2f9e5d
--- /dev/null
+++ b/results/classifier/108/other/2823
@@ -0,0 +1,58 @@
+permissions: 0.751
+other: 0.722
+performance: 0.678
+semantic: 0.676
+graphic: 0.661
+debug: 0.653
+boot: 0.639
+vnc: 0.618
+device: 0.616
+PID: 0.599
+KVM: 0.558
+files: 0.535
+socket: 0.511
+network: 0.472
+
+func-aarch64-aarch64_rme_virt function test hangs especially when built with --enable-debug
+Description of problem:
+
+Steps to reproduce:
+1. Build with ../../configure --enable-debug
+2. ./pyvenv/bin/meson test --setup thorough --suite func-thorough func-aarch64-aarch64_rme_virt
+3. repeat until hang
+Additional information:
+Comparing a normal build to the hang:
+
+```
+2025-02-20 16:54:15,519: NOTICE:  Booting Trusted Firmware    | 2025-02-20 16:16:06,740: NOTICE:  Booting Trusted Firmware
+2025-02-20 16:54:15,519: NOTICE:  BL1: v2.11.0(release):f2f94 | 2025-02-20 16:16:06,740: NOTICE:  BL1: v2.11.0(release):f2f94
+2025-02-20 16:54:15,519: NOTICE:  BL1: Built : 17:54:58, Dec  | 2025-02-20 16:16:06,740: NOTICE:  BL1: Built : 17:54:58, Dec 
+2025-02-20 16:54:15,520: NOTICE:  BL1: Booting BL2            | 2025-02-20 16:16:06,741: NOTICE:  BL1: Booting BL2
+2025-02-20 16:54:15,522: NOTICE:  BL2: v2.11.0(release):f2f94 | 2025-02-20 16:16:06,743: NOTICE:  BL2: v2.11.0(release):f2f94
+2025-02-20 16:54:15,522: NOTICE:  BL2: Built : 17:55:12, Dec  | 2025-02-20 16:16:06,743: NOTICE:  BL2: Built : 17:55:12, Dec 
+2025-02-20 16:54:15,545: NOTICE:  BL2: Booting BL31           | 2025-02-20 16:16:06,762: NOTICE:  BL2: Booting BL31
+2025-02-20 16:54:15,550: NOTICE:  BL31: v2.11.0(release):f2f9 | 2025-02-20 16:16:06,768: NOTICE:  BL31: v2.11.0(release):f2f9
+2025-02-20 16:54:15,550: NOTICE:  BL31: Built : 17:55:22, Dec | 2025-02-20 16:16:06,768: NOTICE:  BL31: Built : 17:55:22, Dec
+2025-02-20 16:54:15,555: Booting RMM v.0.5.0(release) 1b6bdf8 | 2025-02-20 16:16:06,774: Booting RMM v.0.5.0(release) 1b6bdf8
+2025-02-20 16:54:15,556: RMM-EL3 Interface v.0.4              | 2025-02-20 16:16:06,774: RMM-EL3 Interface v.0.4
+2025-02-20 16:54:15,556: Boot Manifest Interface v.0.3        | 2025-02-20 16:16:06,775: Boot Manifest Interface v.0.3
+2025-02-20 16:54:15,556: RMI/RSI ABI v.1.0/1.0 built: Dec  2  | 2025-02-20 16:16:06,775: RMI/RSI ABI v.1.0/1.0 built: Dec  2 
+2025-02-20 16:54:15,587: UEFI firmware (version  built at 17: | 2025-02-20 16:16:06,837: UEFI firmware (version  built at 17:
+2025-02-20 16:54:15,876: ESC[2JESC[01;01HESC[=3hESC[2JESC[01;01HESC[2JESC[01;01HESC[= | 2025-02-20 16:16:07,420: ESC[2JESC[01;01HESC[=3hESC[2JESC[01;01HESC[2JESC[01;01HESC[=
+2025-02-20 16:54:15,898: EFI stub: Using DTB from configurati | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:15,898: EFI stub: Exiting boot services...   | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:16,170: [    0.000000] Booting Linux on phys | 2025-02-20 16:16:07,421: Synchronous Exception at 0x00000000B
+2025-02-20 16:54:16,171: [    0.000000] Linux version 6.12.0- | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:16,171: [    0.000000] KASLR enabled         | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:16,171: [    0.000000] random: crng init don | 2025-02-20 16:16:07,421: Synchronous Exception at 0x00000000B
+2025-02-20 16:54:16,171: [    0.000000] Machine model: linux, <
+2025-02-20 16:54:16,171: [    0.000000] efi: EFI v2.7 by EDK  <
+2025-02-20 16:54:16,171: [    0.000000] efi: SMBIOS=0xbf3c000 <
+2025-02-20 16:54:16,171: [    0.000000] OF: reserved mem: 0x0 <
+2025-02-20 16:54:16,171: [    0.000000] NUMA: Faking a node a <
+2025-02-20 16:54:16,171: [    0.000000] NODE_DATA(0) allocate <
+2025-02-20 16:54:16,171: [    0.000000] Zone ranges:          <
+2025-02-20 16:54:16,171: [    0.000000]   DMA      [mem 0x000 <
+2025-02-20 16:54:16,171: [    0.000000]   DMA32    empty      <
+2025-02-20 16:54:16,171: [    0.000000]   Normal   empty      <
+```
diff --git a/results/classifier/108/other/2824 b/results/classifier/108/other/2824
new file mode 100644
index 00000000..78ec378f
--- /dev/null
+++ b/results/classifier/108/other/2824
@@ -0,0 +1,16 @@
+device: 0.785
+debug: 0.494
+performance: 0.464
+semantic: 0.432
+PID: 0.427
+files: 0.423
+boot: 0.361
+graphic: 0.305
+permissions: 0.253
+network: 0.207
+vnc: 0.153
+socket: 0.126
+other: 0.046
+KVM: 0.011
+
+compile from source on macOS error: "found no usable tomli, please install it"
diff --git a/results/classifier/108/other/2827 b/results/classifier/108/other/2827
new file mode 100644
index 00000000..7ed577a3
--- /dev/null
+++ b/results/classifier/108/other/2827
@@ -0,0 +1,16 @@
+network: 0.915
+device: 0.801
+performance: 0.490
+graphic: 0.265
+boot: 0.217
+semantic: 0.172
+permissions: 0.107
+socket: 0.076
+debug: 0.072
+PID: 0.058
+files: 0.033
+vnc: 0.032
+other: 0.030
+KVM: 0.001
+
+Document how to use QEMU user mode networking with passt
diff --git a/results/classifier/108/other/2828 b/results/classifier/108/other/2828
new file mode 100644
index 00000000..538a8b5e
--- /dev/null
+++ b/results/classifier/108/other/2828
@@ -0,0 +1,18 @@
+graphic: 0.901
+device: 0.819
+semantic: 0.791
+other: 0.788
+debug: 0.768
+performance: 0.656
+socket: 0.570
+vnc: 0.465
+PID: 0.382
+network: 0.349
+boot: 0.322
+KVM: 0.179
+files: 0.160
+permissions: 0.099
+
+Potential issues at Interrupt filtering and virtual interrupts for supervisor level (RISC-V AIA)
+Description of problem:
+I am working on RISC-V Advanced Interrupt Architecture (AIA) compliance tests for our RISC-V core. These tests pass on our hardware implementation but fail when running on QEMU. There are several points where the tests fail while running in QEMU: