10 files changed, 827 insertions, 0 deletions
diff --git a/results/classifier/118/architecture-ppc/1097 b/results/classifier/118/architecture-ppc/1097
new file mode 100644
index 000000000..2a636464f
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/1097
@@ -0,0 +1,61 @@
+ppc: 0.972
+architecture: 0.969
+user-level: 0.811
+device: 0.742
+debug: 0.564
+graphic: 0.544
+performance: 0.414
+mistranslation: 0.354
+semantic: 0.284
+permissions: 0.252
+network: 0.250
+peripherals: 0.247
+boot: 0.210
+PID: 0.166
+kernel: 0.162
+files: 0.134
+register: 0.129
+risc-v: 0.127
+TCG: 0.094
+arm: 0.086
+virtual: 0.083
+VMM: 0.080
+vnc: 0.075
+assembly: 0.026
+socket: 0.022
+i386: 0.017
+KVM: 0.014
+hypervisor: 0.010
+x86: 0.005
+--------------------
+ppc: 0.997
+user-level: 0.837
+kernel: 0.051
+files: 0.046
+i386: 0.027
+virtual: 0.022
+device: 0.019
+debug: 0.018
+x86: 0.017
+TCG: 0.012
+VMM: 0.010
+register: 0.008
+semantic: 0.007
+boot: 0.007
+PID: 0.005
+architecture: 0.003
+socket: 0.003
+network: 0.002
+KVM: 0.002
+peripherals: 0.001
+performance: 0.001
+graphic: 0.001
+risc-v: 0.001
+assembly: 0.001
+hypervisor: 0.001
+vnc: 0.001
+mistranslation: 0.000
+permissions: 0.000
+arm: 0.000
+
+linux-user build broken on 32-bit ppc
diff --git a/results/classifier/118/architecture-ppc/1283519 b/results/classifier/118/architecture-ppc/1283519
new file mode 100644
index 000000000..005765f11
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/1283519
@@ -0,0 +1,75 @@
+ppc: 0.978
+architecture: 0.922
+device: 0.844
+graphic: 0.800
+performance: 0.728
+network: 0.626
+mistranslation: 0.585
+files: 0.571
+peripherals: 0.555
+user-level: 0.503
+arm: 0.498
+risc-v: 0.483
+semantic: 0.478
+kernel: 0.476
+socket: 0.448
+boot: 0.419
+debug: 0.405
+vnc: 0.387
+VMM: 0.347
+PID: 0.253
+TCG: 0.239
+permissions: 0.205
+KVM: 0.186
+virtual: 0.156
+register: 0.140
+i386: 0.111
+hypervisor: 0.107
+assembly: 0.065
+x86: 0.011
+--------------------
+ppc: 0.999
+debug: 0.673
+user-level: 0.663
+TCG: 0.130
+files: 0.055
+architecture: 0.042
+virtual: 0.039
+assembly: 0.032
+hypervisor: 0.032
+register: 0.032
+kernel: 0.027
+performance: 0.023
+network: 0.020
+PID: 0.015
+semantic: 0.012
+peripherals: 0.010
+device: 0.006
+VMM: 0.004
+socket: 0.002
+graphic: 0.001
+permissions: 0.001
+boot: 0.001
+vnc: 0.001
+KVM: 0.001
+risc-v: 0.001
+mistranslation: 0.001
+arm: 0.000
+x86: 0.000
+i386: 0.000
+
+PowerPC altivec rounding instructions vrfi(m|n|z)not correctly mapped
+
+When using ppc-linux-user/qemu-ppc on a ppc ELF executable, I see that QEMU wrongly recognizes the vrfim, vrfin and vrfiz instructions:
+
+If the binary contains vrfim QEMU sees vrfiz
+If the binary contains vrfin QEMU sees vrfim
+If the binary contains vrfiz QEMU sees vrfin
+The vrfip instruction is correctly recognized.
+
+Those instructions normally round a floating-point altivec vector to zero (z), infinity (p), minus infinity (m) or nearest (n).
+
+This problem should have been fixed by the following commit:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=abe60a439b760c749201
+... so closing this ticket now.
+
diff --git a/results/classifier/118/architecture-ppc/1547 b/results/classifier/118/architecture-ppc/1547
new file mode 100644
index 000000000..6d5e3b2d8
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/1547
@@ -0,0 +1,72 @@
+architecture: 0.951
+ppc: 0.882
+device: 0.832
+graphic: 0.827
+performance: 0.816
+files: 0.810
+vnc: 0.692
+socket: 0.672
+network: 0.653
+register: 0.613
+semantic: 0.607
+permissions: 0.602
+TCG: 0.599
+x86: 0.570
+PID: 0.561
+debug: 0.459
+risc-v: 0.400
+arm: 0.382
+boot: 0.353
+kernel: 0.325
+user-level: 0.279
+VMM: 0.259
+virtual: 0.246
+mistranslation: 0.245
+i386: 0.238
+peripherals: 0.046
+assembly: 0.035
+hypervisor: 0.025
+KVM: 0.003
+--------------------
+ppc: 0.905
+debug: 0.604
+files: 0.175
+hypervisor: 0.144
+virtual: 0.080
+TCG: 0.078
+kernel: 0.014
+register: 0.012
+network: 0.011
+user-level: 0.010
+PID: 0.008
+performance: 0.007
+semantic: 0.006
+architecture: 0.004
+device: 0.003
+socket: 0.003
+assembly: 0.002
+peripherals: 0.001
+graphic: 0.001
+boot: 0.001
+permissions: 0.001
+VMM: 0.000
+vnc: 0.000
+x86: 0.000
+KVM: 0.000
+risc-v: 0.000
+mistranslation: 0.000
+i386: 0.000
+arm: 0.000
+
+POWER9 emulation is broken when compiler optimizations are on (for gcc 11.3 and later)
+Description of problem:
+Comparing two floating point memory operands produces incorrect result
+Steps to reproduce:
+1. Unpack attached archive and change to test_p64 directory
+2. Build the source file with: powerpc64le-linux-gnu-g++ -O2 -static test.cpp -o test_p64
+3. Run with QEMU: qemu-ppc64le -cpu POWER9 test_p64 > output.txt
+4. Check the output text file output.txt (with pluma or any other text editor) to see the printouts
+Additional information:
+The pre-built binary and its output file are attached as test_p64.tar.gz[test_p64.tar.gz](/uploads/0e9dbc22e6841496efc15775e6aa624a/test_p64.tar.gz)
+
+The purpose of this report is to motivate the creation of a point release QEMU 6.2.1 for Ubuntu 22.04 LTS (which will be supported for years to come). Also cross-linking similar bug report for MIPS with exact same goal: https://gitlab.com/qemu-project/qemu/-/issues/1531
diff --git a/results/classifier/118/architecture-ppc/1595 b/results/classifier/118/architecture-ppc/1595
new file mode 100644
index 000000000..58a5523b1
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/1595
@@ -0,0 +1,89 @@
+architecture: 0.965
+boot: 0.910
+performance: 0.902
+kernel: 0.883
+graphic: 0.880
+ppc: 0.834
+device: 0.822
+KVM: 0.796
+arm: 0.763
+semantic: 0.659
+vnc: 0.585
+socket: 0.584
+hypervisor: 0.536
+x86: 0.529
+PID: 0.528
+register: 0.526
+user-level: 0.434
+permissions: 0.433
+risc-v: 0.420
+network: 0.399
+debug: 0.381
+files: 0.370
+TCG: 0.367
+VMM: 0.354
+virtual: 0.346
+mistranslation: 0.337
+assembly: 0.316
+peripherals: 0.253
+i386: 0.173
+--------------------
+boot: 0.972
+arm: 0.970
+TCG: 0.940
+debug: 0.925
+KVM: 0.912
+kernel: 0.884
+PID: 0.880
+virtual: 0.856
+VMM: 0.750
+vnc: 0.714
+risc-v: 0.641
+device: 0.634
+socket: 0.528
+hypervisor: 0.516
+files: 0.294
+register: 0.238
+semantic: 0.150
+architecture: 0.033
+assembly: 0.013
+performance: 0.011
+permissions: 0.009
+user-level: 0.007
+network: 0.002
+graphic: 0.001
+peripherals: 0.001
+mistranslation: 0.001
+x86: 0.000
+i386: 0.000
+ppc: 0.000
+
+CPU boot sometimes fails on big.LITTLE CPUs with varying cache sizes
+Description of problem:
+The RK3588 SoC has three core clusters; one with A55 cores, and the other two have A76 cores. The big cores have more L2 cache than the little cores, so the value of `CCSIDR` depends on the core that it is read from.
+
+In `write_list_to_kvmstate`, QEMU attempts to use `KVM_SET_ONE_REG` with an ID for `KVM_REG_ARM_DEMUX_ID_CCSIDR`, trying to set `CCSIDR` to a previously read value.
+
+Normally, that works fine, but if the host kernel has moved QEMU from one core cluster to the other, then the value will be different and `demux_c15_set` will return `EINVAL`, causing the entire `arm_set_cpu_on` to fail, and the guest kernel to print an error.
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/sys_regs.c?h=v6.2#n2827
+
+I tried changing the condition for the `ok = false` line in `write_list_to_kvmstate` to `ret && r.id >> 8 != 0x60200000001100`. This causes all CPUs to initialize correctly in the guest, but obviously that's a hack.
+
+I assume that `CCSIDR` not being uniform across all CPUs means that the guest's copy of `CCSIDR` may be wrong, and so cache maintenance operations may not act on the entire cache. I do not know whether that could actually cause problems. Will QEMU need to find the maximum cache size across all CPUs and present that to guests?
+Steps to reproduce:
+On a SoC where big and little cores have different cache sizes (e.g. RK3588):
+
+```text
+$ qemu-system-aarch64 -M virt -accel kvm -cpu host -smp 4 -nographic -kernel arch/arm64/boot/Image -append quiet
+[    0.001399][    T1] psci: failed to boot CPU1 (-22)
+[    0.001407][    T1] CPU1: failed to boot: -22
+[    0.001685][    T1] psci: failed to boot CPU2 (-22)
+[    0.001691][    T1] CPU2: failed to boot: -22
+[    0.001809][    T1] psci: failed to boot CPU3 (-22)
+[    0.001814][    T1] CPU3: failed to boot: -22
+```
+
+The error is not always printed, because it depends on which core cluster the processes are scheduled on.
+
+Using `taskset -c 0-3` or `taskset -c 4-7` to force QEMU to stick to the little or big cores respectively makes the bug not reproduce.
diff --git a/results/classifier/118/architecture-ppc/1779 b/results/classifier/118/architecture-ppc/1779
new file mode 100644
index 000000000..e94a8cf17
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/1779
@@ -0,0 +1,90 @@
+architecture: 0.922
+ppc: 0.848
+graphic: 0.844
+device: 0.803
+performance: 0.747
+mistranslation: 0.701
+semantic: 0.647
+vnc: 0.578
+PID: 0.575
+permissions: 0.423
+peripherals: 0.414
+arm: 0.411
+boot: 0.365
+debug: 0.348
+user-level: 0.310
+risc-v: 0.306
+TCG: 0.305
+kernel: 0.272
+hypervisor: 0.247
+x86: 0.226
+VMM: 0.226
+network: 0.172
+i386: 0.171
+register: 0.171
+virtual: 0.150
+socket: 0.138
+files: 0.101
+assembly: 0.044
+KVM: 0.019
+--------------------
+ppc: 0.997
+performance: 0.797
+architecture: 0.441
+kernel: 0.251
+debug: 0.219
+TCG: 0.170
+files: 0.102
+device: 0.025
+user-level: 0.025
+semantic: 0.020
+peripherals: 0.020
+assembly: 0.014
+PID: 0.013
+register: 0.012
+virtual: 0.007
+risc-v: 0.005
+VMM: 0.004
+hypervisor: 0.004
+network: 0.003
+boot: 0.003
+permissions: 0.003
+graphic: 0.002
+KVM: 0.001
+mistranslation: 0.001
+vnc: 0.001
+socket: 0.001
+arm: 0.001
+x86: 0.000
+i386: 0.000
+
+PowerPC AltiVec source vector subnormal values are not flushed to zero
+Description of problem:
+AltiVec specifies that source and result vectors are flushed to zero (in NJ mode).  Only result vectors are flushed to zero.
+Steps to reproduce:
+1. Compile the attached Rust program (e.g. `cargo +nightly build --target powerpc-unknown-linux-gnu`)
+2. Run the program and expect assertions to pass.
+3. See assertions fail.
+Additional information:
+See the offending Rust program:
+
+```
+#![feature(stdsimd, powerpc_target_feature)]
+
+use std::arch::powerpc::*;
+
+#[target_feature(enable = "altivec")]
+unsafe fn add(x: f32, y: f32) -> f32 {
+    let array: [f32; 4] = unsafe { std::mem::transmute(vec_add(vec_splats(x), vec_splats(y))) };
+    array[0]
+}
+
+pub fn main() {
+    let result = unsafe { add(-1.0857398e-38, 0.) };
+    assert_eq!(result, 0.);
+
+    // if the input is flushed, the result will be +0
+    // if only the output is flushed, the result is -0
+    assert!(result.is_sign_positive());
+}
+```
diff --git a/results/classifier/118/architecture-ppc/1780 b/results/classifier/118/architecture-ppc/1780
new file mode 100644
index 000000000..1bf35fd5c
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/1780
@@ -0,0 +1,77 @@
+ppc: 0.979
+graphic: 0.882
+architecture: 0.816
+device: 0.724
+network: 0.589
+semantic: 0.561
+vnc: 0.436
+debug: 0.427
+peripherals: 0.418
+boot: 0.398
+performance: 0.395
+PID: 0.393
+socket: 0.311
+kernel: 0.246
+permissions: 0.230
+arm: 0.225
+x86: 0.192
+TCG: 0.182
+register: 0.176
+risc-v: 0.175
+assembly: 0.172
+hypervisor: 0.161
+user-level: 0.141
+mistranslation: 0.130
+i386: 0.114
+virtual: 0.101
+files: 0.097
+VMM: 0.082
+KVM: 0.040
+--------------------
+ppc: 0.999
+performance: 0.590
+assembly: 0.481
+TCG: 0.296
+debug: 0.263
+architecture: 0.084
+files: 0.083
+register: 0.068
+semantic: 0.055
+kernel: 0.032
+user-level: 0.020
+peripherals: 0.014
+PID: 0.012
+device: 0.005
+virtual: 0.003
+boot: 0.003
+mistranslation: 0.003
+graphic: 0.002
+hypervisor: 0.002
+network: 0.001
+VMM: 0.001
+permissions: 0.001
+socket: 0.001
+risc-v: 0.001
+vnc: 0.001
+arm: 0.000
+KVM: 0.000
+x86: 0.000
+i386: 0.000
+
+PowerPC mishandles xscmpudp instruction
+Description of problem:
+xscmpudp instruction is mishandled
+Steps to reproduce:
+1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`)
+2. Run the program and expect assertions to pass.
+3. See assertions fail.
+Additional information:
+When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly).  See the offending program:
+```
+pub fn main() {
+    use std::hint::black_box;
+    assert!(black_box(f64::NAN)
+        .clamp(black_box(0f64), black_box(0f64))
+        .is_nan());
+}
+```
diff --git a/results/classifier/118/architecture-ppc/1818075 b/results/classifier/118/architecture-ppc/1818075
new file mode 100644
index 000000000..f3edd75e4
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/1818075
@@ -0,0 +1,180 @@
+architecture: 0.920
+graphic: 0.906
+debug: 0.898
+assembly: 0.878
+TCG: 0.875
+user-level: 0.870
+permissions: 0.866
+register: 0.862
+virtual: 0.861
+performance: 0.860
+peripherals: 0.857
+ppc: 0.855
+x86: 0.852
+device: 0.848
+arm: 0.841
+risc-v: 0.841
+hypervisor: 0.839
+KVM: 0.820
+files: 0.816
+vnc: 0.809
+network: 0.800
+kernel: 0.800
+semantic: 0.791
+PID: 0.787
+socket: 0.778
+mistranslation: 0.773
+VMM: 0.758
+i386: 0.667
+boot: 0.655
+--------------------
+x86: 0.997
+TCG: 0.944
+assembly: 0.751
+debug: 0.717
+virtual: 0.376
+register: 0.279
+user-level: 0.256
+architecture: 0.111
+hypervisor: 0.082
+performance: 0.070
+files: 0.039
+PID: 0.022
+semantic: 0.019
+VMM: 0.011
+device: 0.008
+kernel: 0.007
+KVM: 0.005
+socket: 0.003
+permissions: 0.002
+risc-v: 0.002
+i386: 0.002
+graphic: 0.002
+network: 0.002
+boot: 0.001
+vnc: 0.001
+peripherals: 0.001
+ppc: 0.000
+mistranslation: 0.000
+arm: 0.000
+
+qemu x86 TCG doesn't support AVX insns
+
+I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU.
+
+Adding input tracing shows that it is likely hanging when dealing with an AVX instruction:
+
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29]
+warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11]
+warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18]
+warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8]
+warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1]
+
+IN:
+0x4000b4ef3b:  c5 fb 5c ca              vsubsd   %xmm2, %xmm0, %xmm1
+0x4000b4ef3f:  c4 e1 fb 2c d1           vcvttsd2si %xmm1, %rdx
+0x4000b4ef44:  4c 31 e2                 xorq     %r12, %rdx
+0x4000b4ef47:  48 85 d2                 testq    %rdx, %rdx
+0x4000b4ef4a:  79 9e                    jns      0x4000b4eeea
+
+[ hangs ]
+
+Attaching a gdb produces this stacktrace:
+
+(gdb) bt
+#0  canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 <float64_params>, part=...)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350
+#1  float64_unpack_canonical (s=0x55a20ff67a88, f=0)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547
+#2  float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776
+#3  0x000055a20baa1949 in helper_subsd (env=<optimized out>, d=0x55a20ff67ad8, s=<optimized out>)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623
+#4  0x000055a20cfcfea8 in static_code_gen_buffer ()
+#5  0x000055a20ba3f764 in cpu_tb_exec (itb=<optimized out>, cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171
+#6  cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>,
+    cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615
+#7  cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725
+#8  0x000055a20ba6d728 in cpu_loop (env=0x55a20ff67780)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93
+#9  0x000055a20ba049ff in main (argc=<optimized out>, argv=0x7ffc58572868, envp=<optimized out>)
+    at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819
+
+<pm215>	my guess is we're doing something unhelpful with the AVX insn, and so the guest code which is checking the result and using it as its loop condition for the jns is just looping forever
+
+<rburton> in_asm log just stopped with this as the last line
+<rburton> 0x4000b4ef4a:  79 9e                    jns      0x4000b4eeea
+
+
+Further debugging on IRC reveals that QEMU itself is not hanging, but the guest code is looping infinitely, because QEMU doesn't implement the AVX instruction set and isn't generating an undefined-instruction exception either. So the %rdx output from the AVX insn is wrong and the guest code never exits the loop (whose condition depends on %rdx).
+
+We should ideally:
+ * make the x86 decoder properly handle insns that don't exist for the CPU being emulated (not too difficult, but doesn't actually help in running this test program)
+ * implement AVX (a fair chunk of effort; it is being proposed as a GSoC project for this summer)
+
+
+If I may be so free:
+
+It seems that QEMU has stopped emphasizing the EMU part of the name, and is too much focused on virtualization.
+
+My interest is at running legacy operating systems, and as such, they must run on foreign CPU platforms. m68 on intel, intel on ARM, etc.
+Time doesn't stand still, and reliance on KVM and similar x86-on-x86 tricks, which allow the delegation of certain CPU features to the host CPU is going to not work going forward.
+
+If the rumored transition of Apple to ARM is going to take place, people will want to e.g. emulate for testing or legacy purposes a variety of operating systems, incl. earlier versions of MacOS.
+
+Testing that scenario, i.e. macOS on an ARM board with the lowest possible CPU capable of running modern macOS, results in these problems (and of course utter failure achieving the goal):
+
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8]
+qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1]
+
+And this is emulating a lowly Penryn CPU with the required CPU flags for macOS:
+-cpu Penryn,vendor=GenuineIntel,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc
+
+Attempting to emulate a more feature laden intel CPU results in even more issues.
+
+I would propose that no CPU should be considered supported unless it can be fully handled by TCG on a non-native host. KVM, native-on-native etc. are nice to have, but peripheral to qEMUlation when it boils down to it.
+
+We do care about emulation; but as always with open source software projects, the parts that get more care and attention are the parts that people are either paid to work on or are personally interested in. x86 guest emulation in particular is not very well maintained (though it is better than some targets), because mostly people are happy to use x86 hardware, and adding support for emulation of large new architectural features like AVX is a lot of work. If you would like to help improve x86 guest emulation, you are welcome to submit patches to fix bugs or add new features. Merely saying "X should be better and you should somehow magically find three months worth of developer time to make it so" doesn't really do anything to move the situation forwards.
+
+
+QEMU, like most open source projects, relies on contributors who have motivation, skills and available time to work on implementing particular features. They naturally tend to focus on features that result in the greatest benefit to their own use cases. Thus simply declaring that an open source project, must support something won't magically make it happen.
+
+IOW, the lack of coverage of newer x86 instructions is largely a reflection of the relative priorities of the current pool of contributors and where/what they feel are the best places/features to spend their time on.
+
+If any person does want to work on improving x86 TCG though, the project would happily receive patches, and existing contributors can offer guidance & advice along the way to help get to a successful outcome.
+
+
+Of course it’s open source, I get that. When I say „xyz should be done“ then in the sense of „2+2 should be 4“ not in the sense of „you must implement xyz right now“ ;)
+
+Nonetheless, if you run e.g. on an ARM platform the command 
+
+qemu-system-x86_64 -cpu help
+
+then it shouldn’t list a slew of CPUs as „available“ that clearly aren’t working.
+
+It should then list fully implemented CPUs separately from partially implemented CPUs (if listing them at all), and if it does list incomplete implementations, it should indicate what’s missing.
+It’s just a horrible user experience, if based on such output, one spends significant time trying to get some emulation running, only to then discover from runtime error messages, that an „available“ CPU isn’t actually available.
+
+
+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/164
+
+
diff --git a/results/classifier/118/architecture-ppc/390 b/results/classifier/118/architecture-ppc/390
new file mode 100644
index 000000000..e0aa9e891
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/390
@@ -0,0 +1,61 @@
+ppc: 0.948
+permissions: 0.918
+architecture: 0.822
+assembly: 0.706
+PID: 0.528
+device: 0.526
+performance: 0.395
+graphic: 0.370
+semantic: 0.361
+arm: 0.354
+x86: 0.346
+debug: 0.323
+peripherals: 0.322
+boot: 0.196
+i386: 0.178
+VMM: 0.178
+KVM: 0.175
+mistranslation: 0.162
+TCG: 0.155
+register: 0.140
+vnc: 0.116
+risc-v: 0.111
+virtual: 0.093
+hypervisor: 0.064
+network: 0.058
+user-level: 0.057
+files: 0.056
+kernel: 0.051
+socket: 0.029
+--------------------
+ppc: 0.995
+assembly: 0.928
+TCG: 0.069
+kernel: 0.056
+architecture: 0.047
+debug: 0.039
+peripherals: 0.038
+permissions: 0.036
+register: 0.031
+performance: 0.017
+virtual: 0.010
+VMM: 0.010
+PID: 0.009
+semantic: 0.005
+device: 0.003
+KVM: 0.003
+risc-v: 0.003
+files: 0.003
+boot: 0.002
+hypervisor: 0.001
+graphic: 0.001
+user-level: 0.001
+x86: 0.001
+mistranslation: 0.000
+vnc: 0.000
+network: 0.000
+arm: 0.000
+socket: 0.000
+i386: 0.000
+
+target/ppc: atomic path of Load Quadword instruction require address with write permission
diff --git a/results/classifier/118/architecture-ppc/859 b/results/classifier/118/architecture-ppc/859
new file mode 100644
index 000000000..082233488
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/859
@@ -0,0 +1,61 @@
+architecture: 0.948
+ppc: 0.907
+device: 0.896
+virtual: 0.896
+graphic: 0.441
+semantic: 0.418
+performance: 0.392
+permissions: 0.388
+mistranslation: 0.336
+arm: 0.333
+boot: 0.330
+VMM: 0.299
+TCG: 0.295
+i386: 0.282
+network: 0.230
+hypervisor: 0.221
+PID: 0.217
+vnc: 0.184
+files: 0.175
+user-level: 0.172
+risc-v: 0.160
+register: 0.122
+peripherals: 0.109
+socket: 0.082
+assembly: 0.051
+debug: 0.050
+KVM: 0.032
+kernel: 0.032
+x86: 0.002
+--------------------
+ppc: 0.992
+virtual: 0.850
+architecture: 0.196
+VMM: 0.065
+assembly: 0.049
+device: 0.032
+semantic: 0.025
+hypervisor: 0.022
+files: 0.021
+debug: 0.017
+peripherals: 0.012
+KVM: 0.010
+TCG: 0.010
+register: 0.009
+kernel: 0.008
+PID: 0.007
+performance: 0.007
+vnc: 0.007
+risc-v: 0.007
+user-level: 0.005
+boot: 0.004
+socket: 0.004
+graphic: 0.001
+permissions: 0.001
+mistranslation: 0.001
+network: 0.001
+i386: 0.001
+x86: 0.000
+arm: 0.000
+
+PowerPC's Virtual Open Firmware uses an unsupported instruction in older CPUs
diff --git a/results/classifier/118/architecture-ppc/86 b/results/classifier/118/architecture-ppc/86
new file mode 100644
index 000000000..81f079097
--- /dev/null
+++ b/results/classifier/118/architecture-ppc/86
@@ -0,0 +1,61 @@
+ppc: 0.978
+device: 0.915
+architecture: 0.867
+performance: 0.634
+mistranslation: 0.511
+graphic: 0.494
+network: 0.479
+arm: 0.448
+debug: 0.420
+permissions: 0.417
+boot: 0.364
+files: 0.335
+user-level: 0.299
+risc-v: 0.263
+kernel: 0.261
+peripherals: 0.244
+semantic: 0.217
+register: 0.215
+VMM: 0.199
+socket: 0.186
+vnc: 0.156
+assembly: 0.152
+x86: 0.139
+PID: 0.135
+hypervisor: 0.128
+TCG: 0.114
+virtual: 0.111
+KVM: 0.042
+i386: 0.017
+--------------------
+ppc: 0.997
+boot: 0.904
+x86: 0.790
+device: 0.519
+debug: 0.120
+assembly: 0.048
+kernel: 0.035
+virtual: 0.031
+user-level: 0.026
+hypervisor: 0.022
+register: 0.014
+files: 0.011
+peripherals: 0.008
+VMM: 0.008
+semantic: 0.006
+architecture: 0.006
+performance: 0.006
+KVM: 0.005
+socket: 0.004
+TCG: 0.003
+graphic: 0.003
+PID: 0.002
+arm: 0.001
+risc-v: 0.001
+mistranslation: 0.001
+vnc: 0.001
+network: 0.000
+i386: 0.000
+permissions: 0.000
+
+powerpc 7450 MMU initialization broken