add 18th iteration of classifier

author: Christian Krinitsin <mail@krinitsin.com> 2025-06-16 16:59:00 +0000
committer: Christian Krinitsin <mail@krinitsin.com> 2025-06-16 16:59:33 +0000
commit: 9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch)
tree: b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/kernel
parent: b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download: qemu-analysis-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz
qemu-analysis-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip
83 files changed, 4927 insertions, 0 deletions
diff --git a/results/classifier/118/kernel/1069 b/results/classifier/118/kernel/1069
new file mode 100644
index 000000000..b3a948472
--- /dev/null
+++ b/results/classifier/118/kernel/1069
@@ -0,0 +1,43 @@
+kernel: 0.968
+graphic: 0.959
+device: 0.932
+architecture: 0.838
+PID: 0.660
+semantic: 0.644
+debug: 0.599
+x86: 0.570
+register: 0.535
+boot: 0.502
+vnc: 0.440
+performance: 0.407
+ppc: 0.403
+permissions: 0.393
+i386: 0.361
+hypervisor: 0.345
+socket: 0.325
+user-level: 0.313
+risc-v: 0.307
+TCG: 0.284
+mistranslation: 0.270
+network: 0.263
+VMM: 0.229
+virtual: 0.226
+arm: 0.200
+files: 0.171
+peripherals: 0.133
+assembly: 0.052
+KVM: 0.025
+
+Qemu triggers the split lock detection of the Linux kernel
+Description of problem:
+Windows displays a "blue screen of death" and the Linux kernel logs this error message:
+
+```
+[  180.886150] x86/split lock detection: #AC: qemu-system-x86/10167 took a split_lock trap at address: 0x3ff2624d
+[  180.946151] x86/split lock detection: #AC: qemu-system-x86/10168 took a split_lock trap at address: 0x3ff2624d
+```
+Steps to reproduce:
+1. Start the guest OS
+2. Do some stuff in the Windows guest (for instance OS updates)
+Additional information:
+Is this a bug in Windows or in Qemu ?
diff --git a/results/classifier/118/kernel/1073 b/results/classifier/118/kernel/1073
new file mode 100644
index 000000000..3fa5d7fe9
--- /dev/null
+++ b/results/classifier/118/kernel/1073
@@ -0,0 +1,59 @@
+kernel: 0.913
+device: 0.909
+peripherals: 0.836
+graphic: 0.802
+performance: 0.786
+architecture: 0.783
+virtual: 0.670
+vnc: 0.656
+network: 0.644
+hypervisor: 0.625
+debug: 0.613
+arm: 0.604
+boot: 0.596
+ppc: 0.544
+PID: 0.515
+socket: 0.513
+files: 0.512
+permissions: 0.509
+register: 0.452
+TCG: 0.445
+user-level: 0.428
+risc-v: 0.423
+semantic: 0.412
+mistranslation: 0.377
+VMM: 0.374
+assembly: 0.236
+x86: 0.164
+i386: 0.155
+KVM: 0.142
+
+SIGABRT with -M raspi3b,accel=hvf on macOS
+Description of problem:
+There is a `SIGUSR2` or `SIGUSR1` raised which causes QEMU to abort:
+```
+(lldb) bt
+* thread #3, stop reason = signal SIGUSR2
+  * frame #0: 0x0000000184c384a4 libsystem_kernel.dylib`__sigsuspend + 8
+    frame #1: 0x0000000100b7ff34 qemu-system-aarch64`qemu_coroutine_new at coroutine-sigaltstack.c:221:9
+    frame #2: 0x0000000100b91f0c qemu-system-aarch64`qemu_coroutine_create(entry=(qemu-system-aarch64`monitor_qmp_dispatcher_co at qmp.c:211), opaque=0x0000000000000000) at qemu-coroutine.c:90:14
+    frame #3: 0x0000000100a833d8 qemu-system-aarch64`monitor_init_globals_core at monitor.c:707:25
+```
+
+I tried skipping over it with `lldb`:
+```
+(lldb) b main
+(lldb) r
+(lldb) process handle SIGUSR1 -s false -p true
+(lldb) process handle SIGUSR2 -s false -p true
+(lldb) c
+qemu-system-aarch64: Unknown Error
+```
+
+I investigated the Unknown Error and and it's actually `HV_ILLEGAL_GUEST_STATE` which is unhandled in the `assert_hvf_ok` function. From here the VM will fail.
+Steps to reproduce:
+1. Get a fake disk. Or create a fake one with: `qemu-img create -f qcow2 zero.qcow2 2G`
+2. Run QEMU with the HVF accelerator: `qemu-system-aarch64 -M raspi3b,accel=hvf -drive id=card0,if=none,format=qcow2,index=0,file=./zero.qcow2 -device sd-card,drive=card0 -serial stdio
+`
+Additional information:
+
diff --git a/results/classifier/118/kernel/1078 b/results/classifier/118/kernel/1078
new file mode 100644
index 000000000..7d1cb066a
--- /dev/null
+++ b/results/classifier/118/kernel/1078
@@ -0,0 +1,74 @@
+kernel: 0.962
+performance: 0.956
+architecture: 0.954
+arm: 0.948
+device: 0.922
+graphic: 0.910
+VMM: 0.878
+debug: 0.852
+peripherals: 0.851
+boot: 0.829
+ppc: 0.823
+user-level: 0.813
+semantic: 0.793
+risc-v: 0.788
+mistranslation: 0.760
+vnc: 0.756
+PID: 0.754
+permissions: 0.745
+files: 0.722
+hypervisor: 0.713
+socket: 0.674
+TCG: 0.669
+x86: 0.661
+assembly: 0.654
+KVM: 0.629
+register: 0.609
+virtual: 0.521
+i386: 0.518
+network: 0.509
+
+qemu-system-arm: unable to use LPAE
+Description of problem:
+Failed to run qemu: qemu-system-arm: Addressing limited to 32 bits,
+but memory exceeds it by 1073741824 bytes
+Steps to reproduce:
+1. ./configure --target-list=arm-softmmu
+2. make
+3.
+./qemu-system-arm \
+-machine virt,highmem=on \
+-cpu cortex-a15 -smp 4 \
+-m 4096 \
+-kernel ./zImage \
+-drive id=disk0,file=./rootfs.ext4,if=none,format=raw \
+-object rng-random,filename=/dev/urandom,id=rng0 \
+-device virtio-rng-pci,rng=rng0 \
+-device virtio-blk-device,drive=disk0 \
+-device virtio-gpu-pci \
+-serial mon:stdio -serial null \
+-nographic \
+-append 'root=/dev/vda rw mem=4096M ip=dhcp console=ttyAMA0 console=hvc0'
+Additional information:
+We set physical address bits to 40 if ARM_FEATURE_LPAE is enabled. But ARM_FEATURE_V7VE also implies ARM_FEATURE_LPAE as set later in arm_cpu_realizefn.
+
+We should add condition for ARM_FEATURE_V7VE, otherwise we would not be able to use highmem larger than 3GB even though we have enabled highmem, since we would fail and return right from machvirt_init. 
+
+I have already made a patch to fix this issue.
+https://gitlab.com/realhezhe/qemu/-/commit/4dad8167c1c1a7695af88d8929e8d7f6399177de
+`hw/arm/virt.c`
+```c
+        if (object_property_get_bool(cpuobj, "aarch64", NULL)) {
+            pa_bits = arm_pamax(armcpu);
+        } else if (arm_feature(&armcpu->env, ARM_FEATURE_LPAE)) {
+        } else if (arm_feature(&armcpu->env, ARM_FEATURE_LPAE)
+                || arm_feature(&armcpu->env, ARM_FEATURE_V7VE)) {
+            /* v7 with LPAE */
+            pa_bits = 40;
+        } else {
+```
+
+After applying the patch, I can make sure that the pa_bits has already been set to 40, but qemu hangs later. By bisecting I found if the following commit is reverted qemu can boot up successfully..
+39a1fd2528 ("target/arm: Fix handling of LPAE block descriptors")
+
+It can't be quickly determined what's going on here at my side. Maybe the author can help give some hints. Thanks.
diff --git a/results/classifier/118/kernel/1119686 b/results/classifier/118/kernel/1119686
new file mode 100644
index 000000000..fdba220c1
--- /dev/null
+++ b/results/classifier/118/kernel/1119686
@@ -0,0 +1,76 @@
+kernel: 0.857
+architecture: 0.855
+debug: 0.815
+x86: 0.802
+files: 0.785
+virtual: 0.760
+hypervisor: 0.754
+semantic: 0.745
+graphic: 0.740
+device: 0.726
+ppc: 0.720
+permissions: 0.706
+network: 0.696
+performance: 0.687
+user-level: 0.680
+socket: 0.664
+i386: 0.654
+vnc: 0.624
+peripherals: 0.620
+risc-v: 0.599
+register: 0.598
+arm: 0.594
+KVM: 0.589
+VMM: 0.559
+TCG: 0.554
+PID: 0.547
+boot: 0.508
+assembly: 0.381
+mistranslation: 0.327
+
+Incorrect handling of icebp
+
+Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu.
+
+To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present:
+
+    exception.c:202: exception 0: 80000004 flags:0 addr:003F0000
+    exception.c:208: Test failed: 0: Wrong exception address 003F0000/003F0001
+    exception.c:214: this is the last test seen before the exception
+    exception: unhandled exception 80000004 at 003F0000
+    exception.c:202: exception 0: c0000027 flags:2 addr:7C80E0B9
+    exception.c:205: Test failed: 0: Wrong exception code c0000027/80000004
+    exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001
+
+Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental).
+
+
+
+This bug is still present in QEMU 1.6.0 (as per Debian's qemu-system-x86 1.6.0+dfsg-1 package).
+
+
+This bug is still present in QEMU 1.7.0 (as per Debian's qemu-system-x86 1.7.0+dfsg-3 package).
+
+The patch submitted upstream was for the kernel. Is this also a bug in QEMU when TCG is disabled?
+
+s/TCG/KVM/ - Is this also a bug when KVM is disabled?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+Actually this got fixed by the following Linux kernel commit:
+
+https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd2a445a94d2ab6b39fb623dc02fee48d01a565a
+
+commit	fd2a445a94d2ab6b39fb623dc02fee48d01a565a (patch)
+
+KVM: VMX: Advance rip to after an ICEBP instruction
+When entering an exception after an ICEBP, the saved instruction
+pointer should point to after the instruction.
+
+This fixes the bug here: https://bugs.launchpad.net/qemu/+bug/1119686
+
+Signed-off-by: Huw Davies <email address hidden>
+Reviewed-by: Jan Kiszka <email address hidden>
+Signed-off-by: Marcelo Tosatti <email address hidden>
+
+
diff --git a/results/classifier/118/kernel/1120 b/results/classifier/118/kernel/1120
new file mode 100644
index 000000000..d7a23228e
--- /dev/null
+++ b/results/classifier/118/kernel/1120
@@ -0,0 +1,42 @@
+i386: 0.994
+kernel: 0.991
+graphic: 0.941
+ppc: 0.919
+device: 0.885
+files: 0.862
+architecture: 0.850
+performance: 0.849
+semantic: 0.829
+x86: 0.682
+debug: 0.632
+mistranslation: 0.618
+user-level: 0.601
+boot: 0.539
+vnc: 0.482
+PID: 0.444
+TCG: 0.297
+VMM: 0.202
+risc-v: 0.188
+permissions: 0.163
+virtual: 0.161
+register: 0.144
+network: 0.134
+KVM: 0.129
+arm: 0.057
+peripherals: 0.037
+assembly: 0.032
+socket: 0.032
+hypervisor: 0.004
+
+Multiboot direct loading broken.
+Description of problem:
+This is my kernel and it's multiboot loader. It passed the check of `grub-file`, but QEMU could not load it.
+```
+qemu-system-i386: Error loading uncompressed kernel without PVH ELF Note
+```
+
+When I add `-machine type=pc-i440fx-3.1`, QEMU shows `qemu: linux kernel too old to load a ram disk` or `qemu: invalid kernel header`.
+
+The multiboot file is linked with `ld.lld -s -o`.
+
+[toop](/uploads/7f230dc39d6a3a8c43c4c720d31878c6/toop)[multiboot](/uploads/59faa4607dc2837b54c89b35db6f206a/multiboot)
diff --git a/results/classifier/118/kernel/1157 b/results/classifier/118/kernel/1157
new file mode 100644
index 000000000..0c39a89c4
--- /dev/null
+++ b/results/classifier/118/kernel/1157
@@ -0,0 +1,43 @@
+architecture: 0.980
+kernel: 0.934
+register: 0.897
+graphic: 0.879
+device: 0.812
+debug: 0.800
+arm: 0.774
+semantic: 0.725
+permissions: 0.549
+performance: 0.518
+peripherals: 0.501
+files: 0.493
+vnc: 0.492
+network: 0.465
+PID: 0.453
+socket: 0.434
+boot: 0.432
+ppc: 0.401
+assembly: 0.334
+user-level: 0.317
+risc-v: 0.316
+TCG: 0.294
+hypervisor: 0.266
+VMM: 0.216
+i386: 0.134
+KVM: 0.133
+virtual: 0.093
+x86: 0.085
+mistranslation: 0.045
+
+aarch64: enabling MMU causes instruction abort
+Description of problem:
+The title describes the problem pretty accurately, we get an instruction abort when enabling the MMU with a pretty simple set of page tables. This has been regressed from qemu 6.x.
+Steps to reproduce:
+1. Run the provided Kernel binary with the command line specified above.
+2. Notice the hang after 'Initialize MMU'. I traced it down to being an instructions abort after the write to the SCTLR_EL1 register.
+3. Try to run with qemu 6.x, and notice that it works.
+Additional information:
+This does work on actual hardware, so it has to be a qemu bug.
+
+A binary of the Serenity Kernel has been attached to the issue. The source of that binary can be found at commit ca0e32e59fcf67a662e5d3a994d44cd7c941624a of [SerenityOS](https://github.com/SerenityOS/serenity).
+
+[Kernel](/uploads/f731edbf81d8e575035e9693b0a51dbf/Kernel)
diff --git a/results/classifier/118/kernel/1164 b/results/classifier/118/kernel/1164
new file mode 100644
index 000000000..50db469ce
--- /dev/null
+++ b/results/classifier/118/kernel/1164
@@ -0,0 +1,47 @@
+kernel: 0.939
+device: 0.836
+network: 0.835
+register: 0.817
+ppc: 0.772
+architecture: 0.763
+vnc: 0.746
+socket: 0.741
+arm: 0.729
+graphic: 0.684
+files: 0.675
+permissions: 0.601
+risc-v: 0.591
+semantic: 0.548
+PID: 0.546
+TCG: 0.527
+debug: 0.490
+mistranslation: 0.484
+performance: 0.481
+boot: 0.477
+x86: 0.473
+VMM: 0.402
+KVM: 0.379
+i386: 0.371
+peripherals: 0.367
+hypervisor: 0.334
+assembly: 0.278
+virtual: 0.243
+user-level: 0.153
+
+q35: incorrect values for PCIEXBAR masks
+Description of problem:
+https://lore.kernel.org/all/1fded151ce5ecbf7010427871b908000b2aba9ee.1520867956.git.x1917x@gmail.com/
+
+In function [mch_update_pciexbar](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/pci-host/q35.c#L295)
+
+There are two small issues in PCIEXBAR address mask handling:
+- wrong bit positions for address mask bits (see PCIEXBAR description
+  in Q35 datasheet)
+- incorrect usage of 64ADR_MASK
+
+Due to this, attempting to write a valid PCIEXBAR address may cause it to
+shift to another address, causing memory layout corruption where emulated
+MMIO regions may overlap real (passed through) MMIO ranges. Fix this
+by providing correct values.
+Additional information:
+Q35 datasheet: https://www.intel.com/Assets/PDF/datasheet/316966.pdf  ( 5.1.16 PCIEXBAR—PCI Express* Register Range Base Address )
diff --git a/results/classifier/118/kernel/1165 b/results/classifier/118/kernel/1165
new file mode 100644
index 000000000..f119952ef
--- /dev/null
+++ b/results/classifier/118/kernel/1165
@@ -0,0 +1,33 @@
+architecture: 0.986
+kernel: 0.930
+device: 0.839
+semantic: 0.700
+network: 0.633
+register: 0.518
+mistranslation: 0.514
+arm: 0.511
+boot: 0.499
+graphic: 0.499
+risc-v: 0.445
+socket: 0.378
+PID: 0.343
+vnc: 0.324
+files: 0.312
+permissions: 0.295
+i386: 0.263
+debug: 0.251
+VMM: 0.208
+TCG: 0.202
+virtual: 0.174
+performance: 0.170
+assembly: 0.166
+x86: 0.163
+ppc: 0.157
+user-level: 0.058
+hypervisor: 0.053
+peripherals: 0.050
+KVM: 0.035
+
+About support LoongArch architecture
+Additional information:
+Start from Linux 5.19, maybe can find the compatible source code for LoongArch in the Linux Kernel source code archive.
diff --git a/results/classifier/118/kernel/1169049 b/results/classifier/118/kernel/1169049
new file mode 100644
index 000000000..2c06b84da
--- /dev/null
+++ b/results/classifier/118/kernel/1169049
@@ -0,0 +1,57 @@
+kernel: 0.897
+graphic: 0.845
+x86: 0.808
+ppc: 0.741
+mistranslation: 0.720
+device: 0.703
+semantic: 0.667
+performance: 0.665
+files: 0.663
+user-level: 0.644
+debug: 0.629
+socket: 0.614
+network: 0.592
+architecture: 0.586
+risc-v: 0.540
+KVM: 0.533
+PID: 0.499
+vnc: 0.475
+permissions: 0.473
+arm: 0.470
+register: 0.452
+boot: 0.451
+peripherals: 0.435
+i386: 0.435
+VMM: 0.413
+hypervisor: 0.407
+TCG: 0.360
+assembly: 0.339
+virtual: 0.331
+
+do not stop on first gdb breakpoint with -enable-kvm
+
+I run qemu like this:
+  qemu-system-x86-64 -enable-kvm -hda <path to file> -s -S,
+
+and start gdb with commands like this:
+  gdb>tartget remote localhost:1234
+  gdb>break *0x7c00
+  gdb>c
+
+but gdb don't stop on it. I then could break execution manually and then breakpoints work.
+
+QEMU version: 1.4.0 (from Debian repos)
+GDB version: 7.5.1 (copiled from sources, but previous was 7.4.1 from Debian repo)
+
+PS Same problem occure on Ubuntu 13.04 with same Qemu and Gdb 7.5.0 from repo.
+
+Thank you
+
+Which Linux kernel version were you using here? Can you still reproduce this problem with the latest Linux kernel version, and the latest version of QEMU?
+
+Hello.
+
+I have forgot about this. I even unable to remember what I have done. Unfortunately I can't help you. Sorry.
+
+Ok, anyway, thanks for your reply! So let's close this ticket now...
+
diff --git a/results/classifier/118/kernel/1184 b/results/classifier/118/kernel/1184
new file mode 100644
index 000000000..5f546902f
--- /dev/null
+++ b/results/classifier/118/kernel/1184
@@ -0,0 +1,99 @@
+i386: 0.994
+TCG: 0.991
+kernel: 0.971
+x86: 0.971
+debug: 0.967
+graphic: 0.962
+files: 0.958
+architecture: 0.951
+peripherals: 0.915
+device: 0.887
+performance: 0.886
+PID: 0.862
+user-level: 0.801
+socket: 0.749
+semantic: 0.730
+network: 0.703
+KVM: 0.701
+hypervisor: 0.692
+assembly: 0.676
+ppc: 0.630
+register: 0.612
+mistranslation: 0.611
+vnc: 0.592
+permissions: 0.586
+risc-v: 0.573
+VMM: 0.565
+boot: 0.508
+arm: 0.465
+virtual: 0.355
+
+Extra SIGTRAP when breakpoint + watchpoint occur on same instruction
+Description of problem:
+If a breakpoint and watchpoint occur on the same instruction in TCG, gdb receives a breakpoint notification, a watchpoint notification, and then a SIGTRAP not corresponding to any set breakpoint/watchpoint.
+Steps to reproduce:
+Start QEMU via:
+
+```
+./qemu-system-i386 -display none -accel tcg -kernel kernel.elf -s -S
+```
+
+Here's the gdb session:
+
+```
+(gdb) file kernel.elf
+Reading symbols from kernel.elf...done.
+(gdb) tar rem :1234
+Remote debugging using :1234
+0x0000fff0 in ?? ()
+(gdb) b _start
+Breakpoint 1 at 0x10000c: file kernel.s, line 17.
+(gdb) c
+Continuing.
+
+Breakpoint 1, _start () at kernel.s:17
+17          mov eax, 3
+(gdb) b bp
+Breakpoint 2 at 0x100011: file kernel.s, line 20.
+(gdb) watch *(int*)&value
+Hardware watchpoint 3: *(int*)&value
+(gdb) c
+Continuing.
+
+Breakpoint 2, bp () at kernel.s:20
+20          mov dword ptr value, eax
+(gdb) c
+Continuing.
+
+Hardware watchpoint 3: *(int*)&value
+
+Old value = 0
+New value = 3
+done () at kernel.s:23
+23          jmp done
+(gdb) c
+Continuing.
+
+Program received signal SIGTRAP, Trace/breakpoint trap.
+done () at kernel.s:23
+23          jmp done
+```
+Additional information:
+This patch fixes it by disabling the extra debug interrupt if the CPU is already singlestepping, but I'm not certain it's the 'correct' fix?
+
+```patch
+--- a/softmmu/physmem.c
++++ b/softmmu/physmem.c
+@@ -894,7 +894,9 @@ void cpu_check_watchpoint(CPUState *cpu, vaddr addr, vaddr len,
+          * trigger after the current instruction.
+          */
+         qemu_mutex_lock_iothread();
+-        cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG);
++        if ((cpu->singlestep_enabled & SSTEP_NOIRQ) == 0) {
++            cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG);
++        }
+         qemu_mutex_unlock_iothread();
+         return;
+     }
+
+```
diff --git a/results/classifier/118/kernel/1186303 b/results/classifier/118/kernel/1186303
new file mode 100644
index 000000000..4142d7f6a
--- /dev/null
+++ b/results/classifier/118/kernel/1186303
@@ -0,0 +1,118 @@
+kernel: 0.869
+peripherals: 0.850
+graphic: 0.823
+user-level: 0.822
+socket: 0.800
+PID: 0.797
+permissions: 0.778
+architecture: 0.771
+device: 0.766
+performance: 0.761
+semantic: 0.748
+virtual: 0.745
+debug: 0.744
+x86: 0.740
+mistranslation: 0.738
+network: 0.710
+assembly: 0.710
+register: 0.699
+arm: 0.693
+risc-v: 0.687
+VMM: 0.641
+TCG: 0.641
+hypervisor: 0.619
+ppc: 0.607
+KVM: 0.602
+files: 0.587
+boot: 0.560
+vnc: 0.533
+i386: 0.383
+
+virtual fat do not working in qemu 1.5.0
+
+Guest : windows Seven / XP
+Qemu version : 1.5.0 
+cmd line : 
+-drive file=fat:floppy:/mnt/vdisk/diskconf/TEST004/,if=none,id=drive-fdc0-0-0,readonly=on 
+generated by  libvirt :
+ 
+<disk type='dir' device='floppy'>
+      <driver name='qemu' type='fat'/>
+      <source dir='/mnt/vdisk/diskconf/TEST003/'/>
+      <target dev='fda' bus='fdc'/>
+      <readonly/>
+      <alias name='fdc0-0-0'/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+
+works with qemu <= 1.4.1
+
+with qemu 1.5.0 , guest does not see the floppy content.
+
+Regards
+
+same issue with qemu 1.5.1
+floopy content is seen under linux. not under Windows guest
+
+On Fri, May 31, 2013 at 03:26:47PM -0000, prochazka nicolas wrote:
+> Public bug reported:
+> 
+> Guest : windows Seven / XP
+> Qemu version : 1.5.0 
+> cmd line : 
+> -drive file=fat:floppy:/mnt/vdisk/diskconf/TEST004/,if=none,id=drive-fdc0-0-0,readonly=on 
+> generated by  libvirt :
+>  
+> <disk type='dir' device='floppy'>
+>       <driver name='qemu' type='fat'/>
+>       <source dir='/mnt/vdisk/diskconf/TEST003/'/>
+>       <target dev='fda' bus='fdc'/>
+>       <readonly/>
+>       <alias name='fdc0-0-0'/>
+>       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+>     </disk>
+> 
+> works with qemu <= 1.4.1
+> 
+> with qemu 1.5.0 , guest does not see the floppy content.
+
+Thanks for reporting this bug.  The vvfat block driver is not actively
+maintained, but you can help us track down this bug:
+
+Since it used to work in QEMU 1.4.1 you could use git-bisect(1) to
+identify the commit that broke vvfat.
+
+http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search
+https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
+http://code-worrier.com/blog/git-bisect-basics/
+
+Something along the lines of:
+
+$ git clone git://git.qemu.org/qemu.git
+$ cd qemu
+$ git bisect start
+$ git bisect bad master
+$ git bisect good v1.4.1
+
+Then build from source and test at each bisect step:
+
+$ ./configure --target-list=x86_64-softmmu && make
+$ qemu -drive file=fat:floppy:...
+
+If it fails:
+
+$ git bisect bad
+
+If it succeeds:
+
+$ git bisect good
+
+At the end of the process it will tell you which commit broke vvfat.
+
+Stefan
+
+
+Triaging old bug tickets... Have you ever bisected the problem? Can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1241 b/results/classifier/118/kernel/1241
new file mode 100644
index 000000000..13bd09b94
--- /dev/null
+++ b/results/classifier/118/kernel/1241
@@ -0,0 +1,43 @@
+register: 0.979
+kernel: 0.942
+graphic: 0.852
+device: 0.777
+network: 0.633
+semantic: 0.552
+socket: 0.503
+mistranslation: 0.501
+vnc: 0.455
+architecture: 0.450
+ppc: 0.448
+debug: 0.395
+x86: 0.370
+arm: 0.345
+boot: 0.301
+files: 0.301
+peripherals: 0.284
+user-level: 0.281
+i386: 0.270
+performance: 0.251
+hypervisor: 0.233
+risc-v: 0.233
+TCG: 0.205
+VMM: 0.194
+PID: 0.186
+permissions: 0.174
+KVM: 0.158
+virtual: 0.151
+assembly: 0.043
+
+About showing the information of the csr
+Description of problem:
+cannot print the inforamtion after pulling the newest version of qemu
+E.g　info r csr 
+only fcsr frm fflags are shown. However , it should print out all the csrs such as mideleg mhartid etc in preivous version
+info r mip 
+(GDB) Invalid register `mip'
+Steps to reproduce:
+1.running riscv64-unknown-elf-gdb kernel 
+2.target remote to the port i set in the xv6 makefile
+3.type info r mip it shows the the probklem i mentioned above. I could use the print CSR in previous version of QEMU.
+Additional information:
+
diff --git a/results/classifier/118/kernel/1280 b/results/classifier/118/kernel/1280
new file mode 100644
index 000000000..954ec8937
--- /dev/null
+++ b/results/classifier/118/kernel/1280
@@ -0,0 +1,38 @@
+kernel: 0.941
+files: 0.924
+boot: 0.866
+device: 0.835
+architecture: 0.810
+arm: 0.809
+network: 0.741
+performance: 0.729
+graphic: 0.694
+PID: 0.693
+semantic: 0.678
+vnc: 0.602
+permissions: 0.600
+TCG: 0.574
+socket: 0.542
+debug: 0.469
+VMM: 0.467
+register: 0.464
+ppc: 0.427
+peripherals: 0.417
+x86: 0.354
+mistranslation: 0.333
+i386: 0.315
+hypervisor: 0.292
+user-level: 0.282
+risc-v: 0.203
+virtual: 0.145
+assembly: 0.075
+KVM: 0.054
+
+qemu-system-arm 7.1 can not boot my cortex-m55 image
+Steps to reproduce:
+```
+1.qemu-system-arm -cpu cortex-m55 -machine mps3-an547 -nographic -vga none -monitor none -semihosting -semihosting-config enable=on,target=native -kernel qemu_simu.elf
+2.arm-none-eabi-gdb -ex "target extended-remote localhost:1234" qemu_simu.elf
+```
+Additional information:
+[qemu_simu.tar.gz](/uploads/b8b3bf0f4868fdbb22b19027f685b4f0/qemu_simu.tar.gz)
diff --git a/results/classifier/118/kernel/1281 b/results/classifier/118/kernel/1281
new file mode 100644
index 000000000..c294f9a18
--- /dev/null
+++ b/results/classifier/118/kernel/1281
@@ -0,0 +1,31 @@
+kernel: 0.965
+debug: 0.701
+device: 0.698
+risc-v: 0.607
+vnc: 0.521
+performance: 0.473
+architecture: 0.462
+graphic: 0.457
+VMM: 0.449
+TCG: 0.390
+boot: 0.383
+PID: 0.361
+register: 0.354
+files: 0.343
+KVM: 0.271
+virtual: 0.252
+arm: 0.225
+socket: 0.213
+ppc: 0.197
+permissions: 0.123
+mistranslation: 0.078
+network: 0.077
+semantic: 0.074
+x86: 0.047
+assembly: 0.033
+user-level: 0.016
+hypervisor: 0.009
+i386: 0.007
+peripherals: 0.002
+
+xv6 kernel problem in single step mode
diff --git a/results/classifier/118/kernel/1298 b/results/classifier/118/kernel/1298
new file mode 100644
index 000000000..16b40a41e
--- /dev/null
+++ b/results/classifier/118/kernel/1298
@@ -0,0 +1,45 @@
+kernel: 0.927
+device: 0.882
+x86: 0.867
+graphic: 0.824
+semantic: 0.644
+architecture: 0.562
+PID: 0.546
+network: 0.409
+mistranslation: 0.403
+performance: 0.395
+debug: 0.346
+socket: 0.253
+ppc: 0.230
+peripherals: 0.225
+i386: 0.198
+virtual: 0.145
+register: 0.141
+VMM: 0.140
+vnc: 0.123
+TCG: 0.121
+boot: 0.096
+risc-v: 0.086
+arm: 0.076
+permissions: 0.041
+user-level: 0.040
+files: 0.030
+assembly: 0.021
+KVM: 0.012
+hypervisor: 0.010
+
+virtio-pmem not working on microvm: virtio-pmem missing request data
+Description of problem:
+When using micorvm, qemu does not "connect" the memory backend mem1 with the pmem device. 
+
+When using the first command is executed, qemu shows the following starts message:
+```
+qemu-system-x86_64: virtio-pmem missing request data 
+```
+
+and the kernel outputs following messages:
+```
+[    0.043871] nd_pmem namespace0.0: could not reserve region [mem 0x00000000-0x001fffff]
+[    0.043923] IPI shorthand broadcast: enabled
+[    0.044022] nd_pmem: probe of namespace0.0 failed with error -16
+```
diff --git a/results/classifier/118/kernel/1320 b/results/classifier/118/kernel/1320
new file mode 100644
index 000000000..dd358f262
--- /dev/null
+++ b/results/classifier/118/kernel/1320
@@ -0,0 +1,42 @@
+kernel: 0.932
+boot: 0.915
+device: 0.912
+risc-v: 0.898
+architecture: 0.897
+graphic: 0.890
+network: 0.819
+PID: 0.777
+files: 0.771
+vnc: 0.767
+permissions: 0.704
+semantic: 0.673
+VMM: 0.634
+TCG: 0.624
+register: 0.617
+assembly: 0.614
+mistranslation: 0.614
+performance: 0.609
+socket: 0.600
+ppc: 0.567
+x86: 0.563
+debug: 0.531
+arm: 0.395
+user-level: 0.387
+virtual: 0.373
+i386: 0.369
+peripherals: 0.332
+KVM: 0.247
+hypervisor: 0.182
+
+qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin"
+Description of problem:
+qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin"
+Steps to reproduce:
+1. wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.79.tar.xz
+2. sudo apt-get install crossbuild-essential-riscv64
+3. make ARCH=riscv defconfig && make ARCH=riscv menuconfig 
+4. make -j4 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- 
+5. trucate -s 128G rootfs.img && mkfs.ext4 rootfs.img
+6. sudo mount -o loop ./rootfs.img /mnt
+7. debootstrap --arch=riscv64 focal /mnt
+8. qemu-system-riscv64 -machine virt -bios default -m 512M -kernel ./linux-5.15.79/arch/riscv/boot/Image -drive file=./rootfs.img,format=raw
diff --git a/results/classifier/118/kernel/1336123 b/results/classifier/118/kernel/1336123
new file mode 100644
index 000000000..428b6a1b7
--- /dev/null
+++ b/results/classifier/118/kernel/1336123
@@ -0,0 +1,48 @@
+kernel: 0.866
+ppc: 0.795
+device: 0.746
+boot: 0.708
+graphic: 0.644
+network: 0.607
+semantic: 0.524
+architecture: 0.500
+socket: 0.449
+PID: 0.311
+vnc: 0.298
+performance: 0.296
+files: 0.289
+register: 0.279
+debug: 0.263
+permissions: 0.258
+mistranslation: 0.250
+user-level: 0.235
+hypervisor: 0.227
+peripherals: 0.197
+virtual: 0.193
+i386: 0.178
+risc-v: 0.171
+arm: 0.162
+x86: 0.158
+VMM: 0.149
+assembly: 0.109
+TCG: 0.094
+KVM: 0.089
+
+bad switch, segfault in hw/pci-host/bonito.c bonito_readl
+
+http://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci-host/bonito.c;h=56292adb03cd1a9873c2c9e5a0b2978fd0572214;hb=master#l301
+
+The switch statement is error-prone, since two branches return the same result.
+
+Segfault reproducing steps:
+1. make a Linux kernel(for example 3.16.0-rc2) with fuloong2e_defconfig
+2. use 'qemu-system-mips64el -machine fulong2e' to boot the vmlinux
+
+qemu versions tried: 2.0.0, 1.6.2
+
+I think this might have been fixed with this commit here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0ca4f94195cce77b624ed
+Or can you still reproduce it with the current version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1392 b/results/classifier/118/kernel/1392
new file mode 100644
index 000000000..db15e7028
--- /dev/null
+++ b/results/classifier/118/kernel/1392
@@ -0,0 +1,44 @@
+kernel: 0.893
+device: 0.865
+peripherals: 0.832
+graphic: 0.814
+architecture: 0.663
+PID: 0.531
+hypervisor: 0.516
+performance: 0.464
+semantic: 0.460
+VMM: 0.423
+permissions: 0.416
+risc-v: 0.388
+debug: 0.361
+mistranslation: 0.361
+network: 0.350
+ppc: 0.342
+boot: 0.339
+x86: 0.321
+i386: 0.273
+vnc: 0.247
+TCG: 0.222
+files: 0.209
+KVM: 0.203
+arm: 0.191
+register: 0.169
+user-level: 0.161
+socket: 0.145
+virtual: 0.114
+assembly: 0.069
+
+qemu 7.2.0 almalinux 9.1 guest  vda io error
+Description of problem:
+after update the qemu from 7.1.0 to 7.2.0 guest almalinux 9.1  have disk io error ,log :
+```log
+Dec 24 00:17:39 rlh1 kernel: I/O error, dev vda, sector 109770720 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
+Dec 24 00:17:42 rlh1 kernel: dm-0: writeback error on inode 33585275, offset 4096, sector 33359840
+Dec 24 00:17:42 rlh1 kernel: I/O error, dev vda, sector 109770776 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
+Dec 24 00:17:42 rlh1 kernel: dm-0: writeback error on inode 33585275, offset 4096, sector 33359896
+Dec 24 00:17:42 rlh1 kernel: I/O error, dev vda, sector 109770832 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
+```
+
+then I switch back to version 7.1.0  it work as normal
+Additional information:
+
diff --git a/results/classifier/118/kernel/1426092 b/results/classifier/118/kernel/1426092
new file mode 100644
index 000000000..852ad1a2e
--- /dev/null
+++ b/results/classifier/118/kernel/1426092
@@ -0,0 +1,70 @@
+kernel: 0.878
+PID: 0.819
+device: 0.807
+boot: 0.780
+performance: 0.776
+graphic: 0.750
+architecture: 0.725
+x86: 0.724
+arm: 0.709
+ppc: 0.642
+socket: 0.619
+vnc: 0.567
+debug: 0.529
+network: 0.527
+semantic: 0.492
+register: 0.482
+permissions: 0.473
+user-level: 0.470
+i386: 0.466
+TCG: 0.451
+hypervisor: 0.444
+VMM: 0.415
+peripherals: 0.398
+risc-v: 0.390
+virtual: 0.347
+mistranslation: 0.329
+assembly: 0.248
+KVM: 0.230
+files: 0.163
+
+virtio-balloon-device locks up Guest
+
+Setting arbitrary balloon target values locks up the guest in some cases crashes it, if the target memory is < used +~5% free.  
+Found while testing aggressive memory over-commit, scenarios.
+You get messages like:
+
+[  155.827448] [<c002060c>] (show_stack) from [<c041c518>] (dump_stack+0x6c/0x88)
+[  155.837076] [<c041c518>] (dump_stack) from [<c0091994>] (warn_alloc_failed+0xe0/0x120)
+[  155.847075] [<c0091994>] (warn_alloc_failed) from [<c0094480>] (__alloc_pages_nodemask+0x600/0x91c)
+[  155.859039] [<c0094480>] (__alloc_pages_nodemask) from [<c00da414>] (balloon_page_enqueue+0x20/0xbc)
+[  155.870556] [<c00da414>] (balloon_page_enqueue) from [<c025d794>] (balloon+0x140/0x2cc)
+[  155.881377] [<c025d794>] (balloon) from [<c0043b38>] (kthread+0xd8/0xf4)
+
+page dumped bacause: nonzero _count
+BUG: BAad page state in process Xorg pfn:396e5
+
+Test Environment:
+x86_64
+Ubuntu 13.10, Guest Linux Kernel 3.19, qemu 2.2.0 with following patches applied - balloon OOM enhancement
+commit 5a10b7dbf904bfe01bb9fcc6298f7df09eed77d5
+Author: Raushaniya Maksudova <email address hidden>
+
+Boot guest with '-balloon virtio', -qmp .... -hmp access
+1. sudo info balloon | socat - tcp4-connect:127.0.0.1:4444
+   - or over qmp interface
+{"execute":"qom-get", "arguments": { "path": "/machine/peripheral-anon/device[1]","property": "guest-stats" }}
+{"return": {"stats": {"stat-swap-out": 0, "stat-free-memory": 513454080, "stat-minor-faults": 1261, "stat-major-faults": 0, "stat-total-memory": 526073856, "stat-swap-in": 0}, "last-update": 11109}}
+
+2. Take memory down check free memory using (1)
+3. Issue "sudo echo balloon XXX | socat - tcp4-connect:127.0.0.1:4444" - XXX is value in threshold mentioned above
+   and you get Guest lockup
+
+ARM - samething except '-device virtio-balloon-device' used
+
+Libvirt - virsh setmem causes same issue.
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? ... anyway, this rather sounds like a bug with the guest kernel to me, so in case this problem persists, you likely should report this in the kernel bug tracker instead.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1461918 b/results/classifier/118/kernel/1461918
new file mode 100644
index 000000000..ca4283f64
--- /dev/null
+++ b/results/classifier/118/kernel/1461918
@@ -0,0 +1,53 @@
+kernel: 0.949
+x86: 0.946
+files: 0.941
+device: 0.924
+vnc: 0.891
+performance: 0.882
+boot: 0.878
+peripherals: 0.848
+architecture: 0.843
+network: 0.820
+graphic: 0.815
+hypervisor: 0.730
+PID: 0.707
+permissions: 0.702
+socket: 0.690
+register: 0.656
+virtual: 0.639
+semantic: 0.614
+VMM: 0.606
+debug: 0.589
+mistranslation: 0.567
+user-level: 0.566
+ppc: 0.509
+i386: 0.376
+risc-v: 0.350
+assembly: 0.304
+TCG: 0.280
+arm: 0.221
+KVM: 0.202
+
+guest hangs after use ethtool to set scatter-gather on
+
+On the guests,  i have a rtl8139 nic,  I use ethtool to set  scatter-gather on ( ethtool -K eth0 sg on ),
+after that,   at host side,  I  use scp to send a file into guest.  As a result, guest hang.
+At that point qemu is using 100% of one host CPU, about 100% guest.
+
+If guest is centOS6.5， with no problem.
+
+
+
+The guest system is Fedora release 19(Kernel 3.11.10-200.fc19.x86_64).
+
+host system is debian 7.1.
+Kernel:3.10.0
+Qemu: 2.3.0
+
+cmd:
+/boot/qemu-2.3.0-bin/qemu-system-x86_64 -vnc :13 -enable-kvm -name fedora -smp sockets=1,cores=2 -cpu core2duo -nodefaults -vga cirrus -k en-us -boot menu=on,splash-time=8000 -m 2048 -usb -drive file=/boot/vm-disk-1.qcow2,if=none,id=drive-ide0,cache=none,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 -netdev type=tap,id=net0,ifname=200,script=/etc/kvm/vtp-bridge -device rtl8139,romfile=,mac=FE:FC:FE:5C:58:65,netdev=net0,bus=pci.0,addr=0x12,id=net0
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU and Fedora? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1462 b/results/classifier/118/kernel/1462
new file mode 100644
index 000000000..b4326ee2b
--- /dev/null
+++ b/results/classifier/118/kernel/1462
@@ -0,0 +1,44 @@
+kernel: 0.946
+network: 0.913
+graphic: 0.909
+device: 0.896
+boot: 0.892
+vnc: 0.833
+virtual: 0.798
+peripherals: 0.789
+socket: 0.770
+user-level: 0.718
+architecture: 0.706
+PID: 0.691
+files: 0.690
+permissions: 0.585
+semantic: 0.547
+debug: 0.545
+VMM: 0.522
+performance: 0.514
+register: 0.454
+x86: 0.434
+ppc: 0.407
+TCG: 0.364
+mistranslation: 0.327
+risc-v: 0.297
+hypervisor: 0.290
+arm: 0.286
+i386: 0.282
+KVM: 0.079
+assembly: 0.063
+
+qemu-system-m68k segfaults on opcode 0x4848
+Description of problem:
+Running an m68k executable with opcode 0x4848 will segfault qemu-system-m68k
+Steps to reproduce:
+1. Boot m68k debian
+2. Compile program (see above for the oops.c source) that executes opcode 0x4848
+3. Run program
+4. QEMU segfaults:
+
+```
+./debian-m68k.sh: line 10:  4420 Segmentation fault      (core dumped) qemu-system-m68k -boot c -M q800 -serial none -serial mon:stdio -m 1000M -net nic,model=dp83932,addr=08:00:07:12:34:89 -net user -append "root=/dev/sda2 rw console=ttyS0 console=tty" -kernel virt/vmlinux-4.16.0-1-m68k -initrd virt/initrd.img-4.16.0-1-m68k -drive file=virt/debian-m68k-deb10.qcow2,format=qcow2 -nographic
+```
+Additional information:
+
diff --git a/results/classifier/118/kernel/1543057 b/results/classifier/118/kernel/1543057
new file mode 100644
index 000000000..188b06a8b
--- /dev/null
+++ b/results/classifier/118/kernel/1543057
@@ -0,0 +1,58 @@
+kernel: 0.959
+architecture: 0.940
+ppc: 0.922
+device: 0.903
+mistranslation: 0.871
+semantic: 0.862
+graphic: 0.860
+PID: 0.779
+user-level: 0.745
+x86: 0.739
+network: 0.737
+hypervisor: 0.696
+i386: 0.694
+peripherals: 0.691
+register: 0.686
+files: 0.658
+permissions: 0.655
+socket: 0.640
+TCG: 0.591
+risc-v: 0.591
+arm: 0.584
+VMM: 0.577
+debug: 0.577
+performance: 0.561
+virtual: 0.544
+KVM: 0.497
+boot: 0.490
+vnc: 0.458
+assembly: 0.452
+
+Warnings are treated as errors
+
+System: Ubuntu 14.04, 32bit
+Kernel: 3.13.0-55-generic
+Qemu: v. 2.2.50
+
+Error msg:
+
+hw/acpi/pcihp.c: In function ‘acpi_pcihp_pc_no_hotplug’:
+hw/acpi/pcihp.c:117:34: error: ‘PCIDevice’ has no member named ‘qdev’
+     return (pc->is_bridge && !dev->qdev.hotplugged) || !dc->hotpluggable;
+                                  ^
+hw/acpi/pcihp.c:118:1: error: control reaches end of non-void function [-Werror=return-type]
+ }
+ ^
+cc1: all warnings being treated as errors
+
+I have same error "PCIDevice has no member named 'qdev'" with you.
+Did you find any solutions to this error?
+
+(a) That warnings are treated as errors  is a feature, not a bug (it happens for development builds only)
+(b) the definition of struct PCIDevice in include/hw/pci/pci.h starts with "DeviceState qdev;" so it's not clear to me how that error could be produced in the first place
+
+I see the original submitter was using 2.2.50 -- I suggest using either (a) a release build of QEMU or (b) current master. 2.2.50 will be from somewhere on trunk between 2.2 and 2.3, so might quite possibly have had a build bug that was quickly fixed subsequently.
+
+
+Closing this as invalid - unless you can reproduce this with the latest release version or the current master branch again, then please feel free to open this ticket again.
+
diff --git a/results/classifier/118/kernel/1552 b/results/classifier/118/kernel/1552
new file mode 100644
index 000000000..c357e93f8
--- /dev/null
+++ b/results/classifier/118/kernel/1552
@@ -0,0 +1,45 @@
+kernel: 0.931
+graphic: 0.898
+arm: 0.836
+architecture: 0.770
+device: 0.639
+mistranslation: 0.604
+semantic: 0.526
+VMM: 0.522
+performance: 0.463
+i386: 0.404
+peripherals: 0.378
+register: 0.365
+permissions: 0.321
+debug: 0.320
+user-level: 0.310
+socket: 0.293
+vnc: 0.293
+virtual: 0.292
+network: 0.272
+hypervisor: 0.254
+x86: 0.248
+ppc: 0.231
+risc-v: 0.202
+PID: 0.190
+boot: 0.177
+TCG: 0.151
+KVM: 0.114
+files: 0.061
+assembly: 0.047
+
+newer version(>=5.2.0) of qemu-system-aarch64 cannot debug arm64 linux kernel
+Description of problem:
+
+Steps to reproduce:
+1. Run QEMU in on teminal.
+2. Run gdb-multiarch in another terminal, for example: gdb-multiarch ./linux-5.10.4/vmlinux
+3. In gdb-multiarch, enter three commands in sequence："target remote localhost:1234"、"b do_sys_open"、"continue"
+4. GDB breakpoint cannot take effect
+5. If using qemu-system-aarch64 5.0.0(manually compiled)，GDB breakpoint can take effect.
+Additional information:
+I tested this problem using different combinations：  
+Host Os：Ubuntu18/Ubuntu20/Ubuntu22  
+ARM64 Linux Kernel: 5.4.50/5.10.4  
+QEMU：qemu 2.11/qemu 4.2/qemu 5.0/qemu 5.2/qemu 6.2/qemu 7  
+Finally, I found out that arm64 linux kernel cannot be debugged since qemu-system-aarch64 5.2.0.
diff --git a/results/classifier/118/kernel/1568589 b/results/classifier/118/kernel/1568589
new file mode 100644
index 000000000..91552c05a
--- /dev/null
+++ b/results/classifier/118/kernel/1568589
@@ -0,0 +1,81 @@
+i386: 0.993
+x86: 0.962
+architecture: 0.957
+kernel: 0.945
+device: 0.917
+graphic: 0.909
+semantic: 0.851
+user-level: 0.846
+files: 0.827
+PID: 0.813
+mistranslation: 0.714
+debug: 0.711
+register: 0.710
+permissions: 0.681
+socket: 0.663
+network: 0.646
+performance: 0.633
+ppc: 0.633
+peripherals: 0.631
+hypervisor: 0.596
+vnc: 0.585
+TCG: 0.568
+arm: 0.551
+risc-v: 0.547
+boot: 0.526
+VMM: 0.493
+virtual: 0.491
+assembly: 0.360
+KVM: 0.093
+
+Compile for os x host failed
+
+Hello QEMU,
+
+I try compile qemu from git pulled by me today and have a troubles:
+
+ GEN   trace/generated-helpers.c
+  CC    aarch64-softmmu/trace/generated-helpers.o
+  LINK  aarch64-softmmu/qemu-system-aarch64
+Undefined symbols for architecture x86_64:
+  "_event_notifier_init_fd", referenced from:
+      _process_msg in ivshmem.o
+ld: symbol(s) not found for architecture x86_64
+clang: error: linker command failed with exit code 1 (use -v to see invocation)
+make[1]: *** [qemu-system-aarch64] Error 1
+make: *** [subdir-aarch64-softmmu] Error 2
+
+Host: 
+# uname -a
+Darwin MacBook-Pro 15.4.0 Darwin Kernel Version 15.4.0: Fri Feb 26 22:08:05 PST 2016; root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64
+
+# ./configure
+Configure: http://pastebin.com/L9ytLFDE
+
+# make -v
+GNU Make 3.81
+Copyright (C) 2006  Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.
+There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
+PARTICULAR PURPOSE.
+
+This program built for i386-apple-darwin11.3.0
+
+Also for i386
+
+  LINK  i386-softmmu/qemu-system-i386
+Undefined symbols for architecture x86_64:
+  "_event_notifier_init_fd", referenced from:
+      _process_msg in ivshmem.o
+ld: symbol(s) not found for architecture x86_64
+clang: error: linker command failed with exit code 1 (use -v to see invocation)
+make[1]: *** [qemu-system-i386] Error 1
+make: *** [subdir-i386-softmmu] Error 2
+
+fix: http://patchwork.ozlabs.org/patch/603499/
+
+According to the discussion for the patch that you've mentioned, the problem should go away after a "make distclean". Can you still reproduce it after doing a fresh build?
+
+Closing this bug since the submitter never responded to Thomas' query in comment #4 in 2016, and we believe it to have been a transient issue fixed by 'make distclean'.
+
+
diff --git a/results/classifier/118/kernel/1585 b/results/classifier/118/kernel/1585
new file mode 100644
index 000000000..385b0d0d4
--- /dev/null
+++ b/results/classifier/118/kernel/1585
@@ -0,0 +1,57 @@
+kernel: 0.950
+graphic: 0.813
+device: 0.699
+architecture: 0.683
+files: 0.618
+ppc: 0.520
+vnc: 0.501
+boot: 0.445
+risc-v: 0.437
+semantic: 0.430
+hypervisor: 0.380
+socket: 0.349
+permissions: 0.299
+arm: 0.283
+network: 0.278
+performance: 0.275
+x86: 0.273
+VMM: 0.266
+peripherals: 0.261
+TCG: 0.248
+PID: 0.234
+register: 0.225
+KVM: 0.181
+i386: 0.155
+debug: 0.119
+user-level: 0.108
+mistranslation: 0.054
+assembly: 0.024
+virtual: 0.010
+
+Incorrect VGA text mode rendering
+Description of problem:
+All of my physical machines use black as `DarkGray` and have the text starting from `White+DarkGray` blink (watch the video below). The ISO I'm using is a minimal kernel I've written to check VGA text mode (provided by the BIOS at `0xb8000` with a 80x25 resolution) handling on multiple emulators and machines.
+Changing the emulated CPU and display driver doesn't change this behaviour.
+
+Hyper-V: color test shows correct colors, all text starting from `White+DarkGray` is blinking
+
+![Hyper-V](/uploads/0d6e9a2398d0f5aeca94e6fbbc31e055/image.png)
+
+AMD Athlon 64 X2 6000+ + NVIDIA Quadro 400 on actual hardware: same as Hyper-V
+I've tested this with multiple physical GPUs and they all have the same behaviour and color palette.
+
+![AMD Athlon 64 X2 6000+ + NVIDIA Quadro 400](/uploads/883484cea78f8d598634ebab3645341c/image.png)
+
+QEMU: dark gray is the wrong color and the text doesn't blink
+Changing the emulated device doesn't change this behaviour.
+
+![QEMU](/uploads/cf1e6a1e7e8bcfc48b60bd92d9024de5/image.png)
+
+I think QEMU should emulate the hardware as close as possible and therefore atleast have the blinking text.
+Consider this a low priority issue.
+Steps to reproduce:
+1. Download ISO from the link above
+2. Run the QEMU command above
+3. See the text not blink
+Additional information:
+![Demo of various machines](/uploads/9de70ecd2185bdb57b3ee324fe18dcd9/2023-04-08_04-56-05.mp4)
diff --git a/results/classifier/118/kernel/1624726 b/results/classifier/118/kernel/1624726
new file mode 100644
index 000000000..76636a558
--- /dev/null
+++ b/results/classifier/118/kernel/1624726
@@ -0,0 +1,70 @@
+kernel: 0.938
+architecture: 0.916
+boot: 0.775
+ppc: 0.765
+graphic: 0.763
+arm: 0.760
+mistranslation: 0.757
+performance: 0.743
+hypervisor: 0.712
+user-level: 0.663
+socket: 0.660
+peripherals: 0.639
+x86: 0.638
+network: 0.638
+debug: 0.624
+semantic: 0.606
+files: 0.602
+device: 0.588
+KVM: 0.485
+vnc: 0.451
+virtual: 0.447
+i386: 0.427
+PID: 0.419
+TCG: 0.393
+register: 0.388
+VMM: 0.377
+permissions: 0.375
+risc-v: 0.356
+assembly: 0.295
+
+Integrator/CP regression after QOM'ification of integratorcp.c
+
+The following command line no longer works (i.e. the guest does not boot) with QEMU 2.7.0:
+
+    qemu-system-arm -M integratorcp -m 128M -kernel HelenOS-0.6.0-arm32-integratorcp.boot
+
+The HelenOS image can be downloaded here:
+
+    http://www.helenos.org/releases/HelenOS-0.6.0-arm32-integratorcp.boot
+
+I did git bisect and came to this revision:
+
+a1f42e0c9abc1028a8bb8686dbb3749fcd2d18e8 is the first bad commit
+commit a1f42e0c9abc1028a8bb8686dbb3749fcd2d18e8
+Author: xiaoqiang.zhao <zxq_yx_007@163.com>
+Date:   Mon Mar 7 15:05:44 2016 +0800
+
+    hw/arm: QOM'ify integratorcp.c
+    
+    * Drop the use of old SysBus init function and use instance_init
+    * Remove the empty 'icp_pic_class_init' from Typeinfo
+    
+    Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com>
+    Reviewed-by: Peter Maydell <email address hidden>
+    Signed-off-by: Peter Maydell <email address hidden>
+
+:040000 040000 b73418ea3fb69ed72438776e78786456fe4c414c b483e8579037fdae7d136b2f4ada3147bdde92f1 M	hw
+
+Upon closer inspection, I discovered that for some reason s->memsz in integratorcm_init() is zero. In the last good revision, this value was 128. As a temporary workaround, hardcoding it to this expected value fixes the problem.
+
+Turns out integratorcm_init() depends on the memsz property being already set, but that unfortunately is not the case as setting of memsz depends on integratorcm_init() having completed:
+
+    dev = qdev_create(NULL, TYPE_INTEGRATOR_CM);            <= calls integratorcm_init(), needs memsz
+    qdev_prop_set_uint32(dev, "memsz", ram_size >> 20);     <= memsz set here, needs dev
+
+
+Patch has been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e9d9ee234f852026d58
+... and been released with QEMU version 2.8
+
diff --git a/results/classifier/118/kernel/1639791 b/results/classifier/118/kernel/1639791
new file mode 100644
index 000000000..63e7008f7
--- /dev/null
+++ b/results/classifier/118/kernel/1639791
@@ -0,0 +1,63 @@
+kernel: 0.933
+x86: 0.865
+device: 0.861
+user-level: 0.856
+KVM: 0.804
+graphic: 0.775
+vnc: 0.753
+debug: 0.747
+files: 0.739
+performance: 0.666
+peripherals: 0.663
+semantic: 0.617
+architecture: 0.593
+PID: 0.592
+network: 0.586
+permissions: 0.582
+ppc: 0.557
+register: 0.555
+mistranslation: 0.544
+virtual: 0.530
+hypervisor: 0.496
+boot: 0.487
+risc-v: 0.433
+i386: 0.413
+TCG: 0.411
+VMM: 0.409
+socket: 0.398
+assembly: 0.394
+arm: 0.335
+
+early virtio console output is lost
+
+This is broken in git and reportedly in 2.5 through 2.7.
+
+Running a Linux kernel which includes a testsuite in initrd sometimes produces no output.
+
+Reportedly the console is sometimes not open when the early userspace tries to log output resulting in either the testsuite terminating early or not writing the output.
+
+Workaround patch is here:
+
+https://git.zx2c4.com/WireGuard/commit/?id=d2de8b0862a7fbb51a7f2f958d58f0efe4648259
+
+reportedly you would get -EBADF there when no output is generated.
+
+Also this reportedly happens with virtio console only, not virtio serial port.
+
+It seems that the author of said testsuite did not report the problem so I write it down so it does not get lost.
+
+test (in bash):
+
+n=0 ; while [ $n -lt 100 ] && grep -m 1 -F "WireGuard Test Suite on Linux 4.8.6" <( /opt/qemu/bin/qemu-system-x86_64         -nodefaults         -nographic         -machine q35,accel=kvm         -cpu host         -smp 2         -m 64M         -object rng-random,id=rng0,filename=/dev/urandom         -device virtio-rng-pci,rng=rng0         -device virtio-serial,max_ports=2         -chardev stdio,id=stdio         -device virtconsole,chardev=stdio         -chardev file,id=status,path=result.txt         -device virtserialport,chardev=status         -monitor none         -kernel wireguard-testing-harness-bzImage-e87cb2a7-145c-4985-907f-17e81fae329b         -append "console=hvc0 initcall_debug=1 loglevel=7" ) ; do echo $n ; n=$(expr $n + 1) ; pkill -f wireguard ; done
+
+This typically does 10-20 iterations but sometimes tens of iterations run without issue.
+
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to
+"Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1650 b/results/classifier/118/kernel/1650
new file mode 100644
index 000000000..af1d56bc5
--- /dev/null
+++ b/results/classifier/118/kernel/1650
@@ -0,0 +1,44 @@
+i386: 0.969
+kernel: 0.938
+x86: 0.893
+performance: 0.872
+device: 0.836
+architecture: 0.812
+graphic: 0.772
+network: 0.750
+semantic: 0.731
+debug: 0.675
+virtual: 0.643
+PID: 0.551
+vnc: 0.487
+permissions: 0.483
+hypervisor: 0.428
+mistranslation: 0.424
+TCG: 0.420
+VMM: 0.413
+risc-v: 0.390
+ppc: 0.367
+boot: 0.348
+register: 0.318
+peripherals: 0.315
+user-level: 0.299
+socket: 0.283
+KVM: 0.226
+arm: 0.209
+files: 0.130
+assembly: 0.120
+
+Consider doing runtime detection of MAP_FIXED_NOREPLACE
+Description of problem:
+```
+qemu-i386-static: Unable to reserve 0xfffff000 bytes of virtual address space at 0x1000 (Operation not supported) for use as guest address space (check your virtual memory ulimit setting, min_mmap_addr or reserve less using -R option)
+```
+strace says
+```
+ mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE|MAP_FIXED_NOREPLACE, -1, 0) = -1 EOPNOTSUPP (Operation not supported)
+```
+Steps to reproduce:
+1. `apt install qemu-i386-static 32subsystem`
+2. `strace qemu-i386-static /opt/32/bin/as`
+Additional information:
+Repeating the strace call in a minimal C program gives the same errno as expected -- the kernel is only 4.4. The problem here is that qemu only does `MAP_FIXED_NOREPLACE` feature detection at build-time via a `#ifndef` and even that behavior is poorly documented. Maybe do something at runtime?
diff --git a/results/classifier/118/kernel/1654826 b/results/classifier/118/kernel/1654826
new file mode 100644
index 000000000..80e0b37ea
--- /dev/null
+++ b/results/classifier/118/kernel/1654826
@@ -0,0 +1,58 @@
+kernel: 0.939
+peripherals: 0.926
+performance: 0.920
+graphic: 0.918
+architecture: 0.911
+device: 0.900
+KVM: 0.885
+user-level: 0.856
+hypervisor: 0.855
+semantic: 0.825
+VMM: 0.813
+vnc: 0.810
+mistranslation: 0.776
+x86: 0.775
+register: 0.723
+ppc: 0.706
+virtual: 0.684
+i386: 0.678
+debug: 0.676
+permissions: 0.670
+boot: 0.669
+PID: 0.668
+network: 0.668
+files: 0.647
+socket: 0.644
+assembly: 0.596
+risc-v: 0.576
+arm: 0.542
+TCG: 0.506
+
+Holding key down using input-linux freezes guest
+
+Qemu release version 2.8.0
+KVM, kernel 4.9.1
+
+When using the -object input-linux capability in qemu for passthrough of input/evdev devices, I found that when a key is held for a few seconds or more (such as ctrl key), the guest system freezes until the key is released. In some cases, mouse control is also lost following one of these "freezes". I also noticed that one of the four cpu cores I have the guest pinned to ramps to 100% during these freezes.
+
+Thought I might add:
+
+The qemu command line option equivalents for mouse and keyboard:
+
+-object input-linux,id=kbd,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd,repeat=on,grab_all=on \
+-object input-linux,id=ms1,evdev=/dev/input/by-id/usb-ROCCAT_ROCCAT_Kone_Pure-event-mouse
+
+quick workaround: drop "repeat=on".
+some guests seem to have problems with that, not debugged yet why.
+
+I have tried without "repeat=on" option, and with 2.8.0 I still seem to be getting weird behavior with mouse dropping out at points, and with keys seemingly being continued to be pressed (ie still running around in an fps game after releasing the key). I also experienced at one point l-ctrl+r-ctrl not passing keyboard control to guest, and needed to VNC in to shutdown/restart guest (this was after plugging in a usb xbox360 controller, not sure if related).
+
+I am getting the same issue where I can even hear the sound glitch out. I'm on Arch Linux.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to
+"Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1694998 b/results/classifier/118/kernel/1694998
new file mode 100644
index 000000000..e41ba96ac
--- /dev/null
+++ b/results/classifier/118/kernel/1694998
@@ -0,0 +1,79 @@
+architecture: 0.934
+kernel: 0.933
+ppc: 0.928
+TCG: 0.926
+user-level: 0.872
+permissions: 0.838
+PID: 0.833
+device: 0.830
+network: 0.825
+peripherals: 0.810
+performance: 0.803
+graphic: 0.795
+socket: 0.792
+semantic: 0.758
+mistranslation: 0.749
+arm: 0.737
+x86: 0.719
+files: 0.715
+boot: 0.706
+debug: 0.691
+vnc: 0.688
+KVM: 0.667
+risc-v: 0.661
+VMM: 0.643
+hypervisor: 0.622
+register: 0.608
+i386: 0.489
+virtual: 0.486
+assembly: 0.444
+
+PPC: msgsnd instruction leads to assertion
+
+I tried to send doorbells (using msgsnd) between cores in guest OS. On QEMU v2.9.0 usage of msgsnd instruction leads to error:
+ERROR: <...>/qemu-new/translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())
+
+
+QEMU v2.8.0 works fine.
+
+QEMU run options: qemu-system-ppc -serial stdio -M ppce500 -cpu e500mc -smp 2 -m 512M -kernel pok.elf
+
+pok.elf attached
+
+
+
+Could you please check whether this patch fixes the issue for you:
+
+diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
+--- a/target/ppc/excp_helper.c
++++ b/target/ppc/excp_helper.c
+@@ -17,6 +17,7 @@
+  * License along with this library; if not, see <http://www.gnu.org/licenses/>.
+  */
+ #include "qemu/osdep.h"
++#include "qemu/main-loop.h"
+ #include "cpu.h"
+ #include "exec/helper-proto.h"
+ #include "exec/exec-all.h"
+@@ -1132,6 +1133,7 @@ void helper_msgsnd(target_ulong rb)
+         return;
+     }
+ 
++    qemu_mutex_lock_iothread();
+     CPU_FOREACH(cs) {
+         PowerPCCPU *cpu = POWERPC_CPU(cs);
+         CPUPPCState *cenv = &cpu->env;
+@@ -1141,5 +1143,6 @@ void helper_msgsnd(target_ulong rb)
+             cpu_interrupt(cs, CPU_INTERRUPT_HARD);
+         }
+     }
++    qemu_mutex_unlock_iothread();
+ }
+ #endif
+
+
+Yes, Thomas, this patch fixes the issue.
+
+Fix has now been included:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f1c29ebc51be77bd64178c8d
+
diff --git a/results/classifier/118/kernel/1695286 b/results/classifier/118/kernel/1695286
new file mode 100644
index 000000000..fe97fb37d
--- /dev/null
+++ b/results/classifier/118/kernel/1695286
@@ -0,0 +1,54 @@
+kernel: 0.829
+semantic: 0.685
+graphic: 0.685
+user-level: 0.629
+device: 0.622
+i386: 0.577
+network: 0.576
+architecture: 0.575
+PID: 0.569
+permissions: 0.544
+performance: 0.543
+register: 0.537
+hypervisor: 0.531
+files: 0.524
+boot: 0.512
+x86: 0.505
+ppc: 0.495
+peripherals: 0.475
+vnc: 0.472
+mistranslation: 0.451
+debug: 0.446
+risc-v: 0.445
+socket: 0.432
+KVM: 0.423
+VMM: 0.421
+TCG: 0.370
+virtual: 0.340
+assembly: 0.339
+arm: 0.294
+
+Add multiboot2 support
+
+multiboot2 is a recent specification that resolves some of the issues of multiboot. Multiboot2 is supported by some tools already (e.g. grub).
+
+It would be great if one can run OS with multiboot2 using '-kernel' option, similar as it is done now with multiboot images.
+
+Quick googling shows there is a Debian bug and patch that adds multiboot support https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621529 Would it be possible to integrate it to QEMU upstream?
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+Marking new to migrate to the new bug tracker.
+
+It would be really great to see this in QEMU!
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/389
+
+
diff --git a/results/classifier/118/kernel/1696 b/results/classifier/118/kernel/1696
new file mode 100644
index 000000000..6a59af88f
--- /dev/null
+++ b/results/classifier/118/kernel/1696
@@ -0,0 +1,69 @@
+kernel: 0.865
+x86: 0.814
+architecture: 0.736
+boot: 0.708
+performance: 0.676
+device: 0.664
+files: 0.593
+debug: 0.492
+graphic: 0.480
+semantic: 0.428
+user-level: 0.421
+ppc: 0.407
+peripherals: 0.376
+risc-v: 0.347
+PID: 0.343
+vnc: 0.318
+network: 0.315
+hypervisor: 0.303
+socket: 0.296
+TCG: 0.295
+i386: 0.263
+VMM: 0.260
+register: 0.253
+permissions: 0.216
+virtual: 0.214
+arm: 0.174
+assembly: 0.096
+KVM: 0.073
+mistranslation: 0.050
+
+Linux kernel hangs rarely when booting on the latest qemu
+Description of problem:
+(Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=2213346)
+
+In Fedora we have noticed that the latest Linux kernel (rarely) hangs when booting
+on the latest qemu.  It hangs after printing:
+
+```
+[    0.070120] x86/cpu: User Mode Instruction Prevention (UMIP) activated
+[    0.070120] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
+[    0.070120] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
+[    0.070120] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
+[    0.070120] Spectre V2 : Mitigation: Retpolines
+[    0.070120] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
+[    0.070120] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
+[    0.070120] Spectre V2 : Enabling Speculation Barrier for firmware calls
+[    0.070120] RETBleed: Mitigation: untrained return thunk
+[    0.070120] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
+[    0.070120] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
+[    0.070120] Freeing SMP alternatives memory: 48K
+```
+
+The next line which would be printed (if it didn't hang) is:
+
+```
+[    0.070794] smpboot: CPU0: AMD Ryzen 9 3900X 12-Core Processor (family: 0x17, model: 0x71, stepping: 0x0)
+```
+
+We've seen this hang on both AMD and Intel.  It probably happens one in every 300 boots.
+Steps to reproduce:
+By far the easiest way to reproduce this is to just run guestfish in a loop:
+
+```
+$ while guestfish -a /dev/null -v run >& /tmp/log; do echo -n . ; done 
+```
+Additional information:
+The full qemu command is rather long but you can find it in this log file:
+
+https://bugzilla-attachments.redhat.com/attachment.cgi?id=1969620
diff --git a/results/classifier/118/kernel/1724 b/results/classifier/118/kernel/1724
new file mode 100644
index 000000000..3a6b4c84d
--- /dev/null
+++ b/results/classifier/118/kernel/1724
@@ -0,0 +1,75 @@
+kernel: 0.977
+device: 0.973
+socket: 0.949
+virtual: 0.948
+debug: 0.944
+files: 0.943
+permissions: 0.918
+graphic: 0.914
+peripherals: 0.913
+risc-v: 0.906
+boot: 0.901
+user-level: 0.875
+network: 0.868
+performance: 0.854
+vnc: 0.818
+PID: 0.800
+register: 0.757
+semantic: 0.708
+arm: 0.649
+ppc: 0.644
+architecture: 0.628
+VMM: 0.597
+mistranslation: 0.594
+x86: 0.525
+hypervisor: 0.406
+TCG: 0.358
+assembly: 0.220
+KVM: 0.196
+i386: 0.132
+
+qemu-system-riscv64 can't break by gdb
+Description of problem:
+The qemu-system-riscv64 can't break by gdb.  
+( => The target is not responding to interrupt requests.  
+Stop debugging it? (y or n) Quit)  
+
+I using old qemu-system-risc64(7.2) don't has this issue.  
+
+This test case running simple OS(riscv-xv6).
+Steps to reproduce:
+1.qemu-system-riscv64 -machine virt -bios none -kernel kernel/kernel -m 128M -smp 3 -nographic -global   virtio-mmio.force-legacy=false -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk-  device,drive=x0,bus=virtio-mmio-bus.0 -S -gdb tcp::26000  
+  
+  
+2.test@test-VirtualBox:~$ riscv64-unknown-linux-gnu-gdb -q                                                                                                                                                 
+(gdb) target remote :26000  
+Remote debugging using :26000  
+warning: No executable has been specified and target does not support  
+determining executable automatically.  Try using the "file" command.  
+0x0000000000001000 in ?? ()  
+(gdb) c  
+Continuing.  
+
+3.check xv6 is running.  
+xv6 kernel is booting  
+
+hart 2 starting  
+hart 1 starting  
+init: starting sh  
+$  
+
+4.Can't stop by GDB.  
+(gdb) c  
+Continuing.  
+^C^CThe target is not responding to interrupt requests.  
+Stop debugging it? (y or n) Quit  
+(gdb)
+Additional information:
+Test on new QEMU.  
+
+```
+commit cab35c73be9d579db105ef73fa8a60728a890098 (HEAD -> master, origin/staging, origin/master, origin/HEAD)
+Merge: 48ab886d3d d7ee93e243
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Jun 20 10:26:53 2023 +0200
+```
diff --git a/results/classifier/118/kernel/1733720 b/results/classifier/118/kernel/1733720
new file mode 100644
index 000000000..24227987b
--- /dev/null
+++ b/results/classifier/118/kernel/1733720
@@ -0,0 +1,107 @@
+mistranslation: 0.985
+architecture: 0.972
+kernel: 0.959
+device: 0.937
+performance: 0.931
+arm: 0.929
+graphic: 0.903
+peripherals: 0.879
+user-level: 0.844
+semantic: 0.835
+debug: 0.814
+ppc: 0.809
+assembly: 0.805
+socket: 0.769
+boot: 0.755
+files: 0.709
+vnc: 0.708
+register: 0.576
+permissions: 0.568
+network: 0.539
+KVM: 0.500
+VMM: 0.469
+risc-v: 0.467
+x86: 0.461
+PID: 0.458
+virtual: 0.415
+TCG: 0.381
+hypervisor: 0.315
+i386: 0.233
+
+raspi2 with multiple CPU's #1
+
+Greetings,
+
+I am running a small program for raspi2 (from http://wiki.osdev.org/ARM_RaspberryPi_Tutorial_C).
+
+This code writes "Hello World", but the output ir repeated 4 times.
+
+My thought was that this is emulating a 4 cpu core system.
+
+However, when I check the MPIDR registed for CPU number, it always returns 1.
+
+I git cloned github.com/qemu/qemu.git, made & installed on Acer ARM CB5-311 under Crouton/ubuntu.
+
+
+./qemu.sh 
+1111
+
+Linux:armv7l: ~/Downloads/RaspiTest/BareBones >>> uname -a
+Linux localhost 3.10.18 #1 SMP Mon Nov 13 16:34:10 PST 2017 armv7l armv7l armv7l GNU/Linux
+
+Linux:armv7l: ~/Downloads/RaspiTest/BareBones >>> qemu-system-arm --version
+QEMU emulator version 2.10.91 (v2.11.0-rc1-dirty)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+=====
+static inline uint32_t read_mpdir(void)
+{
+  uint32_t id;
+  
+  asm volatile("mrc p15, 0, %[id], c0, c0, 0 @ read MIDR\n\t"
+	       : [id] "=r" (id));
+  return id;
+}
+======
+void kernel_main(uint32_t r0, uint32_t r1, uint32_t atags)
+{
+	// Declare as unused
+	(void) r0;
+	(void) r1;
+	(void) atags;
+
+	uint32_t cpu_id;
+
+	cpu_id = read_mpdir() & 0x03;
+
+	uart_putc( "01234"[cpu_id] ); /* output is "1111" */
+
+	if (cpu_id == 0) { /* code never executes 8^( */ }
+
+====== qemu.sh
+qemu-system-arm -m 256 -M raspi2 -no-reboot -serial stdio  -kernel myos.elf
+
+Thanks much,
+-KenD
+
+NOT A BUG
+
+Reviewed the code and found the problem.
+
+asm volatile("mrc p15, 0, %[id], c0, c0, 0 @ read MIDR\n\t" ...
+
+I miscopied the code above; MIDR should have been MIPDR ( 5 )
+
+I now get:
+
+Linux:armv7l: ~/Downloads/RaspiTest/BareBones >>> ./qemu.sh 
+0H312ello, kernel World!
+
+Sorry about the bogus report!
+-KenD
+
+Sorry again, "MPIDR" 
+
+Gotta learn to type!
+
+
diff --git a/results/classifier/118/kernel/1745895 b/results/classifier/118/kernel/1745895
new file mode 100644
index 000000000..e9e28510e
--- /dev/null
+++ b/results/classifier/118/kernel/1745895
@@ -0,0 +1,65 @@
+kernel: 0.958
+device: 0.949
+ppc: 0.908
+PID: 0.906
+user-level: 0.901
+debug: 0.894
+network: 0.878
+socket: 0.877
+architecture: 0.877
+virtual: 0.872
+hypervisor: 0.857
+peripherals: 0.833
+performance: 0.830
+graphic: 0.803
+mistranslation: 0.793
+semantic: 0.763
+register: 0.745
+permissions: 0.734
+VMM: 0.719
+risc-v: 0.698
+vnc: 0.687
+TCG: 0.684
+x86: 0.661
+boot: 0.652
+arm: 0.605
+KVM: 0.602
+assembly: 0.587
+files: 0.556
+i386: 0.520
+
+Unable to migrate vhost-net to virtio-1.0-capable kernel
+
+I am running QEMU 2.11 (from upstream source, not Red Hat package) on stock RHEL 6 and RHEL 7 kernels. Only the RHEL 7 kernel supports VIRTIO_F_VERSION_1 in its vhost-net driver.
+
+When migrating a guest using vhost-net from the RHEL 6 host to RHEL 7, the PCI config is rejected by QEMU on the target machine.
+
+A simple test case:
+
+1. On the RHEL 7 host, prepare for an incoming migration:
+
+  rhel7# qemu-system-x86_64 -S -accel kvm -nographic -monitor stdio -nodefaults -netdev tap,id=net0,vhost=on,script=no,downscript=no -device virtio-net-pci,netdev=net0,mac=54:52:00:ff:ff:ff -incoming tcp:0.0.0.0:12345
+
+2. On the RHEL 6 host, start a guest and migrate it to the RHEL 7 host:
+
+  rhel6# qemu-system-x86_64 -S -accel kvm -nographic -monitor stdio -nodefaults -netdev tap,id=net0,vhost=on,script=no,downscript=no -device virtio-net-pci,netdev=net0,mac=54:52:00:ff:ff:ff
+QEMU 2.11.0 monitor - type 'help' for more information
+  (qemu) migrate tcp:rhel7:12345
+
+The RHEL 7 QEMU errors out:
+
+  qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x20 read: 0 device: c cmask: ff wmask: 0 w1cmask:0
+  qemu-system-x86_64: Failed to load PCIDevice:config
+  qemu-system-x86_64: Failed to load virtio-net:virtio
+  qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/virtio-net'
+  qemu-system-x86_64: load of migration failed: Invalid argument
+
+If I start the source QEMU with vhost=off, or the target QEMU with disable-modern=true, the migration is successful.
+
+My hunch here is that the target QEMU prepares the PCI device to support VIRTIO_F_VERSION_1, as that's available in the kernel there, but then fails to (or does not know to) disable this during the migration.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1747 b/results/classifier/118/kernel/1747
new file mode 100644
index 000000000..980a7aa0b
--- /dev/null
+++ b/results/classifier/118/kernel/1747
@@ -0,0 +1,46 @@
+kernel: 0.862
+register: 0.724
+device: 0.664
+semantic: 0.645
+graphic: 0.590
+network: 0.538
+ppc: 0.435
+risc-v: 0.393
+vnc: 0.354
+user-level: 0.351
+architecture: 0.339
+socket: 0.315
+boot: 0.279
+i386: 0.256
+mistranslation: 0.255
+arm: 0.250
+x86: 0.248
+PID: 0.216
+KVM: 0.193
+virtual: 0.186
+debug: 0.185
+TCG: 0.184
+VMM: 0.180
+permissions: 0.159
+performance: 0.150
+assembly: 0.141
+files: 0.115
+peripherals: 0.086
+hypervisor: 0.082
+
+eMMC support is missing as a storage type
+Additional information:
+There seems several attempts at this, but the most recent appears much more complete:
+* https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg00347.html
+
+
+
+Historical;
+"[PATCH v3 06/21] sd: emmc: Update CMD8 to send EXT_CSD register"
+https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg00118.html
+
+"[RFC PATCH 00/17] hw/sd: Rework models for eMMC support"
+https://lore.kernel.org/qemu-devel/8aa56da0-a54a-102a-fc85-2fa9f02c18d1@kaod.org/
+
+2011 eMMC original support
+https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02835.html
diff --git a/results/classifier/118/kernel/1767146 b/results/classifier/118/kernel/1767146
new file mode 100644
index 000000000..a95533dd7
--- /dev/null
+++ b/results/classifier/118/kernel/1767146
@@ -0,0 +1,76 @@
+kernel: 0.969
+debug: 0.955
+virtual: 0.953
+graphic: 0.896
+ppc: 0.862
+i386: 0.848
+mistranslation: 0.832
+semantic: 0.817
+user-level: 0.806
+device: 0.801
+performance: 0.763
+files: 0.742
+vnc: 0.733
+hypervisor: 0.731
+risc-v: 0.713
+x86: 0.703
+assembly: 0.702
+architecture: 0.699
+peripherals: 0.670
+VMM: 0.660
+PID: 0.655
+register: 0.641
+permissions: 0.638
+KVM: 0.622
+network: 0.616
+arm: 0.564
+socket: 0.551
+boot: 0.522
+TCG: 0.499
+
+No ACPI-table found, option -M 1.6 not found either
+
+Currently writing a small kernel, when trying to detect memory blocks that contain ACPI information, no such block is found. When ran in Oracle Virtualbox, code runs flawlessly.
+
+Code that is detecting the ACPI-Info (with a bit of debug-output):
+
+```
+multiboot_memory_map32_t* map = (multiboot_memory_map32_t*)mmap;
+for (uint32_t i = 0; i < size; i++) {
+	Termutils::cout << map[i].type << "type of block  ";
+        if (mmap[i].type == MULTIBOOT_MEMORY_ACPI_RECLAIMABLE) {
+		Termutils::cout << "WE ARE INSIDE\n";
+		fadt = (FADT*)(map[i].base_addr_low);
+		//break;
+	}
+	if (i % 9 == 0) {
+		Termutils::cout << "\n";
+	}
+}
+```
+
+
+command qemu is run with:
+
+qemu-img create build/objects/test 500M
+qemu-system-i386 -hda $(APP_DIR)/clinl.iso -hdb ./build/objects/test
+
+
+The iso-image is (zipped) included as attachment.
+
+
+qemu-system-i386 --version:
+
+QEMU emulator version 2.10.1(qemu-2.10.1-3.fc27)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+
+
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1774 b/results/classifier/118/kernel/1774
new file mode 100644
index 000000000..858064e16
--- /dev/null
+++ b/results/classifier/118/kernel/1774
@@ -0,0 +1,53 @@
+kernel: 0.825
+vnc: 0.692
+graphic: 0.686
+user-level: 0.643
+ppc: 0.629
+semantic: 0.600
+device: 0.600
+files: 0.558
+PID: 0.526
+socket: 0.501
+permissions: 0.501
+mistranslation: 0.485
+boot: 0.460
+network: 0.456
+TCG: 0.435
+register: 0.430
+VMM: 0.428
+architecture: 0.421
+virtual: 0.421
+risc-v: 0.414
+performance: 0.403
+i386: 0.394
+hypervisor: 0.347
+x86: 0.341
+arm: 0.328
+assembly: 0.317
+debug: 0.283
+KVM: 0.282
+peripherals: 0.273
+
+8.1-rc0 failure to build with capstone 5.0
+Description of problem:
+Use >=capstone-5.0 dependency, try to build qemu, get this error:
+```
+/opt/homebrew/Cellar/capstone/5.0/include/capstone/tricore.h:561:3: error:
+redefinition of 'tricore_feature' as different kind of symbol
+} tricore_feature;
+  ^
+../target/tricore/cpu.h:261:19: note: previous definition is here
+static inline int tricore_feature(CPUTriCoreState *env, int feature)
+                  ^
+1 error generated.
+```
+
+The fix is trivial and it was already mentioned in the mailing list but wasn't fixed for rc0, so I figured it might have been forgotten about.
+
+https://lore.kernel.org/qemu-devel/CA+PgxXVxVKpT0SZ3N+Fc1YvXCiwkkbqm0FmLKqLTbgcDpYCNgg@mail.gmail.com/
+
+If you meet any other problem with capstone (e.g. some regression), please don't hesitate to report it mainstream.
+
+There are plans to make a new patch release soon with fixes for some most annoying bugs since the 5.0 release: https://github.com/capstone-engine/capstone/issues/2081
+
+https://github.com/capstone-engine/capstone/releases
diff --git a/results/classifier/118/kernel/1780814 b/results/classifier/118/kernel/1780814
new file mode 100644
index 000000000..8dba826f5
--- /dev/null
+++ b/results/classifier/118/kernel/1780814
@@ -0,0 +1,80 @@
+kernel: 0.888
+mistranslation: 0.817
+graphic: 0.759
+device: 0.740
+PID: 0.605
+semantic: 0.555
+ppc: 0.542
+network: 0.533
+permissions: 0.475
+debug: 0.465
+files: 0.456
+register: 0.448
+socket: 0.439
+architecture: 0.427
+risc-v: 0.419
+performance: 0.411
+user-level: 0.394
+arm: 0.383
+vnc: 0.383
+boot: 0.381
+peripherals: 0.355
+hypervisor: 0.319
+virtual: 0.267
+VMM: 0.244
+x86: 0.241
+i386: 0.236
+KVM: 0.220
+TCG: 0.165
+assembly: 0.120
+
+lib/raid6/neon4.c:118:1: internal compiler error
+
+I am facing below issue when i am trying to cross compile kernel for raspberry pi 3.
+please give solution .
+
+
+Below is log
+
+
+
+CHK     include/config/kernel.release
+  CHK     include/generated/uapi/linux/version.h
+  CHK     include/generated/utsrelease.h
+  CHK     include/generated/bounds.h
+  CHK     include/generated/timeconst.h
+  CHK     include/generated/asm-offsets.h
+  CALL    scripts/checksyscalls.sh
+  CHK     scripts/mod/devicetable-offsets.h
+  CHK     include/generated/compile.h
+  CHK     kernel/config_data.h
+  CC [M]  lib/raid6/neon4.o
+lib/raid6/neon4.c: In function ‘raid6_neon4_gen_syndrome_real’:
+lib/raid6/neon4.c:118:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1078
+ }
+ ^
+Please submit a full bug report,
+with preprocessed source if appropriate.
+See <https://bugs.launchpad.net/gcc-linaro> for instructions.
+scripts/Makefile.build:328: recipe for target 'lib/raid6/neon4.o' failed
+make[2]: *** [lib/raid6/neon4.o] Error 1
+scripts/Makefile.build:587: recipe for target 'lib/raid6' failed
+make[1]: *** [lib/raid6] Error 2
+Makefile:1034: recipe for target 'lib' failed
+
+Hi -- this is an internal compiler error reported by your compiler. It's not a QEMU bug. The message suggests that you report it as a GCC bug: "See <https://bugs.launchpad.net/gcc-linaro> for instructions".
+
+
+Thanks peter maydell for your comments.
+
+
+
+Hi Peter Maydell ,
+
+is that GCC compiler error or cross-compiler error ?
+
+It must be the cross compiler. (Why did you report this against QEMU anyway?)
+
+
+I thought it was QEMU issue. Sorry for that.
+
diff --git a/results/classifier/118/kernel/1813045 b/results/classifier/118/kernel/1813045
new file mode 100644
index 000000000..856557f9b
--- /dev/null
+++ b/results/classifier/118/kernel/1813045
@@ -0,0 +1,54 @@
+kernel: 0.929
+files: 0.894
+device: 0.860
+graphic: 0.791
+mistranslation: 0.785
+performance: 0.655
+semantic: 0.599
+virtual: 0.598
+hypervisor: 0.545
+ppc: 0.541
+architecture: 0.537
+register: 0.534
+PID: 0.483
+vnc: 0.476
+user-level: 0.437
+debug: 0.424
+arm: 0.410
+VMM: 0.407
+assembly: 0.395
+permissions: 0.393
+i386: 0.385
+boot: 0.373
+x86: 0.359
+socket: 0.354
+network: 0.321
+risc-v: 0.313
+TCG: 0.304
+KVM: 0.230
+peripherals: 0.170
+
+qemu-ga fsfreeze crashes the kernel
+
+We use mainly Cloudlinux, Debian and Centos.
+We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot.
+The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening:
+
+When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation: 
+1) freeze loopback fs
+              ---> send async reqs to loopback thread
+2) freeze main fs
+3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash. 
+
+I believe this is the culprit: 
+
+/dev/loop0 /tmp ext3 rw,nosuid,noexec,relatime,data=ordered 0 0
+/dev/loop0 /var/tmp ext3 rw,nosuid,noexec,relatime,data=ordered 0 0
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+See also https://gitlab.com/qemu-project/qemu/-/issues/520
+
diff --git a/results/classifier/118/kernel/1836537 b/results/classifier/118/kernel/1836537
new file mode 100644
index 000000000..bb29c2829
--- /dev/null
+++ b/results/classifier/118/kernel/1836537
@@ -0,0 +1,44 @@
+kernel: 0.908
+device: 0.874
+user-level: 0.778
+network: 0.776
+graphic: 0.708
+architecture: 0.691
+socket: 0.650
+ppc: 0.649
+mistranslation: 0.639
+semantic: 0.622
+boot: 0.614
+register: 0.609
+vnc: 0.608
+performance: 0.552
+risc-v: 0.529
+permissions: 0.517
+VMM: 0.508
+KVM: 0.475
+PID: 0.472
+peripherals: 0.452
+TCG: 0.452
+arm: 0.424
+files: 0.369
+hypervisor: 0.363
+debug: 0.361
+i386: 0.349
+virtual: 0.337
+x86: 0.337
+assembly: 0.163
+
+Kconfig-related options not shown in ./configure --help
+
+tag: v4.1.0-rc0
+
+I notice these options not documented by '--help':
+
+  --with-default-devices) default_devices="yes"
+  --without-default-devices) default_devices="no"
+
+We might have other options not documented too.
+
+Fixed here:
+https://gitlab.com/qemu-project/qemu/-/commit/c035c8d6f54
+
diff --git a/results/classifier/118/kernel/1842916 b/results/classifier/118/kernel/1842916
new file mode 100644
index 000000000..4e917a8d3
--- /dev/null
+++ b/results/classifier/118/kernel/1842916
@@ -0,0 +1,83 @@
+kernel: 0.932
+device: 0.847
+architecture: 0.835
+PID: 0.807
+files: 0.734
+graphic: 0.704
+socket: 0.701
+register: 0.689
+ppc: 0.643
+assembly: 0.631
+boot: 0.612
+performance: 0.600
+semantic: 0.588
+risc-v: 0.585
+network: 0.581
+user-level: 0.569
+peripherals: 0.565
+vnc: 0.560
+hypervisor: 0.547
+permissions: 0.545
+mistranslation: 0.539
+debug: 0.518
+x86: 0.488
+VMM: 0.439
+KVM: 0.416
+TCG: 0.406
+arm: 0.384
+i386: 0.248
+virtual: 0.225
+
+[18.04 FEAT] Enhanced Hardware Support - Finalize Naming
+
+This feature request will provide the final naming of the next machine
+
+A similar ticket for Eoan/19.10 was created, too:
+https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842774
+
+Disco also needs to be addressed, but let's track that here, too.
+
+------- Comment From <email address hidden> 2019-09-18 08:43 EDT-------
+See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0e2251132995b962281aa80ab54a9288f9e0b6b
+
+commit a0e2251132995b962281aa80ab54a9288f9e0b6b
+Author: Martin Schwidefsky <email address hidden>
+Date:   Wed Feb 6 08:22:11 2019 +0100
+
+s390: add support for IBM z15 machines
+
+Add detection for machine types 0x8562 and 8x8561 and set the ELF platform
+name to z15. Add the miscellaneous-instruction-extension 3 facility to
+the list of facilities for z15.
+
+And allow to generate code that only runs on a z15 machine.
+
+Reviewed-by: Christian Borntraeger <email address hidden>
+Signed-off-by: Martin Schwidefsky <email address hidden>
+Signed-off-by: Heiko Carstens <email address hidden>
+
+for the kernel upstream commit. Applies cleanly to git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic
+
+Marking this as duplicate of LP 1842774, since both LPs deal with the same patch, just for different Ubuntu releases.
+But the affected Ubuntu releases are now all listed in LP 1842774, which makes the requested kernel SRU simpler.
+
+------- Comment From <email address hidden> 2019-10-04 03:42 EDT-------
+For reference the QEMU part, which is already done in eoan via
+> qemu (1:4.0+dfsg-0ubuntu9) eoan; urgency=medium
+>
+> * d/p/lp-1842774-s390x-cpumodel-Add-the-z15-name-to-the-description-o.patch:
+> update the z15 model name (LP: #1842774)
+>
+> -- Christian Ehrhardt <email address hidden>  Tue, 24 Sep 2019
+
+is upstream commit 7505deca0bfa859136ec6419dbafc504f22fcac2
+s390x/cpumodel: Add the z15 name to the description of gen15a
+
+------- Comment From <email address hidden> 2019-11-04 11:27 EDT-------
+*** This bug has been marked as a duplicate of bug 181268 ***
+
+------- Comment From <email address hidden> 2019-11-04 11:28 EDT-------
+IBM Bugzilla status -> closed,
+
+Will be tracked with LP: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842774
+
diff --git a/results/classifier/118/kernel/1843711 b/results/classifier/118/kernel/1843711
new file mode 100644
index 000000000..b03cd8ede
--- /dev/null
+++ b/results/classifier/118/kernel/1843711
@@ -0,0 +1,65 @@
+kernel: 0.938
+device: 0.849
+user-level: 0.741
+peripherals: 0.650
+architecture: 0.644
+network: 0.639
+socket: 0.601
+performance: 0.587
+semantic: 0.573
+debug: 0.569
+PID: 0.532
+ppc: 0.517
+permissions: 0.511
+register: 0.477
+graphic: 0.462
+files: 0.447
+mistranslation: 0.425
+boot: 0.412
+x86: 0.394
+vnc: 0.342
+VMM: 0.323
+virtual: 0.303
+risc-v: 0.291
+hypervisor: 0.270
+arm: 0.269
+i386: 0.252
+TCG: 0.221
+KVM: 0.200
+assembly: 0.187
+
+qemu-xhci device should detect if libusb host supports streams
+
+When using USB passthrough with the qemu-xhci (and nec-usb-xhci), streams are enabled by default, but if the host xHCI controller doesn't support them, it will trigger hard-to-debug UAS guest errors.
+
+This should be possible to detect since the kernel returns ENOSYS (errno 38) when xhci host controller does not support streams:
+            libusb: error [do_streams_ioctl] streams-ioctl failed error -1 errno 38
+            qemu: libusb_alloc_streams: -99 [OTHER]
+
+Maybe libusb should return a dedicated error instead of LIBUSB_ERROR_OTHER in this case, but qemu does not handle any other error code anyway.
+
+Just trying to enable streams before enabling them in qemu should do it. I don't know if it should be done in hcd-xhci.c, host-libusb.c or elsewhere, but this would be detectable at launch instead of a static option true/false, maybe a ternary with auto would be better.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+This is a suggestion that would really help anyone using trying to use xhci passthrough on a platform without streams.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/182
+
+
diff --git a/results/classifier/118/kernel/1849 b/results/classifier/118/kernel/1849
new file mode 100644
index 000000000..d147c4791
--- /dev/null
+++ b/results/classifier/118/kernel/1849
@@ -0,0 +1,101 @@
+kernel: 0.940
+performance: 0.929
+device: 0.928
+graphic: 0.886
+architecture: 0.874
+user-level: 0.859
+risc-v: 0.858
+boot: 0.844
+peripherals: 0.839
+files: 0.784
+PID: 0.758
+permissions: 0.731
+semantic: 0.694
+hypervisor: 0.648
+network: 0.614
+virtual: 0.502
+arm: 0.473
+debug: 0.463
+mistranslation: 0.417
+assembly: 0.398
+register: 0.346
+socket: 0.329
+VMM: 0.291
+x86: 0.282
+vnc: 0.235
+TCG: 0.216
+ppc: 0.212
+i386: 0.203
+KVM: 0.106
+
+Problems with building riscv Linux using qemu on wsl2
+Description of problem:
+execute:
+
+`qemu-system-riscv64 -M virt -m 256M -nographic -kernel /home/ysc/test/linux-6.1.46/arch/riscv/boot/Image -drive file=rootfs.img,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -append "root=/dev/vda rw console=ttyS0"`
+
+**appear:**
+
+OpenSBI
+
+/ \_\_ \\ / **_| \_ \_ | | | | | \_\_ \__\_ \_ \_\_ | (_**\_ | |_) || | | | | | '\_ \\ / \_ \\ '\_ \\ \__\_ | \_ \< | | | |\*\*| | |_) | \_\_/ | | |) | |) || | \_\_**/| .**/ \_\*\*|_| |_|**_/|\___\_/_**| | | |\_|
+
+Platform Name : riscv-virtio,qemu
+
+Platform Features : medeleg Platform HART Count : 1
+
+Platform IPI Device : aclint-mswi
+
+Platform Timer Device : aclint-mtimer @ 10000000Hz
+
+Platform Console Device : uart8250 Platform HSM Device : ---
+
+Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test
+
+Firmware Base : 0x80000000
+
+Firmware Size : 252 KB
+
+Runtime SBI Version : 0.3
+
+Domain0 Name : root
+
+Domain0 Boot HART : 0
+
+Domain0 HARTs : 0\*
+
+Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I)
+
+Domain0 Region01 : 0x0000000080000000-0x000000008003ffff ()
+
+Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
+
+Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x000000008f000000
+
+Domain0 Next Mode : S-mode Domain0 SysReset : yes
+
+Boot HART ID : 0
+
+Boot HART Domain : root
+
+Boot HART ISA : rv64imafdcsuh
+
+Boot HART Features : scounteren,mcounteren,time
+
+Boot HART PMP Count : 16
+
+Boot HART PMP Granularity : 4
+
+Boot HART PMP Address Bits: 54
+
+Boot HART MHPM Count : 0
+
+Boot HART MIDELEG : 0x0000000000001666
+
+Boot HART MEDELEG : 0x0000000000f0b509
+
+When I run qemu, it's stuck here
+Steps to reproduce:
+1. Build the kernel file using Linux-6.1.46
+2. Use busbox to build rootfs
+3. run qemu
diff --git a/results/classifier/118/kernel/1850 b/results/classifier/118/kernel/1850
new file mode 100644
index 000000000..44a0d3b0f
--- /dev/null
+++ b/results/classifier/118/kernel/1850
@@ -0,0 +1,59 @@
+register: 0.985
+architecture: 0.937
+kernel: 0.921
+files: 0.852
+semantic: 0.719
+device: 0.700
+graphic: 0.669
+assembly: 0.656
+performance: 0.573
+ppc: 0.540
+PID: 0.443
+arm: 0.439
+network: 0.430
+vnc: 0.405
+socket: 0.378
+permissions: 0.364
+debug: 0.314
+TCG: 0.308
+mistranslation: 0.282
+user-level: 0.270
+x86: 0.255
+risc-v: 0.252
+boot: 0.248
+VMM: 0.196
+virtual: 0.182
+hypervisor: 0.164
+i386: 0.143
+peripherals: 0.134
+KVM: 0.129
+
+AARCH64 Illegal Instruction (CurrentEL)
+Description of problem:
+While emulating Aarch64 in QEMU, whenever the instruction `CurrentEL` is executed,
+QEMU crashes with the following message.
+
+`qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction (core dumped)`
+
+I've tried both QEMU user space translation (qemu-aarch64-static) and QEMU emulation (qemu-system-aarch64),
+and both fail with the above message.
+
+C Code to reproduce bug, courtesy of https://github.com/cirosantilli/linux-kernel-module-cheat/blob/35684b1b7e0a04a68987056cb15abd97e3d2f0cc/baremetal/arch/aarch64/el.c
+```
+#include <stdio.h>
+#include <inttypes.h>
+
+int main(void) {
+        register uint64_t x0 __asm__ ("x0");
+	__asm__ ("mrs x0, CurrentEL;" : : : "%x0");
+	printf("%" PRIu64 "\n", x0 >> 2);
+	return 0;
+}
+```
+Steps to reproduce:
+1. Copy C code above into file.
+2. Compile code `gcc ./main.c --static`
+3. Execute elf bin `./a.out`
+Additional information:
+
diff --git a/results/classifier/118/kernel/1854 b/results/classifier/118/kernel/1854
new file mode 100644
index 000000000..345fc9a5d
--- /dev/null
+++ b/results/classifier/118/kernel/1854
@@ -0,0 +1,48 @@
+kernel: 0.938
+device: 0.934
+graphic: 0.892
+user-level: 0.874
+files: 0.865
+PID: 0.855
+register: 0.691
+permissions: 0.661
+vnc: 0.655
+architecture: 0.652
+debug: 0.634
+network: 0.626
+semantic: 0.578
+socket: 0.563
+ppc: 0.441
+boot: 0.363
+mistranslation: 0.311
+TCG: 0.288
+performance: 0.288
+VMM: 0.274
+x86: 0.261
+hypervisor: 0.211
+i386: 0.197
+peripherals: 0.194
+virtual: 0.157
+risc-v: 0.138
+arm: 0.110
+KVM: 0.087
+assembly: 0.059
+
+s390x: qemu-user: ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Description of problem:
+The nolibc-test program from the Linux kernel crashes since 5f4e5b34092556ab1577e25d1262bd5975b26980 .
+Reverting that commit fixes the issue.
+Steps to reproduce:
+1. Build `nolibc-test` for s390x from Linux kernel tree. (from `tools/testing/selftests/nolibc/`). EDIT: compiled binary is uploaded below.
+2. Run it under qemu-s390x.
+
+```
+ ./qemu-s390x nolibc-test
+**
+ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Bail out! ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Aborted (core dumped)
+
+```
+Additional information:
+
diff --git a/results/classifier/118/kernel/1882784 b/results/classifier/118/kernel/1882784
new file mode 100644
index 000000000..1c94491be
--- /dev/null
+++ b/results/classifier/118/kernel/1882784
@@ -0,0 +1,95 @@
+kernel: 0.837
+socket: 0.820
+peripherals: 0.803
+arm: 0.801
+network: 0.799
+permissions: 0.797
+x86: 0.796
+hypervisor: 0.790
+files: 0.774
+device: 0.762
+ppc: 0.752
+register: 0.752
+graphic: 0.751
+vnc: 0.741
+PID: 0.739
+boot: 0.735
+TCG: 0.733
+risc-v: 0.714
+virtual: 0.710
+assembly: 0.703
+architecture: 0.700
+debug: 0.687
+performance: 0.683
+KVM: 0.671
+mistranslation: 0.668
+user-level: 0.656
+VMM: 0.631
+semantic: 0.630
+i386: 0.505
+
+Legacy IGD passthrough in QEMU 5 disabled
+
+Bug with tag v5.0.0, or commit fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6
+
+As of QEMU 5 Legacy IGD PT is no longer working.
+
+Host is a Xeon E3-1226 v3 and my method to test is to run the following:
+
+./qemu-system-x86_64 \
+  -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1f' \
+  -device 'vfio-pci,host=00:02.0,addr=02.0' \
+  -L '/usr/share/kvm' \
+  -nographic \
+  -vga none \
+  -nodefaults
+
+in the hope of seeing a "IGD device 0000:00:02.0 cannot support legacy mode due to existing devices at address 1f.0" error.
+
+The culprit appears to be this commit:
+
+https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19
+
+Specifically the following block in pci-quirks.c:
+
+#ifdef CONFIG_VFIO_IGD
+    vfio_probe_igd_bar4_quirk(vdev, nr);
+#endif
+
+as the kconfig variable CONFIG_VFIO_IGD doesn't appear to be available outside of makefiles as described here: https://qemu.weilnetz.de/doc/devel/kconfig.html. I can confirm that the igd code is being pulled in as removing this check, as would defining the variable I presume, makes Legacy IGD PT work again (ie I see the expected "existing devices" error).
+
+I first spotted this in Proxmox, but have confirmed the bug by building QEMU sources.
+
+Hi! That info in kconfig.html is not up to date anymore, we are generating now #defines for the Kconfig switches. And in my build tree, I can see:
+
+$ grep CONFIG_VFIO_IGD *-softmmu/*.h
+x86_64-softmmu/config-devices.h:#define CONFIG_VFIO_IGD 1
+
+... what's missing in that file is simply a "#include "config-devices.h" ... sorry, that fell somehow through the cracks. I'll prepare a patch for that.
+
+Looks similar to https://bugs.launchpad.net/qemu/+bug/1879175
+
+Looks the same, although the title was misleading so I missed it.
+
+@Thomas, I used the same patch and verified that it works (I know you don't pick up patches here but I presume you have your own):
+
+diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
+index 2d348f8237..a633df965e 100644
+--- a/hw/vfio/pci-quirks.c
++++ b/hw/vfio/pci-quirks.c
+@@ -25,6 +25,7 @@
+ #include "hw/qdev-properties.h"
+ #include "pci.h"
+ #include "trace.h"
++#include "config-devices.h"
+
+ /*
+  * List of device ids/vendor ids for which to disable
+
+
+Patch is on the list now:
+https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg02567.html
+
+Patch has been included:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=643a4eacef87a318c
+
diff --git a/results/classifier/118/kernel/1885553 b/results/classifier/118/kernel/1885553
new file mode 100644
index 000000000..04145c8a5
--- /dev/null
+++ b/results/classifier/118/kernel/1885553
@@ -0,0 +1,74 @@
+arm: 0.956
+architecture: 0.955
+kernel: 0.930
+graphic: 0.813
+device: 0.780
+files: 0.742
+hypervisor: 0.701
+ppc: 0.690
+debug: 0.680
+PID: 0.677
+user-level: 0.665
+performance: 0.643
+network: 0.628
+semantic: 0.616
+vnc: 0.609
+risc-v: 0.601
+peripherals: 0.577
+socket: 0.574
+register: 0.573
+TCG: 0.573
+x86: 0.564
+VMM: 0.560
+permissions: 0.554
+mistranslation: 0.552
+i386: 0.540
+boot: 0.540
+KVM: 0.476
+assembly: 0.468
+virtual: 0.342
+
+make-check test failed with "Segmentation fault"
+
+While running the make-check testing on arm architecture the test failed with error:
+"kill_qemu() detected QEMU death from signal 11 (Segmentation fault) (core dumped)". Apart from that make-install test always passes.
+The problem doesn't reproduce in 100%
+qemu - from the master branch
+RHEL-8 kernel 4.18.0-221.el8.aarch64
+Logfile with an error you can to find in attachment
+
+Thanks
+
+
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" within the next 60 days (otherwise it will get
+closed as "Expired"). We will then eventually migrate the ticket auto-
+matically to the new system (but you won't be the reporter of the bug
+in the new system and thus won't get notified on changes anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1893634 b/results/classifier/118/kernel/1893634
new file mode 100644
index 000000000..f99221386
--- /dev/null
+++ b/results/classifier/118/kernel/1893634
@@ -0,0 +1,73 @@
+kernel: 0.945
+device: 0.894
+architecture: 0.853
+performance: 0.839
+peripherals: 0.820
+mistranslation: 0.800
+graphic: 0.799
+network: 0.791
+user-level: 0.741
+files: 0.717
+hypervisor: 0.712
+arm: 0.698
+permissions: 0.696
+x86: 0.692
+register: 0.686
+debug: 0.670
+PID: 0.663
+semantic: 0.651
+socket: 0.622
+TCG: 0.618
+i386: 0.603
+ppc: 0.601
+assembly: 0.587
+KVM: 0.576
+VMM: 0.574
+risc-v: 0.555
+virtual: 0.541
+boot: 0.535
+vnc: 0.531
+
+blk_get_max_transfer() works only with sg
+
+blk_get_max_transfer() is supposed to be able to get the max_sectors queue limit of the scsi device on the host side and is used in both scsi-generic.c (for scsi-generic and scsi-block) and scsi-disk.c (for scsi-hd) to set/change the max_xfer_len (and opt_xfer_len in the case of scsi-generic).
+
+However, it only works with the sg driver in doing so. It cannot get the queue limit with the sd driver and simply returns MAX_INT.
+
+qemu version 5.1.0
+kernel version 5.8.5
+
+Btw, is there a particular reason that it doesn't MIN_NON_ZERO against the original max_xfer_len: https://github.com/qemu/qemu/blob/v5.1.0/hw/scsi/scsi-generic.c#L172?
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/1910 b/results/classifier/118/kernel/1910
new file mode 100644
index 000000000..58c2f3680
--- /dev/null
+++ b/results/classifier/118/kernel/1910
@@ -0,0 +1,92 @@
+kernel: 0.942
+x86: 0.939
+debug: 0.867
+i386: 0.841
+boot: 0.829
+architecture: 0.800
+register: 0.743
+ppc: 0.742
+performance: 0.739
+device: 0.678
+socket: 0.657
+risc-v: 0.645
+PID: 0.607
+network: 0.595
+user-level: 0.593
+arm: 0.587
+vnc: 0.551
+semantic: 0.529
+graphic: 0.529
+permissions: 0.511
+VMM: 0.468
+hypervisor: 0.446
+TCG: 0.437
+peripherals: 0.420
+KVM: 0.380
+mistranslation: 0.363
+files: 0.354
+assembly: 0.168
+virtual: 0.135
+
+Signal handlers in x86_64 userspace have wrongly aligned stack
+Description of problem:
+Various applications crash in signal handlers due to `movaps` getting a misaligned stack address. For some reason this is reported as a NULL deref, but `gdb` clearly shows the true cause.
+
+```plaintext
+> qemu-x86_64 /usr/bin/ruby -e '`true`'
+-e:1: [BUG] Segmentation fault at 0x0000000000000000
+ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-gnu]
+
+-- Control frame information -----------------------------------------------
+c:0003 p:---- s:0011 e:000010 CFUNC  :`
+c:0002 p:0005 s:0006 e:000005 EVAL   -e:1 [FINISH]
+c:0001 p:0000 s:0003 E:0015b0 DUMMY  [FINISH]
+
+-- Ruby level backtrace information ----------------------------------------
+-e:1:in `<main>'
+-e:1:in ``'
+
+-- Machine register context ------------------------------------------------
+ RIP: 0x00002aaaab50f98a RBP: 0x00002aaaabb136b8 RSP: 0x00002aaaab2a9c98
+ RAX: 0x0000000000000000 RBX: 0x0000000000004946 RCX: 0x0000000000000000
+ RDX: 0x00002aaaab2a9c98 RDI: 0x000000000caf0000 RSI: 0x0000000000000000
+  R8: 0x00002aaaab2aaa50  R9: 0x0000000000000050 R10: 0x0000000000000008
+ R11: 0x0000000000000000 R12: 0x0000000000000002 R13: 0x0000000000007310
+ R14: 0x0000000000005e10 R15: 0x00002aaab0537f20 EFL: 0x0000000000000246
+
+-- C level backtrace information -------------------------------------------
+```
+
+```plaintext
+(gdb) x/i $pc
+=> 0x2aaaab50f98a:      movaps %xmm0,(%rsp)
+(gdb) p/x $rsp
+$3 = 0x2aaaab2a9998
+```
+Steps to reproduce:
+1. ```qemu-x86_64 /usr/bin/ruby -e '`true`'```
+Additional information:
+The x86_64 psABI says:
+
+> the value (%rsp − 8) is always a multiple of 16 when control is transferred to the function entry point.
+
+However, when QEMU jumps to the signal handler, $rsp is aligned to 16B, i.e. ends in `0x..0`.
+
+The relevant kernel code:
+
+https://elixir.bootlin.com/linux/v6.5.5/source/arch/x86/kernel/signal.c#L123
+
+```plaintext
+	sp -= frame_size;
+
+	if (ia32_frame)
+		/*
+		 * Align the stack pointer according to the i386 ABI,
+		 * i.e. so that on function entry ((sp + 4) & 15) == 0.
+		 */
+		sp = ((sp + 4) & -FRAME_ALIGNMENT) - 4;
+	else
+		sp = round_down(sp, FRAME_ALIGNMENT) - 8;
+```
+
+CC @lvivier @bonzini @rth7680
diff --git a/results/classifier/118/kernel/1921092 b/results/classifier/118/kernel/1921092
new file mode 100644
index 000000000..0eeb78776
--- /dev/null
+++ b/results/classifier/118/kernel/1921092
@@ -0,0 +1,70 @@
+kernel: 0.900
+device: 0.858
+debug: 0.844
+files: 0.812
+boot: 0.760
+semantic: 0.745
+ppc: 0.723
+user-level: 0.692
+arm: 0.689
+PID: 0.619
+virtual: 0.585
+register: 0.551
+socket: 0.536
+graphic: 0.536
+mistranslation: 0.526
+architecture: 0.526
+performance: 0.525
+hypervisor: 0.498
+permissions: 0.489
+network: 0.410
+vnc: 0.388
+peripherals: 0.345
+risc-v: 0.342
+x86: 0.297
+VMM: 0.282
+TCG: 0.217
+assembly: 0.199
+i386: 0.191
+KVM: 0.165
+
+gdbstub debug of multi-cluster machines is undocumented and confusing
+
+Working with Zephyr RTOS, running a multi core sample on mps2_an521 works fine. Both cpus start.
+Trying to debug with options -s -S the second core fails to boot.
+Posted with explanation also at: https://github.com/zephyrproject-rtos/zephyr/issues/33635
+
+there was no bug, it was my fault. How do I delete this
+
+In general, you don't need to delete bugs that turn out to be user error, or edit the description/title; just mark them as 'invalid', perhaps with a comment about what turned out to be the cause. That leaves the trail of what was going on for future readers who might be going down the same path as you.
+
+There are actually a couple of things we should do here in upstream QEMU:
+
+* we should document the process for using the debugstub with multi-cluster board models like the mps2-an521
+* we should check whether we are doing the right/most appropriate thing when the user connects to the debug stub and is only attaching to one 'inferior' -- it sounds from your report like the un-attached inferior is left permanently in the 'stopped' state. Maybe that's what the gdb protocol requires, but it seems a bit unhelpful.
+
+I'm going to update the bug status/text accordingly.
+
+
+Thanks for the answer,
+
+indeed the second cluster of the board has been halted when I was starting gdb the "normal" way - not adding the second inferior. In my own research I did not find out about these inferiors, so I was wondering why "info threads" did only show one cpu. Maybe gdb could inform the user about unattached inferiors when using "info threads"
+
+Could you provide an example QEMU command line and guest image file which you were having this problem with, please? That would save me figuring out how to build zephyr binaries :-)
+
+
+qemu-system-arm -cpu cortex-m33 -machine mps2-an521 -nographic -m 16 -vga none -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -icount shift=7,align=off,sleep=off -rtc clock=vm -device loader,file=<remote_dir>/zephyr.elf -s -S -kernel <master_dir>/zephyr.elf
+
+i've included both .elf files in a zip. That should be enough for running the sample
+
+There's now a new docs section on debugging multicore (including multi-cluster) machines:
+
+https://qemu-project.gitlab.io/qemu/system/gdb.html#debugging-multicore-machines
+
+
+Is there still anything to do here or could we close the ticket now?
+
+It can be closed. The added documentation is very helpful.
+
+Ok, thanks, so I'm closing this ticket now.
+
diff --git a/results/classifier/118/kernel/1922430 b/results/classifier/118/kernel/1922430
new file mode 100644
index 000000000..389fb81eb
--- /dev/null
+++ b/results/classifier/118/kernel/1922430
@@ -0,0 +1,101 @@
+kernel: 0.959
+KVM: 0.954
+hypervisor: 0.952
+architecture: 0.946
+graphic: 0.913
+x86: 0.895
+performance: 0.892
+user-level: 0.885
+permissions: 0.885
+device: 0.882
+boot: 0.863
+ppc: 0.858
+assembly: 0.856
+semantic: 0.843
+VMM: 0.842
+socket: 0.837
+PID: 0.816
+peripherals: 0.816
+network: 0.804
+files: 0.792
+mistranslation: 0.770
+virtual: 0.716
+risc-v: 0.708
+vnc: 0.665
+TCG: 0.624
+register: 0.606
+arm: 0.551
+debug: 0.527
+i386: 0.486
+
+3d accel does not take care of 1280x960 setting
+
+openSuse 15.2
+kde plasma 5.21.3, frameworks 5.80.0
+libvirt 7.0.0
+qemu 5.2.0
+virgl renderer 0.8.2
+
+here is my invocation
+
+qemu-kvm -enable-kvm \
+-m 2048 -smp 2 -cpu host \
+-device virtio-vga,virgl=on -display gtk,gl=on \
+-device usb-ehci \
+-device usb-kbd \
+-device usb-mouse \
+-device usb-tablet \
+-device ich9-intel-hda \
+-device hda-duplex,audiodev=snd0 \
+-audiodev pa,id=snd0 \
+-device usb-host,vendorid=0x046d,productid=0x08e5 \
+-boot menu=on \
+-nic bridge \
+~/QEMU_VM/android_x86_7.1-r5.img \
+
+in the kernel command there is "vga=1280x960"
+
+with "-device qxl" no problem. I get immediately a  window of size 1280x960.
+
+with "-device virtio-vga,virgl=on -display gtk,gl=on"
+
+i get a tiny window.
+
+i must uncheck "zoom to fit" to get a window of size 1280x960.
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+done
+
+Ticket has been moved here (thanks!):
+https://gitlab.com/qemu-project/qemu/-/issues/315
+... so I'm closing this on Launchpad now.
+
diff --git a/results/classifier/118/kernel/1926249 b/results/classifier/118/kernel/1926249
new file mode 100644
index 000000000..2875ad081
--- /dev/null
+++ b/results/classifier/118/kernel/1926249
@@ -0,0 +1,64 @@
+kernel: 0.925
+permissions: 0.880
+device: 0.844
+KVM: 0.809
+user-level: 0.794
+PID: 0.791
+semantic: 0.791
+ppc: 0.787
+graphic: 0.775
+VMM: 0.744
+socket: 0.715
+architecture: 0.675
+arm: 0.675
+debug: 0.674
+register: 0.638
+TCG: 0.618
+performance: 0.615
+mistranslation: 0.608
+virtual: 0.581
+vnc: 0.556
+network: 0.545
+risc-v: 0.544
+files: 0.539
+boot: 0.538
+hypervisor: 0.497
+x86: 0.476
+i386: 0.446
+peripherals: 0.369
+assembly: 0.319
+
+postcopy migration fails in hirsute (solved)
+
+FYI: this is an intended change, can be overwritten via config and this bug is mostly to have something puzzled users can find via search engines to explain and solve their issue.
+
+postcopy migration can in some cases be very useful
+=> https://wiki.qemu.org/Features/PostCopyLiveMigration
+
+But with Hirsute kernel being 5.11 that now contains the following upstream change
+=> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0d4730ac2
+
+Due to that postcopy migration will fail like:
+
++ lxc exec testkvm-focal-from -- virsh migrate --unsafe --live --postcopy --postcopy-after-precopy kvmguest-focal-postcopy qemu+ssh://10.85.93.248/system
+error: internal error: unable to execute QEMU command 'migrate-set-capabilities': Postcopy is not supported
+
+This will also apply to e.g. a Focal-HWE kernel once on v5.11 or to Focal userspaces in a container under a Hirsute kernel (that is the example above).
+
+This was done for security reasons, if you want/need to re-enable un-limited userfault handling to be able to use postcopy again you'd want/need to set the control knob to one like:
+$ sudo sysctl -w "vm.unprivileged_userfaultfd=1"
+
+Also documented in https://askubuntu.com/questions/1334249/qemu-kvm-postcopy-migration-fails-in-hirsute-v5-11-kernels-solved/1334250
+
+Also added as known issue in https://discourse.ubuntu.com/t/hirsute-hippo-release-notes/19221
+
+I hope that this will help the case to be found by affected users.
+
+juju config live-migration-permit-post-copy on the nova-compute charm, could auto enable vm.unprivileged_userfaultfd=1, or at least state this requirement on it's description.
+
+I'm assigning this to won't fix based on it being a hirsute issue.  Hirsuite is EOL as of January 20, 2022. However, if this is affecting newer releases of Ubuntu then please re-open.  thanks.
+
+Hi @ajkavanagh, this affects focal-hwe, jammy and will affect any new releases unless this sysctl is set to 1.
+
+Based on @felipe's comment in #4, I'm triaging to medium.  A possible fix is to enable the sysctl to be executed if the config option " enable-live-migration" is set to True in the charm.  This is relatively easy to do.  It should also be documented in the charm-guide if the fix is done.
+
diff --git a/results/classifier/118/kernel/1939179 b/results/classifier/118/kernel/1939179
new file mode 100644
index 000000000..f704bee22
--- /dev/null
+++ b/results/classifier/118/kernel/1939179
@@ -0,0 +1,61 @@
+kernel: 0.939
+device: 0.784
+user-level: 0.768
+mistranslation: 0.761
+semantic: 0.725
+graphic: 0.706
+hypervisor: 0.612
+files: 0.597
+performance: 0.491
+ppc: 0.419
+register: 0.403
+architecture: 0.388
+socket: 0.371
+virtual: 0.359
+vnc: 0.330
+boot: 0.319
+PID: 0.307
+network: 0.299
+permissions: 0.297
+i386: 0.288
+arm: 0.277
+risc-v: 0.272
+x86: 0.268
+debug: 0.224
+assembly: 0.207
+VMM: 0.194
+TCG: 0.190
+peripherals: 0.145
+KVM: 0.083
+
+qemu-ga fsfreeze crashes the kernel
+
+Hello,
+
+Still required your attention, duplicate from:
+https://bugs.launchpad.net/bugs/1807073
+https://bugs.launchpad.net/bugs/1813045
+
+We use mainly Cloudlinux, Debian and Centos.
+We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot.
+The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening:
+
+When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation:
+1) freeze loopback fs
+              ---> send async reqs to loopback thread
+2) freeze main fs
+3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash.
+
+Moreover, a lot of Proxmox users are complaining about the issue as well:
+https://forum.proxmox.com/threads/error-vm-100-qmp-command-guest-fsfreeze-thaw-failed-got-timeout.68082/
+https://forum.proxmox.com/threads/problem-with-fsfreeze-freeze-and-qemu-guest-agent.65707/
+
+We are currently in progress of retiring this bug tracker here... could you please open a new ticket on gitlab instead:
+
+ https://gitlab.com/qemu-project/qemu/-/issues
+
+Thanks and sorry for the inconvenience.
+
+https://gitlab.com/qemu-project/qemu/-/issues/520
+... thanks!
+
diff --git a/results/classifier/118/kernel/1991 b/results/classifier/118/kernel/1991
new file mode 100644
index 000000000..378ae3206
--- /dev/null
+++ b/results/classifier/118/kernel/1991
@@ -0,0 +1,94 @@
+kernel: 0.979
+files: 0.942
+boot: 0.912
+graphic: 0.911
+socket: 0.905
+device: 0.895
+permissions: 0.887
+user-level: 0.885
+architecture: 0.877
+performance: 0.859
+PID: 0.836
+VMM: 0.828
+i386: 0.807
+x86: 0.803
+debug: 0.802
+ppc: 0.800
+mistranslation: 0.792
+semantic: 0.778
+KVM: 0.754
+hypervisor: 0.749
+network: 0.740
+register: 0.708
+vnc: 0.698
+risc-v: 0.640
+peripherals: 0.635
+TCG: 0.601
+arm: 0.574
+virtual: 0.524
+assembly: 0.326
+
+error "hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached" in qemu-system-hppa
+Description of problem:
+The installation phase terminates with a failed assertion in qemu:
+```
+...
+Rebooting the system
+reboot: Restarting system
+SeaBIOS wants SYSTEM RESET.
+***************************
+**
+ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached
+Bail out! ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached
+Aborted (core dumped)
+```
+Steps to reproduce:
+```
+PATH=$HOME/inst-qemu/8.2.0-rc0/bin:$PATH
+```
+
+Create empty disk:
+```
+qemu-img create -f qcow2 t2sde.qcow2 10G
+```
+
+Pull kernel and initrd out of the installation CD:
+```
+sudo mount -r -t iso9660 -o loop t2-23.6-hppa-minimal-desktop-gcc-glibc.iso /mnt
+mkdir boot-for-install
+cp -p /mnt/boot/* boot-for-install/
+sudo umount /mnt
+```
+
+Run installer:
+```
+machine_args="-M C3700 -m 256"
+disk_args="-drive file=t2sde.qcow2,format=qcow2,id=hd0"
+net_args=""
+#display_args="-monitor stdio -display gtk"
+display_args="-nographic"
+common_args="$machine_args $disk_args $net_args $display_args"
+qemu-system-hppa $common_args \
+  -kernel boot-for-install/vmlinux-6.3.7-t2 -initrd boot-for-install/initrd-6.3.7-t2 \
+  -drive file=t2-23.6-hppa-minimal-desktop-gcc-glibc.iso,if=scsi,bus=0,unit=2,media=cdrom
+```
+
+```
+Serial terminal: <Enter> or console
+# install
+Partition:
+  fdisk
+  n p 1 <Enter> <Enter>
+  w
+On /dev/sda1: Create filesystem of type ext3 with mount point /
+Install the system
+Full install (all packages).
+Keyboard: us
+Root password: t2
+Time zone: Europe/Berlin
+Locale: --
+Finally: <Back>
+Then: <Exit>
+```
+Additional information:
+
diff --git a/results/classifier/118/kernel/2000 b/results/classifier/118/kernel/2000
new file mode 100644
index 000000000..2918d67f9
--- /dev/null
+++ b/results/classifier/118/kernel/2000
@@ -0,0 +1,75 @@
+kernel: 0.966
+files: 0.931
+device: 0.921
+peripherals: 0.894
+socket: 0.878
+permissions: 0.875
+architecture: 0.860
+VMM: 0.855
+mistranslation: 0.833
+network: 0.829
+performance: 0.822
+register: 0.810
+vnc: 0.806
+graphic: 0.802
+PID: 0.797
+boot: 0.726
+arm: 0.710
+x86: 0.673
+user-level: 0.671
+ppc: 0.669
+hypervisor: 0.626
+semantic: 0.616
+i386: 0.591
+debug: 0.588
+risc-v: 0.544
+virtual: 0.540
+assembly: 0.465
+TCG: 0.431
+KVM: 0.361
+
+m68k: error "fatal: Unimplemented control register write 0x0 = 0x1"
+Description of problem:
+An attempt to run the NetBSD m68k kernel under QEMU crashes.
+The error message is:
+```
+qemu: fatal: Unimplemented control register write 0x0 = 0x1
+```
+Steps to reproduce:
+1. ```wget http://cdn.netbsd.org/pub/NetBSD/iso/9.3/NetBSD-9.3-mac68k.iso```
+2. Pull kernel out of the installation CD:
+```
+sudo mount -r -t iso9660 -o loop /home/bruno/vms/os-install-media/NetBSD-9.3-mac68k.iso /mnt
+cp /mnt/mac68k/binary/kernel/netbsd-GENERIC.gz .
+sudo umount /mnt
+chmod u+w netbsd-GENERIC.gz
+gunzip netbsd-GENERIC.gz
+```
+3. ```qemu-img create -f qcow2 netbsd93.qcow2 10G```
+4. ```qemu-system-m68k -m 256 -drive file=netbsd93.qcow2,format=qcow2,index=0 -nographic -kernel netbsd-GENERIC -cdrom NetBSD-9.3-mac68k.iso```
+
+It crashes like this:
+```
+qemu: fatal: Unimplemented control register write 0x0 = 0x1
+
+D0 = 00000001   A0 = 00000000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000000   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000000   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 00330346   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 00002e14   SR = 2700 T:0 I:7 SI -----
+FPSR = 00000000 ----
+                                FPCR =     0000 X RN
+  A7(MSP) = 00000000 ->A7(USP) = 00330346   A7(ISP) = 00000000
+VBR = 0x00000000
+SFC = 0 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+Aborted (core dumped)
+```
+Additional information:
+
diff --git a/results/classifier/118/kernel/2037 b/results/classifier/118/kernel/2037
new file mode 100644
index 000000000..ac1463f6b
--- /dev/null
+++ b/results/classifier/118/kernel/2037
@@ -0,0 +1,45 @@
+kernel: 0.979
+graphic: 0.959
+x86: 0.949
+device: 0.927
+KVM: 0.898
+semantic: 0.849
+architecture: 0.822
+boot: 0.800
+TCG: 0.771
+debug: 0.744
+user-level: 0.730
+ppc: 0.728
+PID: 0.721
+VMM: 0.700
+i386: 0.676
+performance: 0.675
+vnc: 0.655
+network: 0.644
+register: 0.619
+permissions: 0.617
+hypervisor: 0.609
+mistranslation: 0.483
+arm: 0.482
+risc-v: 0.447
+files: 0.434
+virtual: 0.409
+socket: 0.340
+peripherals: 0.328
+assembly: 0.202
+
+CPUID.07H:EBX.intel-pt not supported warning info shown in terminal when start guest with -cpu qemu64,+intel-pt
+Description of problem:
+When launch guest with qemu-system-x86_64 with parameter -cpu host,+intel-pt, it will show warning info in terminal :
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25] 'intel_pt' can not be found  in guest's CPU flag. 
+While host already support intel_pt.
+Steps to reproduce:
+1. Run the above QEMU command.
+Additional information:
+This issue was observed with kernel 5.13
+
+qemu-system-x86_64 -accel kvm -m 4096 -smp 4 -cpu host,+intel-pt,min-level=0x14
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
+qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:EBX.intel-pt [bit 25]
diff --git a/results/classifier/118/kernel/2074 b/results/classifier/118/kernel/2074
new file mode 100644
index 000000000..27ff14cab
--- /dev/null
+++ b/results/classifier/118/kernel/2074
@@ -0,0 +1,50 @@
+kernel: 0.902
+debug: 0.848
+graphic: 0.839
+device: 0.680
+performance: 0.679
+boot: 0.672
+architecture: 0.650
+risc-v: 0.549
+semantic: 0.448
+x86: 0.416
+peripherals: 0.375
+user-level: 0.371
+permissions: 0.314
+PID: 0.280
+ppc: 0.246
+mistranslation: 0.233
+register: 0.228
+i386: 0.213
+virtual: 0.210
+vnc: 0.171
+socket: 0.147
+network: 0.129
+hypervisor: 0.118
+TCG: 0.113
+VMM: 0.102
+assembly: 0.101
+KVM: 0.093
+arm: 0.072
+files: 0.063
+
+riscv64  cannot use the mret instruction to jump to the address corresponding to s mode
+Description of problem:
+I use coreboot to boot my linux kernel.The kernel is copied at 0x82200000,I set reg mepc 0x82200000,and set reg mstatus a00000800.
+and I use "mret" instruction so that qemu can jump to 0x82200000 and enter S mode.But some errors happened.
+It shows:
+[DEBUG]  Exception:          Instruction access fault
+[DEBUG]  Hart ID:            0
+[DEBUG]  Previous mode:      machine
+[DEBUG]  Bad instruction pc: 0x8103f7c0
+[DEBUG]  Bad address:        0x00000000
+[DEBUG]  Stored ra:          0x8103f7b8
+[DEBUG]  Stored sp:          0x82032f08
+Bad instruction pc: 0x8103f7c0 in my elf file instruction is "mret".
+So I can not jump to my kernel's load address.
+I think when I use -bios option,my qemu should in M mode.How could I can jump to my mepc address?
+Steps to reproduce:
+1.download qemu
+2.download coreboot
+Additional information:
+When I enter qemu with -bios option,I find that the reg mstatus is 0xa0000000.
diff --git a/results/classifier/118/kernel/2226 b/results/classifier/118/kernel/2226
new file mode 100644
index 000000000..ff39aa9f4
--- /dev/null
+++ b/results/classifier/118/kernel/2226
@@ -0,0 +1,86 @@
+register: 0.977
+architecture: 0.976
+arm: 0.933
+kernel: 0.930
+virtual: 0.928
+ppc: 0.877
+boot: 0.855
+socket: 0.855
+graphic: 0.852
+risc-v: 0.844
+peripherals: 0.823
+performance: 0.802
+vnc: 0.795
+permissions: 0.790
+device: 0.777
+debug: 0.738
+assembly: 0.722
+PID: 0.702
+network: 0.683
+TCG: 0.679
+files: 0.660
+VMM: 0.652
+hypervisor: 0.619
+semantic: 0.609
+user-level: 0.607
+i386: 0.547
+KVM: 0.509
+mistranslation: 0.494
+x86: 0.480
+
+arm HSTR trap settings routed to EL1 instead of EL2
+Description of problem:
+ARM's HSTR register is used to trap CP15 access from EL1/0. qemu's implementation seems to be inconsistent with ARM's documentation.
+
+Take the system register VBAR for example, the following pseudo code is grabbed from ARM DDI 0487J.a ID042523 G8-10651, which is the logics behind when reading VBAR.
+```
+if PSTATE.EL == EL0 then
+    UNDEFINED;
+elsif PSTATE.EL == EL1 then
+    if EL2Enabled() && !ELUsingAArch32(EL2) && HSTR_EL2.T12 == '1' then
+        AArch64.AArch32SystemAccessTrap(EL2, 0x03);
+    elsif EL2Enabled() && ELUsingAArch32(EL2) && HSTR.T12 == '1' then
+        AArch32.TakeHypTrapException(0x03);
+    elsif HaveEL(EL3) && ELUsingAArch32(EL3) then
+        R[t] = VBAR_NS;
+    else
+        R[t] = VBAR;
+elsif PSTATE.EL == EL2 then
+    if HaveEL(EL3) && ELUsingAArch32(EL3) then
+        R[t] = VBAR_NS;
+    else
+        R[t] = VBAR;
+elsif PSTATE.EL == EL3 then
+    if SCR.NS == '0' then
+        R[t] = VBAR_S;
+    else
+        R[t] = VBAR_NS;
+```
+
+The main logics in my attached test program are:
+1. Setting EL2 and EL1's exception table
+2. Set HSTR.T12
+3. ERET to EL1, and read VBAR from EL1
+
+As the document mentions, when CPU running on EL1 && HSTR.T12 is set, HypTrapException 0x3 should be taken, which is EL2. But the test program shows, on such circumstances, CPU is being routed to EL1's undefined exception.
+Steps to reproduce:
+1. Clone this repo https://github.com/roolrz/reproduce-qemu-arm-hstr-issue
+2. Use make to build the test program
+3. Use following command to launch it
+```
+qemu-system-arm \
+	-nographic \
+	-cpu cortex-a7 \
+	-M virt,virtualization=on \
+	-m 1G \
+	-kernel el2.elf
+```
+4. The following message is printed by the program, problem reproduced
+```
+EL2 Booted
+Jumping to el1
+el1 reached, triggering trap
+EL1 undefined sync triggered
+```
+Additional information:
+
diff --git a/results/classifier/118/kernel/2281 b/results/classifier/118/kernel/2281
new file mode 100644
index 000000000..3013bfec0
--- /dev/null
+++ b/results/classifier/118/kernel/2281
@@ -0,0 +1,37 @@
+kernel: 0.949
+debug: 0.924
+graphic: 0.918
+device: 0.807
+semantic: 0.624
+architecture: 0.475
+register: 0.470
+network: 0.456
+files: 0.436
+arm: 0.429
+PID: 0.389
+socket: 0.389
+risc-v: 0.366
+boot: 0.341
+TCG: 0.339
+vnc: 0.284
+performance: 0.274
+ppc: 0.268
+VMM: 0.208
+permissions: 0.181
+virtual: 0.126
+mistranslation: 0.118
+user-level: 0.117
+i386: 0.080
+peripherals: 0.076
+assembly: 0.060
+x86: 0.055
+hypervisor: 0.024
+KVM: 0.006
+
+[bugfix incl.] Solaris Debuggers Panic OS with "Nonparity Synchronous Error"
+Description of problem:
+General use of a debugger (mdb, adb, gdb), such as single-stepping, causing a breakpoint to trigger, and/or simply running a program will cause a kernel panic of "Nonparity Synchronous Error" on many versions of Solaris / SunOS.
+
+This a well reported issue.
+
+#
diff --git a/results/classifier/118/kernel/2284 b/results/classifier/118/kernel/2284
new file mode 100644
index 000000000..b679751b6
--- /dev/null
+++ b/results/classifier/118/kernel/2284
@@ -0,0 +1,31 @@
+kernel: 0.968
+arm: 0.784
+device: 0.763
+graphic: 0.610
+performance: 0.563
+virtual: 0.448
+debug: 0.379
+semantic: 0.315
+mistranslation: 0.257
+permissions: 0.236
+ppc: 0.222
+user-level: 0.208
+network: 0.186
+register: 0.152
+vnc: 0.143
+PID: 0.140
+architecture: 0.120
+VMM: 0.103
+boot: 0.102
+i386: 0.099
+risc-v: 0.097
+x86: 0.075
+files: 0.072
+TCG: 0.058
+assembly: 0.056
+hypervisor: 0.052
+peripherals: 0.049
+socket: 0.032
+KVM: 0.023
+
+sunxi avocado tests: kernel no longer available on armbian
diff --git a/results/classifier/118/kernel/2384 b/results/classifier/118/kernel/2384
new file mode 100644
index 000000000..1d4eeefa3
--- /dev/null
+++ b/results/classifier/118/kernel/2384
@@ -0,0 +1,56 @@
+arm: 0.962
+kernel: 0.943
+graphic: 0.931
+device: 0.914
+assembly: 0.909
+files: 0.903
+PID: 0.897
+architecture: 0.881
+ppc: 0.845
+vnc: 0.834
+user-level: 0.818
+hypervisor: 0.817
+performance: 0.813
+x86: 0.786
+debug: 0.785
+register: 0.776
+VMM: 0.765
+socket: 0.743
+permissions: 0.734
+risc-v: 0.731
+boot: 0.718
+semantic: 0.712
+peripherals: 0.705
+network: 0.686
+TCG: 0.682
+mistranslation: 0.642
+virtual: 0.636
+i386: 0.624
+KVM: 0.334
+
+Crash on QEMU 7.2.11 with imx6ul arm cpu cortex-a7 when trying to mount rootfs
+Description of problem:
+trying to run qemu 7.2.11 for NXP mcimx6ul-evk machine, We get a kernel panic trying to mount the rootfs.
+...
+[    7.401206]   No soundcards found.
+[    7.500010] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
+[    7.504607] VFS: Mounted root (vfat filesystem) on device 179:1.
+[    7.511987] devtmpfs: error mounting -2
+[    7.612562] Freeing unused kernel image (initmem) memory: 1024K
+[    7.638370] Run /sbin/init as init process
+[    7.638829]   with arguments:
+[    7.639016]     /sbin/init
+[    7.639247]     earlyprintk
+[    7.639429]     noresume
+...
+[    7.657347] Kernel panic - not syncing: No working init found.
+
+The full log is attached.[qemu_imx6ul_kernel_panic_info.txt](/uploads/c4075a3de7894c18050bf53c32bb18a7/qemu_imx6ul_kernel_panic_info.txt)
+Steps to reproduce:
+1. download and build qemu 7.2.11
+2. download LF_v6.1.55-2.2.1_images_IMX6UL7D.zip from NXP containing kernel, dtb, rootfs, ...etc binaries 
+3. To use diskimage as ‘sd’ card , we need to shrink .wic image we got from NXP to fit in 4GB : 
+./qemu-img resize --shrink imx-image-full.wic 4G
+4. invoke the command to run qemu described above.
+Additional information:
+Any help would be appreciated, if it's not the right forum please advise, thank you.
diff --git a/results/classifier/118/kernel/2500 b/results/classifier/118/kernel/2500
new file mode 100644
index 000000000..a9964b3f3
--- /dev/null
+++ b/results/classifier/118/kernel/2500
@@ -0,0 +1,34 @@
+kernel: 0.887
+graphic: 0.818
+device: 0.817
+semantic: 0.810
+assembly: 0.807
+architecture: 0.777
+mistranslation: 0.739
+network: 0.738
+debug: 0.584
+performance: 0.549
+i386: 0.512
+socket: 0.510
+arm: 0.442
+hypervisor: 0.350
+user-level: 0.296
+files: 0.279
+peripherals: 0.279
+boot: 0.257
+PID: 0.238
+permissions: 0.233
+register: 0.224
+virtual: 0.202
+ppc: 0.194
+x86: 0.184
+risc-v: 0.163
+vnc: 0.154
+VMM: 0.118
+KVM: 0.115
+TCG: 0.087
+
+m68k: mmu: 68030 mmu instructions are missing
+Description of problem:
+The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??).
+QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu.
diff --git a/results/classifier/118/kernel/2657 b/results/classifier/118/kernel/2657
new file mode 100644
index 000000000..87cbd208d
--- /dev/null
+++ b/results/classifier/118/kernel/2657
@@ -0,0 +1,41 @@
+kernel: 0.985
+graphic: 0.969
+virtual: 0.933
+boot: 0.837
+device: 0.831
+vnc: 0.776
+register: 0.714
+files: 0.702
+semantic: 0.651
+PID: 0.621
+VMM: 0.611
+socket: 0.572
+performance: 0.522
+permissions: 0.504
+network: 0.492
+debug: 0.484
+architecture: 0.460
+TCG: 0.425
+ppc: 0.415
+hypervisor: 0.364
+risc-v: 0.345
+mistranslation: 0.304
+arm: 0.281
+x86: 0.256
+i386: 0.247
+user-level: 0.219
+assembly: 0.186
+peripherals: 0.107
+KVM: 0.082
+
+Kernel crashed when installing OpenServer 6 D2M2a
+Description of problem:
+The kernel crashed when finishing installation.
+Steps to reproduce:
+1. Download OpenServer6D2M2a-DVD.iso for free from Xinuos website(a free account is needed, but the registation is easy to be done)
+2. Create new virtual hard drive
+3. Boot the installation ISO
+4. Install with all default settings and all packages, evaluate license is okay.
+5. Boom!
+Additional information:
+![QQ20241106-110404](/uploads/b42d5d6fef34606b4a6c672e33f06b97/QQ20241106-110404.png)
diff --git a/results/classifier/118/kernel/2794 b/results/classifier/118/kernel/2794
new file mode 100644
index 000000000..b2e7cf12f
--- /dev/null
+++ b/results/classifier/118/kernel/2794
@@ -0,0 +1,79 @@
+kernel: 0.943
+device: 0.881
+architecture: 0.837
+graphic: 0.825
+boot: 0.797
+ppc: 0.707
+PID: 0.654
+performance: 0.596
+permissions: 0.567
+debug: 0.540
+register: 0.448
+vnc: 0.430
+user-level: 0.416
+semantic: 0.399
+VMM: 0.379
+virtual: 0.354
+risc-v: 0.349
+x86: 0.335
+network: 0.280
+files: 0.243
+peripherals: 0.242
+assembly: 0.228
+mistranslation: 0.219
+socket: 0.202
+TCG: 0.195
+arm: 0.143
+i386: 0.116
+hypervisor: 0.100
+KVM: 0.067
+
+qemu-system-m68k virt machine doesn't boot Linux kernels using 68020, 68030 and 68060 CPUs
+Description of problem:
+QEMU doesn't seem to be able to start Linux kernels using a CPU other than a 68040 (which does work fine)
+
+To rule out host issues, the issue is reproductible on Debian Unstable amd64 (with version QEMU emulator version 9.2.0)(Debian 1:9.2.0+ds-5))
+
+To rule out cross-compilation issues, the kernel has been rebuild inside a virt machine (using a 68040 CPU), running Debian Unstable 
+
+Each CPU model below gets stuck early before kernel boot during the ABCGHIJK thing. The Kernel doesn't seem to boot and QEMU process eat 100% of a CPU physical core
+
+**68020**
+```
+qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux
+ABCGH
+```
+
+**68030**
+```
+qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux
+ABC
+```
+
+**68060**
+```
+qemu-system-m68k -M virt -cpu m68060 -m 1G -nographic -kernel /home/demik/tmp/vmlinux
+ABC
+```
+Steps to reproduce:
+1. build a kernel with 68020/030/060 support (using virt_defconfig as base)
+2. start QEMU with the command line above
+Additional information:
+68020 is understandable as it may need some sort of 68851 emulation.
+
+Relevant Kernel config Processor configuration:
+```
+#
+# Processor Type
+#
+CONFIG_M68KCLASSIC=y
+# CONFIG_COLDFIRE is not set
+CONFIG_M68020=y
+CONFIG_M68030=y
+CONFIG_M68040=y
+CONFIG_M68060=y
+```
+
+This may be related to the following issues (but I don't have the skillset to confirm that)
+- https://gitlab.com/qemu-project/qemu/-/issues/2091
+- https://gitlab.com/qemu-project/qemu/-/issues/2500
diff --git a/results/classifier/118/kernel/2833 b/results/classifier/118/kernel/2833
new file mode 100644
index 000000000..069b4dd00
--- /dev/null
+++ b/results/classifier/118/kernel/2833
@@ -0,0 +1,49 @@
+kernel: 0.888
+permissions: 0.873
+graphic: 0.853
+device: 0.838
+boot: 0.835
+debug: 0.826
+performance: 0.817
+vnc: 0.813
+ppc: 0.787
+files: 0.784
+peripherals: 0.777
+architecture: 0.769
+socket: 0.768
+network: 0.745
+risc-v: 0.735
+mistranslation: 0.724
+semantic: 0.723
+hypervisor: 0.705
+PID: 0.702
+register: 0.686
+KVM: 0.660
+i386: 0.652
+arm: 0.638
+x86: 0.625
+VMM: 0.614
+assembly: 0.586
+TCG: 0.578
+virtual: 0.546
+user-level: 0.494
+
+Inconsistent `Tn_INT_ROUTE_CAP` and `Tn_INT_ROUTE_CNF` in HPET
+Description of problem:
+In the [HPET specification](http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/software-developers-hpet-spec-1-0a.pdf) it says:
+>  Timer n Interrupt Routing Capability: (where n is the timer number: 00 to 31) This 32-bit read-only field indicates to which interrupts in the I/O (x) APIC this timer’s interrupt can be routed. This is used in conjunction with the Tn_INT_ROUTE_CNF field.
+> 
+> Each bit in this field corresponds to a particular interrupt. For example, if this timer’s interrupt can be mapped to interrupts 16, 18, 20, 22, or 24, then bits 16, 18, 20, 22, and 24 in this field will be set to 1. All other bits will be 0.
+
+
+> Timer n Interrupt Route: (where n is the timer number: 00 to 31). This 5-bit read/write field indicates the routing for the interrupt to the I/O APIC. A maximum value of 32 interrupts are supported. Default is 00h Software writes to this field to select which interrupt in the I/O (x) will be used for this timer’s interrupt. If the value is not supported by this prarticular timer, then the value read back will not match what is written. The software must only write valid values.
+
+In QEMU, the HPET timers indicate that the only I/O APIC IRQ they support is IRQ 2 (based only bit 2 being 1). But actually the HPET interrupt works even if I set it to IRQ 20, which is inconsistent with the `Tn_INT_ROUTE_CAP` that the timer shows.
+
+The HPET should show that it works with more than just IRQ 2.
+Steps to reproduce:
+1. Git checkout https://github.com/ChocolateLoverRaj/code-runner/tree/fd368f53c1c99885a3b149a59f2959f383f42859
+2. `nix develop`
+3. `cargo r -- -s -serial mon:stdio --no-reboot -nographic -d int`
+Additional information:
+
diff --git a/results/classifier/118/kernel/444 b/results/classifier/118/kernel/444
new file mode 100644
index 000000000..45b496618
--- /dev/null
+++ b/results/classifier/118/kernel/444
@@ -0,0 +1,31 @@
+kernel: 0.928
+architecture: 0.803
+device: 0.761
+arm: 0.565
+performance: 0.520
+debug: 0.516
+i386: 0.488
+x86: 0.484
+boot: 0.443
+ppc: 0.438
+TCG: 0.437
+graphic: 0.409
+semantic: 0.408
+PID: 0.400
+network: 0.384
+risc-v: 0.383
+KVM: 0.355
+VMM: 0.353
+vnc: 0.333
+register: 0.280
+permissions: 0.241
+socket: 0.241
+mistranslation: 0.215
+user-level: 0.197
+virtual: 0.179
+peripherals: 0.059
+assembly: 0.049
+files: 0.040
+hypervisor: 0.035
+
+EFI stub: ERROR: This 64 KB granular kernel is not supported by your CPU
diff --git a/results/classifier/118/kernel/485239 b/results/classifier/118/kernel/485239
new file mode 100644
index 000000000..74acac40d
--- /dev/null
+++ b/results/classifier/118/kernel/485239
@@ -0,0 +1,68 @@
+kernel: 0.903
+virtual: 0.882
+user-level: 0.881
+graphic: 0.850
+vnc: 0.839
+boot: 0.834
+x86: 0.833
+performance: 0.792
+architecture: 0.785
+KVM: 0.762
+hypervisor: 0.758
+device: 0.751
+peripherals: 0.739
+mistranslation: 0.729
+files: 0.702
+register: 0.694
+PID: 0.678
+semantic: 0.647
+permissions: 0.629
+debug: 0.617
+network: 0.612
+socket: 0.596
+VMM: 0.579
+risc-v: 0.540
+ppc: 0.528
+TCG: 0.483
+arm: 0.430
+i386: 0.385
+assembly: 0.352
+
+Windows 2008 datacenter- 64 bit , installation fails with qemu-system-x86_64 0.11.50
+
+Installation of Windows 2008 datacenter- 64 bit fails with qemu-system-x86_64. 
+Version of qemu-system-x86_64 is 0.11.50. 
+The installation source is dvd iso. Just after booting for installation of the Windows guest, it hangs for sometime and then the installation crashes with the error:
+
+"A problem has been detected and windows has been shut down to prevent damage to your computer".
+
+Below is the command used for creating the guest.
+/usr/local/bin/qemu-system-x86_64 -cdrom /home/en_windows_server_2008_datacenter_enterprise_standard_x64_dvd_X14-26714.iso -hda /var/lib/libvirt/images/win2008_dc_64.qcow2 -m 3000 -smp 3 -net nic -net tap,script=/home/qemu-ifup-latest -name win2008_dc_64 -vnc :1 &
+
+Disk info of the guest image is as below:
+/usr/local/bin/qemu-img info /var/lib/libvirt/images/win2008_dc_64.qcow2
+image: /var/lib/libvirt/images/win2008_dc_64.qcow2
+file format: qcow2
+virtual size: 15G (16106127360 bytes)
+disk size: 136K
+cluster_size: 65536
+
+This issue is also reproducible with raw image format.
+
+
+
+I am experiencing similar problems with Win2008 / Win7 guests; BSOD when trying to install; sometimes before the first screen, sometimes just after.
+
+Using Ubuntu Lucid:
+kernel 2.6.32-21-server
+qemu-kvm-0.12.3
+
+Also on Fedora 12:
+kernel 2.6.32.12-115.fc12.x86_64
+qemu-0.11.0-13.fc12.x86_64
+qemu-system-x86-0.11.0-13.fc12.x86_64
+
+I've tried qcow2 and raw, with/without network device, cirrus/std/vmware vga... suggestions welcomed.
+
+Please try the latest version. The version you reported is too old.
+
diff --git a/results/classifier/118/kernel/512 b/results/classifier/118/kernel/512
new file mode 100644
index 000000000..ccd319d2e
--- /dev/null
+++ b/results/classifier/118/kernel/512
@@ -0,0 +1,31 @@
+kernel: 0.896
+device: 0.887
+performance: 0.784
+network: 0.720
+files: 0.714
+architecture: 0.712
+vnc: 0.674
+register: 0.659
+VMM: 0.568
+mistranslation: 0.556
+TCG: 0.543
+socket: 0.542
+boot: 0.540
+risc-v: 0.534
+arm: 0.531
+PID: 0.525
+debug: 0.455
+graphic: 0.451
+ppc: 0.433
+peripherals: 0.417
+semantic: 0.416
+permissions: 0.291
+i386: 0.260
+virtual: 0.250
+user-level: 0.235
+hypervisor: 0.218
+x86: 0.210
+KVM: 0.157
+assembly: 0.132
+
+6.1.0-rc1 New regression (not in 6.1.0-rc0): Freezes using UEFI firmware without acceleration
diff --git a/results/classifier/118/kernel/520 b/results/classifier/118/kernel/520
new file mode 100644
index 000000000..9afd64b44
--- /dev/null
+++ b/results/classifier/118/kernel/520
@@ -0,0 +1,63 @@
+kernel: 0.911
+hypervisor: 0.828
+virtual: 0.818
+files: 0.810
+device: 0.790
+graphic: 0.763
+performance: 0.693
+register: 0.688
+permissions: 0.599
+PID: 0.588
+vnc: 0.586
+semantic: 0.552
+socket: 0.546
+ppc: 0.539
+risc-v: 0.512
+arm: 0.467
+user-level: 0.458
+i386: 0.457
+debug: 0.455
+architecture: 0.455
+VMM: 0.437
+boot: 0.412
+mistranslation: 0.408
+x86: 0.386
+TCG: 0.341
+network: 0.293
+KVM: 0.254
+assembly: 0.206
+peripherals: 0.136
+
+qemu-ga fsfreeze crashes the kernel
+Description of problem:
+Hello,
+
+Still required your attention, duplicate from:
+https://bugs.launchpad.net/bugs/1807073
+https://bugs.launchpad.net/bugs/1813045
+
+We use mainly Cloudlinux, Debian and Centos.
+We experienced many crashes on our qemu instances based on Cloudlinux during a snapshot.
+The issue is not related to CloudLinux directly, but to Qemu agent, which does not freeze the file system(s) correctly. What is actually happening:
+
+When VM backup is invoked, Qemu agent freezes the file systems, so no single change will be made during the backup. But Qemu agent does not respect the loop* devices in freezing order (we have checked its sources), which leads to the next situation:
+1) freeze loopback fs
+              ---> send async reqs to loopback thread
+2) freeze main fs
+3) loopback thread wakes up and trying to write data to the main fs, which is still frozen, and this finally leads to the hung task and kernel crash.
+
+Moreover, a lot of Proxmox users are complaining about the issue as well:
+https://forum.proxmox.com/threads/error-vm-100-qmp-command-guest-fsfreeze-thaw-failed-got-timeout.68082/
+https://forum.proxmox.com/threads/problem-with-fsfreeze-freeze-and-qemu-guest-agent.65707/
+Steps to reproduce:
+1. Manually start backup for the VM with qemu-agent enabled.
+2. The backup process stuck at "INFO: issuing guest-agent 'fs-freeze' command"
+3. The VM become unavailable, you can only unlock it and force reset.
+Additional information:
+/var/log/messages logs:  
+Aug  6 21:54:00 cpanel qemu-ga: info: guest-ping called  
+Aug  6 21:54:01 cpanel qemu-ga: info: guest-fsfreeze called  
+Aug  6 21:54:01 cpanel qemu-ga: info: executing fsfreeze hook with arg 'freeze'  
+
+
+after this the VM becomes completely unavailable.
diff --git a/results/classifier/118/kernel/598 b/results/classifier/118/kernel/598
new file mode 100644
index 000000000..01c77e65e
--- /dev/null
+++ b/results/classifier/118/kernel/598
@@ -0,0 +1,31 @@
+ppc: 0.992
+architecture: 0.937
+kernel: 0.937
+device: 0.920
+boot: 0.892
+debug: 0.596
+performance: 0.377
+graphic: 0.348
+mistranslation: 0.267
+semantic: 0.235
+peripherals: 0.225
+permissions: 0.195
+register: 0.116
+hypervisor: 0.086
+network: 0.083
+user-level: 0.061
+virtual: 0.061
+arm: 0.029
+socket: 0.024
+files: 0.024
+assembly: 0.017
+risc-v: 0.012
+TCG: 0.009
+VMM: 0.007
+PID: 0.004
+vnc: 0.003
+KVM: 0.002
+i386: 0.002
+x86: 0.001
+
+QEMU boot kernel for ppc e300c3 problem
diff --git a/results/classifier/118/kernel/627982 b/results/classifier/118/kernel/627982
new file mode 100644
index 000000000..9eeb0ddc8
--- /dev/null
+++ b/results/classifier/118/kernel/627982
@@ -0,0 +1,61 @@
+kernel: 0.935
+boot: 0.935
+mistranslation: 0.866
+register: 0.810
+PID: 0.732
+semantic: 0.724
+device: 0.688
+user-level: 0.599
+graphic: 0.579
+performance: 0.543
+permissions: 0.513
+virtual: 0.491
+x86: 0.487
+network: 0.463
+VMM: 0.443
+ppc: 0.420
+socket: 0.410
+vnc: 0.408
+architecture: 0.387
+i386: 0.379
+risc-v: 0.377
+files: 0.376
+TCG: 0.368
+peripherals: 0.350
+arm: 0.337
+assembly: 0.311
+debug: 0.303
+KVM: 0.279
+hypervisor: 0.239
+
+linux 2.6.35 hangs with -no-acpi
+
+Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance the Debian kernel:
+
+qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686 
+
+There is no output except just "Booting the kernel"
+
+  On 09/01/2010 01:54 PM, Samuel thibault wrote:
+> Public bug reported:
+>
+> Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance
+> the Debian kernel:
+>
+> qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686
+>
+> There is no output except just "Booting the kernel"
+>
+
+Is this a kernel regression?  A qemu regression?  What do 'info 
+registers' and 'x/20i $eip' show?
+
+You know better than this.
+
+-- 
+I have a truly marvellous patch that fixes the bug which this
+signature is too narrow to contain.
+
+
+Since kernel 2.6.35 is pretty much outdated nowadays, I think we can close this bug now (Feel free to re-open it if necessary).
+
diff --git a/results/classifier/118/kernel/664 b/results/classifier/118/kernel/664
new file mode 100644
index 000000000..00295498e
--- /dev/null
+++ b/results/classifier/118/kernel/664
@@ -0,0 +1,44 @@
+kernel: 0.917
+x86: 0.916
+architecture: 0.851
+device: 0.790
+graphic: 0.737
+performance: 0.731
+mistranslation: 0.722
+vnc: 0.678
+socket: 0.655
+network: 0.641
+ppc: 0.636
+PID: 0.583
+semantic: 0.561
+peripherals: 0.560
+boot: 0.533
+VMM: 0.531
+register: 0.516
+files: 0.507
+hypervisor: 0.506
+KVM: 0.489
+permissions: 0.486
+virtual: 0.465
+i386: 0.465
+risc-v: 0.463
+debug: 0.424
+arm: 0.410
+TCG: 0.385
+user-level: 0.321
+assembly: 0.277
+
+hvf-accelerated x86_64 incorrectly reports virtual address bit width via CPUID
+Description of problem:
+When running qemu-system-x86_64 with hvf acceleration enabled the maximum extended cpuid function (available via EAX=0x80000000) is reported to be 0x80000001, which means that physical address and virtual address bit width (which is supposed to be reported via EAX=0x80000008) is not available. As per the intel IA32/64 manual: `Processors that do not support CPUID function 80000008H, support a linear-address width of 32.`, while in actuality qemu-system-x86_64 with hvf acceleration supports virtual addresses of up to 48 bit in width, like most modern x86_64 processors.
+Steps to reproduce:
+This can be observed when running SerenityOS on x86_64 qemu with hvf acceleration based on the following dmesg lines:
+```
+[Kernel]: CPU[0]: Physical address bit width: 36
+[Kernel]: CPU[0]: Virtual address bit width: 32
+```
+But can also be reproduced by running the CPUID instruction with EAX set to 0x80000000 and observing that the returned value is 0x80000001.
+Additional information:
+The best way to resolve this as far as I can tell is to expose the 0x80000008 CPUID function and report the real values.
+
+NOTE: This is a report of the underlying bug that was found during the investigation of an issue raised in the SerenityOS repository, see https://github.com/SerenityOS/serenity/issues/10382 for more information.
diff --git a/results/classifier/118/kernel/677 b/results/classifier/118/kernel/677
new file mode 100644
index 000000000..29b24d35f
--- /dev/null
+++ b/results/classifier/118/kernel/677
@@ -0,0 +1,31 @@
+kernel: 0.968
+performance: 0.872
+device: 0.867
+architecture: 0.683
+graphic: 0.681
+arm: 0.483
+debug: 0.422
+boot: 0.347
+user-level: 0.157
+permissions: 0.112
+network: 0.100
+semantic: 0.097
+PID: 0.093
+risc-v: 0.082
+ppc: 0.081
+mistranslation: 0.071
+virtual: 0.070
+x86: 0.048
+assembly: 0.039
+register: 0.032
+vnc: 0.026
+hypervisor: 0.025
+i386: 0.019
+TCG: 0.010
+VMM: 0.008
+socket: 0.005
+peripherals: 0.003
+files: 0.003
+KVM: 0.002
+
+Qemu crashes when trying to load kernel inside of WSL2
diff --git a/results/classifier/118/kernel/679 b/results/classifier/118/kernel/679
new file mode 100644
index 000000000..fdabb92ff
--- /dev/null
+++ b/results/classifier/118/kernel/679
@@ -0,0 +1,31 @@
+architecture: 0.968
+ppc: 0.967
+kernel: 0.940
+device: 0.908
+performance: 0.809
+network: 0.630
+graphic: 0.610
+debug: 0.473
+arm: 0.470
+register: 0.379
+boot: 0.216
+semantic: 0.200
+socket: 0.148
+PID: 0.134
+permissions: 0.106
+files: 0.100
+hypervisor: 0.094
+mistranslation: 0.085
+user-level: 0.085
+TCG: 0.070
+peripherals: 0.060
+VMM: 0.051
+risc-v: 0.047
+virtual: 0.047
+vnc: 0.024
+assembly: 0.020
+x86: 0.016
+i386: 0.005
+KVM: 0.002
+
+powerpc/e500: QEMU freeze without any output when kernel size is a bit big
diff --git a/results/classifier/118/kernel/682360 b/results/classifier/118/kernel/682360
new file mode 100644
index 000000000..95bc1ad4f
--- /dev/null
+++ b/results/classifier/118/kernel/682360
@@ -0,0 +1,59 @@
+kernel: 0.927
+boot: 0.839
+x86: 0.827
+performance: 0.812
+graphic: 0.756
+architecture: 0.747
+device: 0.738
+semantic: 0.686
+vnc: 0.685
+debug: 0.638
+permissions: 0.633
+ppc: 0.594
+virtual: 0.576
+VMM: 0.568
+socket: 0.563
+register: 0.556
+assembly: 0.543
+user-level: 0.514
+PID: 0.504
+peripherals: 0.504
+hypervisor: 0.425
+mistranslation: 0.413
+risc-v: 0.379
+files: 0.375
+arm: 0.330
+i386: 0.291
+network: 0.279
+TCG: 0.214
+KVM: 0.112
+
+Unaccessible memory
+
+Hello,
+
+I'm trying to develop a OS over L4/X2 microkernel and I use Linux debian and qemu 0.13 in 64 bits mode. When I start qemu with qemu-system-x86_64 -hdc freevms.img -smp 1 -serial stdio -m 128M -k fr, my kernel boots fine. If I modify this command line with -m 384M (for example), my kernel is loaded but enter in a deadlock. I have found a bug in my code until I have tried to use the _same_ disk image under virtualbox and it works without any trouble. I runs fine on a real PC also.
+
+I have bissected my code and qemu stops (maybe in a deadlock) when I try to access to memory :
+%MEM-I-VM_ALLOC, adding $0000000000045000 - $0000000000108FFF to VM allocator
+%MEM-I-VM_ALLOC, adding $000000000010B000 - $00000000003F2FFF to VM allocator
+%MEM-I-VM_ALLOC, adding $000000000040C000 - $0000000000FFFFFF to VM allocator
+%MEM-I-VM_ALLOC, adding $000000000100F000 - $FFFFFEFFFFFFFFFF to VM allocator
+%MEM-I-ACCMAP, accepting mapping
+%MEM-I-ACCMAP, virtual  $FFFF000000000000 - $FFFF000000000FFF
+%MEM-I-ACCMAP, physical $000000000009E000 - $000000000009EFFF
+
+Note that qemu doesn't crash. It only stops. My virtual memory subsystem maps $FFFF000000000000 in physical memory ($9E000). And when I try to initialize this memory, qemu enters in deadlock.
+
+A disk image to reproduce this bug is available at http://www.systella.fr/~bertrand/freevms.img.bz2
+
+Regards,
+
+JKB
+
+This is a qemu emulator problem, whould qemu stop when the memory is larger than 128M? You can try  set the memory 256 to start vm.
+
+QEMU 0.13 is pretty much outdated nowadays ... can you still reproduce this issue with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/kernel/703 b/results/classifier/118/kernel/703
new file mode 100644
index 000000000..66a1b795d
--- /dev/null
+++ b/results/classifier/118/kernel/703
@@ -0,0 +1,47 @@
+kernel: 0.938
+device: 0.834
+virtual: 0.766
+boot: 0.718
+peripherals: 0.709
+ppc: 0.657
+semantic: 0.652
+vnc: 0.623
+socket: 0.586
+graphic: 0.586
+KVM: 0.574
+PID: 0.537
+network: 0.507
+risc-v: 0.491
+hypervisor: 0.446
+performance: 0.440
+architecture: 0.415
+register: 0.343
+arm: 0.339
+x86: 0.332
+i386: 0.322
+mistranslation: 0.299
+TCG: 0.290
+files: 0.255
+permissions: 0.254
+debug: 0.244
+VMM: 0.241
+user-level: 0.181
+assembly: 0.156
+
+Resizable BAR (ReBAR) support on VFIO
+Additional information:
+Currently `vfio_add_ext_cap()` doesn't pass ReBAR support option to VFIO.
+
+There was a report that removing the line you see below makes it boot, but the system is not stable.
+Needs investigation.
+
+[https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089](https://github.com/qemu/qemu/blob/2255564fd21059960966b47212def9069cb56077/hw/vfio/pci.c#L2089)
+```        switch (cap_id) {
+        case 0: /* kernel masked capability */
+        case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */
+        case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization */
+        case PCI_EXT_CAP_ID_REBAR: /* Can't expose read-only */
+            trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, next);
+```
+
+[Discussion link](https://forum.level1techs.com/t/smart-access-memory-vs-qemu-kvm/169447)
diff --git a/results/classifier/118/kernel/706 b/results/classifier/118/kernel/706
new file mode 100644
index 000000000..e1cb4f90d
--- /dev/null
+++ b/results/classifier/118/kernel/706
@@ -0,0 +1,68 @@
+kernel: 0.865
+virtual: 0.805
+PID: 0.735
+boot: 0.724
+performance: 0.702
+risc-v: 0.700
+graphic: 0.689
+ppc: 0.681
+device: 0.679
+peripherals: 0.657
+debug: 0.656
+vnc: 0.633
+semantic: 0.626
+VMM: 0.615
+hypervisor: 0.608
+permissions: 0.581
+architecture: 0.564
+user-level: 0.560
+mistranslation: 0.541
+KVM: 0.521
+register: 0.506
+network: 0.504
+TCG: 0.491
+arm: 0.485
+socket: 0.473
+files: 0.466
+x86: 0.416
+assembly: 0.400
+i386: 0.384
+
+NVMe End-to-End Data Protection
+Description of problem:
+When activating end-to-end data protection inside qemu NVMe virtual namespace, guest can not read or write anything to discovered /dev/nvme0n1. Guest kernel has NVMe support compiled-in, when booting i get the following messages related to emulated nvme pi-enabled drive inside guest:
+
+```
+[    0.661260] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[    0.663774] Buffer I/O error on dev nvme0n1, logical block 1, async page read
+[    0.665043] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[    0.666976] Buffer I/O error on dev nvme0n1, logical block 0, async page read
+[    0.676702] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[    0.678664] Buffer I/O error on dev nvme0n1, logical block 0, async page read
+[    0.679923] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[    0.681811] Buffer I/O error on dev nvme0n1, logical block 1, async page read
+[    0.683544]  nvme0n1: unable to read partition table
+```
+
+Same when trying to read anything:
+
+```
+/ # dd bs=512 count=1 skip=0 if=/dev/nvme0n1 iflag=direct
+[  432.017616] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
+[  432.020596] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[  432.023530] Buffer I/O error on dev nvme0n1, logical block 0, async page read
+[  432.025345] blk_update_request: protection error, dev nvme0n1, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+[  432.028289] Buffer I/O error on dev nvme0n1, logical block 1, async page read
+dd: /dev/nvme0n1: Input/output error
+``` 
+
+And write:
+
+```
+/ # dd bs=512 count=1 if=output.dat of=/dev/nvme0n1
+[  597.679455] blk_update_request: protection error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
+dd: error writing '/dev/nvme0n1': Input/output error
+1+0 records in
+0+0 records out
+0 bytes (0B) copied, 0.003864 seconds, 0B/s
+```
diff --git a/results/classifier/118/kernel/747 b/results/classifier/118/kernel/747
new file mode 100644
index 000000000..944aa2b2a
--- /dev/null
+++ b/results/classifier/118/kernel/747
@@ -0,0 +1,60 @@
+kernel: 0.807
+architecture: 0.796
+performance: 0.786
+peripherals: 0.674
+device: 0.668
+boot: 0.666
+arm: 0.639
+graphic: 0.623
+ppc: 0.601
+mistranslation: 0.569
+debug: 0.479
+user-level: 0.468
+PID: 0.455
+network: 0.431
+hypervisor: 0.387
+semantic: 0.381
+VMM: 0.352
+permissions: 0.289
+TCG: 0.279
+x86: 0.273
+register: 0.268
+files: 0.261
+socket: 0.261
+assembly: 0.258
+vnc: 0.252
+KVM: 0.182
+risc-v: 0.165
+virtual: 0.087
+i386: 0.028
+
+hvf-accelerated aarch64 hangs when switching to big endian mode
+Description of problem:
+Trying to boot a big endian Linux kernel using the above command line on an M1 Mac Mini just hangs, there is not a single output.  However, by replacing `hvf` with `tcg`, the kernel boots up fine.  The kernel also starts if I use KVM acceleration on a Linux host system.
+Steps to reproduce:
+1. Build a Linux kernel for big endian arm64
+2. Try to boot it with -accel hvf on an M1 Mac
+3. Observe a lot of nothing happening  :-)
+Additional information:
+Sample run, TCG vs HVF
+```
+mikan:/tmp% qemu-system-aarch64 -accel tcg -machine virt,highmem=off -cpu cortex-a72 -nographic -kernel /tmp/vmlinuz-5.10.76-gentoo-r1-arm64.be |& head -16
+[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
+[    0.000000] Linux version 5.10.76-gentoo-r1-arm64 (root@localhost) (aarch64-unknown-linux-gnu-gcc (Gentoo 11.2.0 p1) 11.2.0, GNU ld (Gentoo 2.37_p1 p0) 2.37) #1 SMP Sun Nov 21 16:30:21 -00 2021
+[    0.000000] Machine model: linux,dummy-virt
+[    0.000000] NUMA: No NUMA configuration found
+[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x0000000047ffffff]
+[    0.000000] NUMA: NODE_DATA [mem 0x47f65300-0x47f76fff]
+[    0.000000] Zone ranges:
+[    0.000000]   DMA      [mem 0x0000000040000000-0x0000000047ffffff]
+[    0.000000]   DMA32    empty
+[    0.000000]   Normal   empty
+[    0.000000] Movable zone start for each node
+[    0.000000] Early memory node ranges
+[    0.000000]   node   0: [mem 0x0000000040000000-0x0000000047ffffff]
+[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x0000000047ffffff]
+[    0.000000] psci: probing for conduit method from DT.
+[    0.000000] psci: PSCIv0.2 detected in firmware.
+mikan:/tmp% qemu-system-aarch64 -accel hvf -machine virt,highmem=off -cpu cortex-a72 -nographic -kernel /tmp/vmlinuz-5.10.76-gentoo-r1-arm64.be       
+```
+(followed by tumbleweeds)
diff --git a/results/classifier/118/kernel/839790 b/results/classifier/118/kernel/839790
new file mode 100644
index 000000000..24a6f7243
--- /dev/null
+++ b/results/classifier/118/kernel/839790
@@ -0,0 +1,68 @@
+kernel: 0.888
+peripherals: 0.857
+user-level: 0.809
+device: 0.750
+architecture: 0.645
+performance: 0.569
+PID: 0.563
+semantic: 0.421
+register: 0.363
+graphic: 0.321
+ppc: 0.281
+KVM: 0.271
+mistranslation: 0.185
+debug: 0.171
+socket: 0.151
+permissions: 0.144
+files: 0.132
+vnc: 0.128
+x86: 0.114
+boot: 0.096
+virtual: 0.080
+network: 0.065
+VMM: 0.060
+hypervisor: 0.050
+assembly: 0.037
+risc-v: 0.035
+TCG: 0.030
+arm: 0.024
+i386: 0.023
+
+-usbdevice tablet broken on win XP client
+
+I'm using the qemu-kvm package from arch (not the qemu package), and on prior versions of qemu-kvm I was able to use -usbdevide tablet without problems.  The absolute mouse position is great...  With current version of qemu-kvm, when I use -usbdevice tablet, I got no mouse at all.  As my client is windows XP, it's not good to try do anything without mouse, :-)
+
+I searched in current bugs, and didn't find any bug which subject included "tablet", so I'm submitting this bug...
+
+Current qemu-kvm package in arch I'm using is:
+
+% pacman -Ss qemu-kvm
+extra/qemu-kvm 0.15.0-2 [installed]
+    Latest KVM QEMU is a generic and open source processor emulator which achieves a good emulation speed by using dynamic translation.
+
+Please notice I do not get any error, just the mouse broken...
+
+thanks,
+
+Javier.
+
+Forgot to mention, I'm using linux  3.0.4, but the problem also is present on all 3.0.* kernels:
+
+% pacman -Ss linux | 'grep' core
+...
+core/linux 3.0.4-1 (base) [installed]
+
+And the kvm module used is the intel one:
+
+% lsmod | 'grep' kvm
+kvm_intel              53373  3 
+kvm                   328912  1 kvm_intel
+
+If more information is needed, please let me know...
+
+Also observed on Fedora 16: https://bugzilla.redhat.com/show_bug.cgi?id=754149
+
+Can you reproduce this problem with the latest version of QEMU from http://qemu-project.org/Download ?
+
+According to the Fedora bug, this has been fixed. And since there wasn't any reply to the question in my last comment, I assume nobody experiences this issue anymore. So closing this ticket now...
+
diff --git a/results/classifier/118/kernel/876 b/results/classifier/118/kernel/876
new file mode 100644
index 000000000..b335cb905
--- /dev/null
+++ b/results/classifier/118/kernel/876
@@ -0,0 +1,64 @@
+kernel: 0.964
+TCG: 0.935
+architecture: 0.904
+arm: 0.901
+semantic: 0.884
+PID: 0.857
+ppc: 0.857
+graphic: 0.841
+device: 0.838
+files: 0.836
+performance: 0.829
+peripherals: 0.824
+socket: 0.791
+register: 0.772
+permissions: 0.765
+user-level: 0.734
+vnc: 0.730
+boot: 0.708
+debug: 0.667
+risc-v: 0.646
+network: 0.535
+VMM: 0.489
+hypervisor: 0.398
+mistranslation: 0.392
+x86: 0.210
+KVM: 0.209
+assembly: 0.197
+virtual: 0.166
+i386: 0.128
+
+snek-arm fails on s390x with qemu >6.1
+Description of problem:
+snek is a language inspired by python for embedded. The tests run snek code natively (in this case on s390x) as well as in python3 as well as emulated for arm.
+The latter is what fails...
+
+the Ubuntu testing has spotted this in:
+
+- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220211_065108_2144a@/log.gz
+- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220212_050524_3b7ee@/log.gz
+- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220214_080226_46968@/log.gz
+
+In there all work, but one test fails reproducible, that is `test/pass-slice.py`
+
+When eliminating the automation in makefiles and all that it comes down to:
+```
+$ qemu-system-arm -chardev stdio,mux=on,id=stdio0 -serial none -monitor none -semihosting-config enable=on,chardev=stdio0,arg='snek',arg=test/pass-slice.py -machine mps2-an385,accel=tcg -cpu cortex-m3 -kernel /usr/share/snek/snek-qemu-arm-1.7.elf -nographic -bios none
+fail: [::-5] (model 'o' impl '')
+```
+
+To be clear:
+- the test for python3 works on all platforms
+- the test for snek-native works on all platforms
+- the test for snek-arm work on all platforms except s390x
+- with qemu 6.0 this worked, but the more recent qemu 6.2 makes it fail
+- only some subtests of pass-slice.py fail (see below)
+
+I've gone into some details for the snek side of things in [the bug report there](https://github.com/keith-packard/snek/issues/58).
+Steps to reproduce:
+1. get an s390x system
+2. get the snek elf file for arm
+3. run qemu-system-arm as shown above
+
+P.S. I tried this on latest head (building qemu in an F35 container) and it fails there as well, hence I'm listing commit 2d88a3a595 as affected as well.
+We know 6.0 was ok, so likely 6.0->6.1 brought the issue, I have not yet checked if a bisect is feasible for this.
diff --git a/results/classifier/118/kernel/923 b/results/classifier/118/kernel/923
new file mode 100644
index 000000000..386620c9d
--- /dev/null
+++ b/results/classifier/118/kernel/923
@@ -0,0 +1,31 @@
+kernel: 0.994
+performance: 0.650
+register: 0.599
+device: 0.468
+graphic: 0.465
+mistranslation: 0.330
+debug: 0.277
+network: 0.204
+architecture: 0.173
+boot: 0.144
+semantic: 0.087
+permissions: 0.085
+i386: 0.061
+arm: 0.040
+virtual: 0.037
+KVM: 0.031
+ppc: 0.024
+hypervisor: 0.024
+x86: 0.020
+peripherals: 0.014
+assembly: 0.008
+vnc: 0.006
+risc-v: 0.006
+files: 0.005
+PID: 0.004
+socket: 0.003
+VMM: 0.002
+user-level: 0.002
+TCG: 0.002
+
+Kernel OOPS on SBSA-ref due to missing watchdog register
diff --git a/results/classifier/118/kernel/973 b/results/classifier/118/kernel/973
new file mode 100644
index 000000000..d932e5228
--- /dev/null
+++ b/results/classifier/118/kernel/973
@@ -0,0 +1,49 @@
+kernel: 0.881
+boot: 0.822
+x86: 0.818
+device: 0.798
+VMM: 0.741
+architecture: 0.739
+graphic: 0.675
+virtual: 0.668
+semantic: 0.642
+network: 0.567
+PID: 0.559
+permissions: 0.472
+vnc: 0.419
+performance: 0.401
+ppc: 0.398
+i386: 0.370
+register: 0.346
+arm: 0.325
+debug: 0.319
+risc-v: 0.298
+files: 0.260
+TCG: 0.255
+socket: 0.240
+hypervisor: 0.217
+mistranslation: 0.202
+peripherals: 0.160
+user-level: 0.150
+KVM: 0.128
+assembly: 0.060
+
+qemu 6.2 memory leak when failed to boot and infinitely reboot
+Description of problem:
+qemu allocates tons of memory (very likely memory leak) in certain (rare) cases.
+
+When I misconfigured qemu so that I have run a bigger linux kernel within insufficient memory (for example 8M bzImage while 16M ram and no hdd), the kernel will obviously fail to boot. In this case qemu will reboot (likely the linux kernel reboots). However reboot does not solve the problem, causing qemu to repeatedly reboot.
+
+Memory usage of qemu raises sharply in the progress.
+Steps to reproduce:
+1. Get any linux kernel (tested with 5.15.33)
+2. Run the kernel on qemu, with memory smaller than necessary
+Additional information:
+A reproducing dockerfile:
+```
+FROM alpine:3.15
+
+RUN apk add qemu-system-x86_64 linux-virt
+
+CMD ["/usr/bin/qemu-system-x86_64", "-kernel", "/boot/vmlinuz-virt", "-nographic", "-net", "none", "-m", "16M"]
+```
author	Christian Krinitsin <mail@krinitsin.com>	2025-06-16 16:59:00 +0000
committer	Christian Krinitsin <mail@krinitsin.com>	2025-06-16 16:59:33 +0000
commit	9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch)
tree	b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/kernel
parent	b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download	qemu-analysis-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz qemu-analysis-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip