10 files changed, 330 insertions, 0 deletions
diff --git a/results/classifier/108/other/271 b/results/classifier/108/other/271
new file mode 100644
index 000000000..4801470f2
--- /dev/null
+++ b/results/classifier/108/other/271
@@ -0,0 +1,16 @@
+device: 0.818
+performance: 0.680
+graphic: 0.489
+debug: 0.450
+permissions: 0.255
+boot: 0.254
+files: 0.248
+semantic: 0.174
+PID: 0.170
+vnc: 0.168
+socket: 0.143
+other: 0.106
+network: 0.069
+KVM: 0.003
+
+ARM cpu emulation regression on QEMU 4.2.0
diff --git a/results/classifier/108/other/2710 b/results/classifier/108/other/2710
new file mode 100644
index 000000000..9d92293b2
--- /dev/null
+++ b/results/classifier/108/other/2710
@@ -0,0 +1,141 @@
+other: 0.767
+permissions: 0.700
+device: 0.674
+KVM: 0.670
+debug: 0.666
+graphic: 0.660
+performance: 0.653
+vnc: 0.653
+semantic: 0.621
+network: 0.608
+boot: 0.607
+socket: 0.592
+PID: 0.585
+files: 0.536
+
+QEMU can't detect guest debug support on older (pre v5.7) x86 host kernels due to missing KVM_CAP_SET_GUEST_DEBUG
+Description of problem:
+```
+qemu-system-x86_64: -s: gdbstub: current accelerator doesn't support guest debugging
+```
+Additional information:
+I initially located the QEMU source code to determine whether KVM supports gdbstub by checking for `KVM_CAP_SET_GUEST_DEBUG`. The corresponding code can be found at: 
+```c
+// qemu/accel/kvm/kvm-all.c:2695
+#ifdef TARGET_KVM_HAVE_GUEST_DEBUG
+    kvm_has_guest_debug =
+        (kvm_check_extension(s, KVM_CAP_SET_GUEST_DEBUG) > 0);
+#endif
+```
+It can be observed that if the return value is <= 0 (in practice, this function only returns 0 on failure), the debug_flag is set to false.
+
+Upon further investigation of the Linux 4.15 kernel code, I discovered that in earlier versions, support for checking VM debugging capabilities via `KVM_CAP_SET_GUEST_DEBUG` was almost non-existent (it was only supported on arm64). However, for x86_64, VM debugging is supported on the 4.15 kernel.
+
+```c
+// linu4.15/arch/x86/kvm/x86.c:2672
+int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
+{
+	int r;
+
+	switch (ext) {
+	case KVM_CAP_IRQCHIP:
+	case KVM_CAP_HLT:
+	case KVM_CAP_MMU_SHADOW_CACHE_CONTROL:
+	case KVM_CAP_SET_TSS_ADDR:
+	case KVM_CAP_EXT_CPUID:
+	case KVM_CAP_EXT_EMUL_CPUID:
+	case KVM_CAP_CLOCKSOURCE:
+	case KVM_CAP_PIT:
+	case KVM_CAP_NOP_IO_DELAY:
+	case KVM_CAP_MP_STATE:
+	case KVM_CAP_SYNC_MMU:
+	case KVM_CAP_USER_NMI:
+	case KVM_CAP_REINJECT_CONTROL:
+	case KVM_CAP_IRQ_INJECT_STATUS:
+	case KVM_CAP_IOEVENTFD:
+	case KVM_CAP_IOEVENTFD_NO_LENGTH:
+	case KVM_CAP_PIT2:
+	case KVM_CAP_PIT_STATE2:
+	case KVM_CAP_SET_IDENTITY_MAP_ADDR:
+	case KVM_CAP_XEN_HVM:
+	case KVM_CAP_VCPU_EVENTS:
+	case KVM_CAP_HYPERV:
+	case KVM_CAP_HYPERV_VAPIC:
+	case KVM_CAP_HYPERV_SPIN:
+	case KVM_CAP_HYPERV_SYNIC:
+	case KVM_CAP_HYPERV_SYNIC2:
+	case KVM_CAP_HYPERV_VP_INDEX:
+	case KVM_CAP_PCI_SEGMENT:
+	case KVM_CAP_DEBUGREGS:
+	case KVM_CAP_X86_ROBUST_SINGLESTEP:
+	case KVM_CAP_XSAVE:
+	case KVM_CAP_ASYNC_PF:
+	case KVM_CAP_GET_TSC_KHZ:
+	case KVM_CAP_KVMCLOCK_CTRL:
+	case KVM_CAP_READONLY_MEM:
+	case KVM_CAP_HYPERV_TIME:
+	case KVM_CAP_IOAPIC_POLARITY_IGNORED:
+	case KVM_CAP_TSC_DEADLINE_TIMER:
+	case KVM_CAP_ENABLE_CAP_VM:
+	case KVM_CAP_DISABLE_QUIRKS:
+	case KVM_CAP_SET_BOOT_CPU_ID:
+ 	case KVM_CAP_SPLIT_IRQCHIP:
+	case KVM_CAP_IMMEDIATE_EXIT:
+		r = 1;
+		break;
+	case KVM_CAP_ADJUST_CLOCK:
+		r = KVM_CLOCK_TSC_STABLE;
+		break;
+	case KVM_CAP_X86_GUEST_MWAIT:
+		r = kvm_mwait_in_guest();
+		break;
+	case KVM_CAP_X86_SMM:
+		/* SMBASE is usually relocated above 1M on modern chipsets,
+		 * and SMM handlers might indeed rely on 4G segment limits,
+		 * so do not report SMM to be available if real mode is
+		 * emulated via vm86 mode.  Still, do not go to great lengths
+		 * to avoid userspace's usage of the feature, because it is a
+		 * fringe case that is not enabled except via specific settings
+		 * of the module parameters.
+		 */
+		r = kvm_x86_ops->cpu_has_high_real_mode_segbase();
+		break;
+	case KVM_CAP_VAPIC:
+		r = !kvm_x86_ops->cpu_has_accelerated_tpr();
+		break;
+	case KVM_CAP_NR_VCPUS:
+		r = KVM_SOFT_MAX_VCPUS;
+		break;
+	case KVM_CAP_MAX_VCPUS:
+		r = KVM_MAX_VCPUS;
+		break;
+	case KVM_CAP_NR_MEMSLOTS:
+		r = KVM_USER_MEM_SLOTS;
+		break;
+	case KVM_CAP_PV_MMU:	/* obsolete */
+		r = 0;
+		break;
+	case KVM_CAP_MCE:
+		r = KVM_MAX_MCE_BANKS;
+		break;
+	case KVM_CAP_XCRS:
+		r = boot_cpu_has(X86_FEATURE_XSAVE);
+		break;
+	case KVM_CAP_TSC_CONTROL:
+		r = kvm_has_tsc_control;
+		break;
+	case KVM_CAP_X2APIC_API:
+		r = KVM_X2APIC_API_VALID_FLAGS;
+		break;
+	default:
+		r = 0;
+		break;
+	}
+	return r;
+
+}
+```
+
+I attempted to bypass this check in QEMU and verified that the QEMU gdbstub works normally on the 4.15 kernel.
+
+For modifications related to this part in QEMU, you can refer to the email: https://lore.kernel.org/all/20211111110604.207376-5-pbonzini@redhat.com/.
diff --git a/results/classifier/108/other/2711 b/results/classifier/108/other/2711
new file mode 100644
index 000000000..956d2ed54
--- /dev/null
+++ b/results/classifier/108/other/2711
@@ -0,0 +1,16 @@
+device: 0.811
+performance: 0.754
+network: 0.264
+semantic: 0.188
+graphic: 0.162
+boot: 0.144
+other: 0.116
+files: 0.112
+debug: 0.107
+socket: 0.073
+permissions: 0.057
+vnc: 0.051
+PID: 0.022
+KVM: 0.005
+
+TSTEQ lowering and optimization bug
diff --git a/results/classifier/108/other/2712 b/results/classifier/108/other/2712
new file mode 100644
index 000000000..c6013cdd4
--- /dev/null
+++ b/results/classifier/108/other/2712
@@ -0,0 +1,26 @@
+graphic: 0.838
+device: 0.800
+boot: 0.755
+KVM: 0.652
+semantic: 0.633
+other: 0.404
+performance: 0.368
+vnc: 0.367
+PID: 0.325
+debug: 0.298
+permissions: 0.168
+socket: 0.146
+network: 0.086
+files: 0.035
+
+Windows VM doesn't boot on QEMU KVM when hypervisor is disabled in Linux 6.12
+Description of problem:
+Windows VM doesn't boot on QEMU KVM when hypervisor is disabled in Linux 6.12. QEMU uses 100% CPU core usage and nothing happens.
+
+It boots properly in Linux 6.11.10. I don't know if it's a kernel bug or QEMU needs some changes to work with the new kernel correctly.
+Steps to reproduce:
+1. Boot Windows 10 or 11 (can be installation ISO form official website) with KVM, but set "hypervisor=off" CPU parameter.
+2. Wait.
+3. Nothing happens - doesn't boot.
+Additional information:
+Nothing is displayed in console.
diff --git a/results/classifier/108/other/2713 b/results/classifier/108/other/2713
new file mode 100644
index 000000000..afa359dc4
--- /dev/null
+++ b/results/classifier/108/other/2713
@@ -0,0 +1,28 @@
+device: 0.908
+graphic: 0.851
+semantic: 0.686
+performance: 0.619
+PID: 0.515
+boot: 0.440
+other: 0.367
+network: 0.343
+debug: 0.332
+files: 0.329
+vnc: 0.306
+socket: 0.292
+permissions: 0.242
+KVM: 0.227
+
+Addressing Limitations with 64GB RAM on virt-9.2 Machine Type in QEMU 9.1.93
+Description of problem:
+When attempting to run a VM with 64GB of RAM using the `virt-9.2` machine type, QEMU encounters an error related to addressing limitations. It appears that the memory configuration exceeds the 32-bit addressing limit.
+
+Error output:
+**qemu-system-aarch64: Addressing limited to 32 bits, but memory exceeds it by 65498251264 bytes**
+Steps to reproduce:
+1. Build QEMU from source on macOS (M2 MacBook, arm64).
+2. Run the command with the `virt-9.2` machine type and 64GB of RAM.
+Additional information:
+- Changes in [UTM app](https://github.com/utmapp/UTM/releases) for release v4.6.2 - (macOS) Support > 32GiB RAM configurations in QEMU ([#5537](https://github.com/utmapp/UTM/issues/5537))
+- Although the site advertises release of qemu-9.2.0-rc3, the brew install doesn't install the latest version yet.
+- The QEMU build environment includes dependencies installed via Homebrew: libffi, gettext, glib, pkg-config, pixman, ninja, meson, sdl2, gtk+3, gnu-tar.
diff --git a/results/classifier/108/other/2714 b/results/classifier/108/other/2714
new file mode 100644
index 000000000..b1f36d2a9
--- /dev/null
+++ b/results/classifier/108/other/2714
@@ -0,0 +1,22 @@
+device: 0.838
+graphic: 0.790
+network: 0.765
+files: 0.700
+other: 0.677
+vnc: 0.634
+socket: 0.610
+PID: 0.547
+debug: 0.473
+semantic: 0.431
+boot: 0.425
+permissions: 0.405
+performance: 0.223
+KVM: 0.070
+
+Potential memory leak in virtio-crytpto
+Description of problem:
+There is a potential memory leak while using virtio-crypto with vhost-user backend.
+
+The problem is due to misuse of error_setg in [backends/cryptodev-vhost-user.c#L284](https://gitlab.com/qemu-project/qemu/-/blob/master/backends/cryptodev-vhost-user.c#L284). After invoking error_setg(&local_error, ...), current procedure should not return without freeing err object pointed by local_error.
+
+The same problem occured in cryptodev-builtin, which has been discussed in #2283 and fixed in f6abce29cc4afa0445cb3b29a265a114ac9fa744. The same fixes should be applied to cryptodev-vhost-user.
diff --git a/results/classifier/108/other/2715 b/results/classifier/108/other/2715
new file mode 100644
index 000000000..dac4efcfd
--- /dev/null
+++ b/results/classifier/108/other/2715
@@ -0,0 +1,16 @@
+device: 0.834
+network: 0.697
+boot: 0.485
+performance: 0.451
+socket: 0.393
+files: 0.381
+graphic: 0.304
+permissions: 0.288
+semantic: 0.245
+vnc: 0.236
+PID: 0.193
+other: 0.122
+debug: 0.105
+KVM: 0.024
+
+QEMU AARCH64 only supports canonical addresses running on x64.
diff --git a/results/classifier/108/other/2716 b/results/classifier/108/other/2716
new file mode 100644
index 000000000..57f6421f0
--- /dev/null
+++ b/results/classifier/108/other/2716
@@ -0,0 +1,22 @@
+device: 0.864
+performance: 0.757
+network: 0.742
+vnc: 0.728
+boot: 0.660
+files: 0.567
+graphic: 0.500
+PID: 0.466
+KVM: 0.431
+debug: 0.336
+socket: 0.256
+semantic: 0.249
+permissions: 0.207
+other: 0.040
+
+migrate incoming with fd transfer issue
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+#
diff --git a/results/classifier/108/other/2717 b/results/classifier/108/other/2717
new file mode 100644
index 000000000..8fdf36448
--- /dev/null
+++ b/results/classifier/108/other/2717
@@ -0,0 +1,27 @@
+graphic: 0.803
+device: 0.744
+semantic: 0.725
+files: 0.666
+network: 0.522
+socket: 0.514
+vnc: 0.495
+debug: 0.262
+other: 0.238
+boot: 0.234
+permissions: 0.213
+PID: 0.187
+performance: 0.166
+KVM: 0.133
+
+semihosting link to risc-v details in document is changed
+Description of problem:
+
+Steps to reproduce:
+1. Open https://gitlab.com/qemu-project/qemu/-/blob/master/docs/about/emulation.rst
+2. Goto Supported Targets section
+3. Click RISC-V link in the table
+4. Got 404
+
+New url looks like https://github.com/riscv-non-isa/riscv-semihosting/blob/main/riscv-semihosting.adoc
+Additional information:
+
diff --git a/results/classifier/108/other/2719 b/results/classifier/108/other/2719
new file mode 100644
index 000000000..22b01d2fb
--- /dev/null
+++ b/results/classifier/108/other/2719
@@ -0,0 +1,16 @@
+other: 0.975
+files: 0.841
+device: 0.655
+network: 0.551
+PID: 0.451
+vnc: 0.450
+socket: 0.442
+semantic: 0.412
+performance: 0.387
+boot: 0.303
+permissions: 0.274
+debug: 0.218
+KVM: 0.210
+graphic: 0.113
+
+9.2.0 tarball contains unrelated files