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/architecture-arm
parent: b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download: emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz
emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip
50 files changed, 3924 insertions, 0 deletions
diff --git a/results/classifier/118/architecture-arm/1062 b/results/classifier/118/architecture-arm/1062
new file mode 100644
index 00000000..76cfd385
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1062
@@ -0,0 +1,76 @@
+architecture: 0.982
+arm: 0.934
+graphic: 0.906
+assembly: 0.851
+device: 0.826
+peripherals: 0.808
+mistranslation: 0.798
+performance: 0.728
+socket: 0.727
+risc-v: 0.676
+register: 0.659
+network: 0.651
+semantic: 0.646
+permissions: 0.635
+ppc: 0.625
+vnc: 0.606
+PID: 0.559
+kernel: 0.537
+files: 0.517
+TCG: 0.488
+boot: 0.478
+debug: 0.476
+i386: 0.414
+VMM: 0.260
+hypervisor: 0.218
+virtual: 0.206
+x86: 0.196
+user-level: 0.178
+KVM: 0.082
+--------------------
+assembly: 0.982
+arm: 0.955
+architecture: 0.818
+register: 0.384
+semantic: 0.071
+files: 0.045
+TCG: 0.043
+debug: 0.037
+kernel: 0.022
+VMM: 0.017
+device: 0.016
+boot: 0.008
+socket: 0.006
+PID: 0.005
+virtual: 0.005
+peripherals: 0.003
+hypervisor: 0.002
+user-level: 0.002
+performance: 0.002
+risc-v: 0.002
+KVM: 0.001
+vnc: 0.001
+network: 0.001
+permissions: 0.001
+graphic: 0.001
+mistranslation: 0.001
+ppc: 0.000
+x86: 0.000
+i386: 0.000
+
+AArch64: SCR_EL3.RW behaves incorrectly for CPUs with no AArch32
+Description of problem:
+In the ARM DDI 0487G.a, D13-3572, the SCR_EL3.RW bit is defined as RAO/WI if both EL2 and EL1 don't support Aarch32. However, the function `scr_write` in `target/arm/helper.c` does not reflect this behavior, even though it checks for Aarch32 EL1 support.
+
+This would break this EL3 code, which should run on cpu reset to attempt to return to EL1:
+```asm
+mov x1, #((1<<0)|(1<<2)|(1<<6)|(1<<7)|(1<<8)|(1<<9)) ; EL1h, DAIF masked
+mov SPSR_EL3, x1
+adr x1, 1f
+msr ELR_EL3, x1
+eret
+1:
+; something something
+```
+Additional information:
+
diff --git a/results/classifier/118/architecture-arm/1079080 b/results/classifier/118/architecture-arm/1079080
new file mode 100644
index 00000000..c07790e0
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1079080
@@ -0,0 +1,90 @@
+architecture: 0.969
+arm: 0.935
+kernel: 0.912
+graphic: 0.903
+device: 0.901
+register: 0.853
+semantic: 0.833
+performance: 0.815
+peripherals: 0.798
+network: 0.755
+permissions: 0.709
+socket: 0.707
+files: 0.660
+vnc: 0.648
+boot: 0.648
+VMM: 0.642
+mistranslation: 0.619
+virtual: 0.612
+ppc: 0.585
+risc-v: 0.539
+PID: 0.516
+user-level: 0.494
+debug: 0.485
+x86: 0.432
+hypervisor: 0.397
+TCG: 0.397
+i386: 0.302
+assembly: 0.187
+KVM: 0.100
+--------------------
+arm: 0.997
+architecture: 0.868
+kernel: 0.428
+debug: 0.108
+virtual: 0.067
+TCG: 0.035
+assembly: 0.032
+VMM: 0.026
+user-level: 0.022
+register: 0.019
+files: 0.016
+network: 0.015
+device: 0.009
+semantic: 0.008
+hypervisor: 0.008
+PID: 0.008
+socket: 0.006
+risc-v: 0.005
+peripherals: 0.003
+vnc: 0.003
+performance: 0.002
+permissions: 0.001
+boot: 0.001
+graphic: 0.001
+mistranslation: 0.000
+KVM: 0.000
+ppc: 0.000
+i386: 0.000
+x86: 0.000
+
+ARM instruction "srs" wrong behaviour
+
+Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R :
+"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode"
+
+Problem:
+When executing this instruction, the register stored is CPSR instead of SPSR.
+
+Context:
+Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line:
+qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic
+
+It looks like this is only a problem in Thumb mode; the equivalent bug in ARM mode was fixed in commit c67b6b71 back in 2009.
+
+Can you make the test case dtb and image available? That would help in testing...
+
+
+
+
+
+
+Thanks -- I've submitted a patch which fixes this: http://patchwork.ozlabs.org/patch/220748/
+
+If you'd like to give me a name/email [format "Full Name <email address hidden>"] I can credit you in a Reported-by: tag in the commit message...
+
+
+You are welcome. 
+Credit info you need: Cesson Vincent <email address hidden>
+Thank you for fixing it!
+
diff --git a/results/classifier/118/architecture-arm/1167 b/results/classifier/118/architecture-arm/1167
new file mode 100644
index 00000000..d3cc3b0e
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1167
@@ -0,0 +1,61 @@
+arm: 0.874
+architecture: 0.843
+hypervisor: 0.703
+device: 0.637
+graphic: 0.416
+semantic: 0.238
+register: 0.233
+mistranslation: 0.229
+performance: 0.216
+VMM: 0.196
+boot: 0.152
+virtual: 0.147
+PID: 0.144
+assembly: 0.143
+debug: 0.127
+user-level: 0.109
+socket: 0.104
+vnc: 0.085
+permissions: 0.079
+risc-v: 0.069
+network: 0.063
+TCG: 0.055
+ppc: 0.054
+kernel: 0.033
+peripherals: 0.026
+x86: 0.021
+files: 0.015
+i386: 0.010
+KVM: 0.004
+--------------------
+virtual: 0.959
+hypervisor: 0.951
+arm: 0.895
+semantic: 0.155
+TCG: 0.146
+user-level: 0.102
+architecture: 0.060
+VMM: 0.032
+register: 0.029
+files: 0.024
+KVM: 0.017
+device: 0.012
+boot: 0.011
+kernel: 0.010
+debug: 0.007
+socket: 0.005
+assembly: 0.005
+risc-v: 0.002
+graphic: 0.002
+vnc: 0.001
+peripherals: 0.001
+PID: 0.001
+permissions: 0.001
+performance: 0.001
+network: 0.001
+ppc: 0.001
+mistranslation: 0.000
+x86: 0.000
+i386: 0.000
+
+Does qemu-system-aarch64 support hyper-v elightenment feature for windows for arm guest?
diff --git a/results/classifier/118/architecture-arm/1245 b/results/classifier/118/architecture-arm/1245
new file mode 100644
index 00000000..1c540f2b
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1245
@@ -0,0 +1,61 @@
+arm: 0.983
+architecture: 0.884
+performance: 0.649
+device: 0.530
+peripherals: 0.376
+graphic: 0.341
+mistranslation: 0.309
+permissions: 0.297
+assembly: 0.237
+hypervisor: 0.219
+files: 0.196
+semantic: 0.186
+debug: 0.185
+network: 0.182
+ppc: 0.179
+vnc: 0.179
+VMM: 0.176
+virtual: 0.170
+user-level: 0.152
+register: 0.141
+risc-v: 0.111
+PID: 0.109
+KVM: 0.069
+TCG: 0.067
+kernel: 0.062
+x86: 0.054
+boot: 0.047
+socket: 0.028
+i386: 0.021
+--------------------
+arm: 0.997
+device: 0.845
+peripherals: 0.620
+assembly: 0.069
+register: 0.060
+virtual: 0.053
+semantic: 0.049
+files: 0.035
+user-level: 0.022
+performance: 0.012
+graphic: 0.010
+architecture: 0.006
+debug: 0.005
+PID: 0.004
+kernel: 0.004
+boot: 0.003
+socket: 0.003
+VMM: 0.003
+TCG: 0.002
+KVM: 0.002
+permissions: 0.002
+mistranslation: 0.001
+hypervisor: 0.001
+vnc: 0.001
+risc-v: 0.001
+ppc: 0.000
+network: 0.000
+i386: 0.000
+x86: 0.000
+
+arm: cp15 support
diff --git a/results/classifier/118/architecture-arm/1308381 b/results/classifier/118/architecture-arm/1308381
new file mode 100644
index 00000000..97f7fe68
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1308381
@@ -0,0 +1,146 @@
+architecture: 0.880
+arm: 0.838
+peripherals: 0.831
+performance: 0.825
+assembly: 0.817
+hypervisor: 0.807
+graphic: 0.807
+register: 0.800
+device: 0.793
+debug: 0.789
+PID: 0.786
+ppc: 0.786
+risc-v: 0.781
+files: 0.768
+vnc: 0.762
+kernel: 0.751
+permissions: 0.749
+boot: 0.749
+VMM: 0.747
+mistranslation: 0.744
+socket: 0.709
+virtual: 0.706
+user-level: 0.706
+network: 0.693
+x86: 0.629
+KVM: 0.628
+TCG: 0.616
+i386: 0.521
+semantic: 0.520
+--------------------
+arm: 0.935
+architecture: 0.445
+assembly: 0.402
+debug: 0.311
+TCG: 0.056
+register: 0.037
+files: 0.035
+semantic: 0.020
+risc-v: 0.020
+kernel: 0.018
+PID: 0.014
+device: 0.013
+hypervisor: 0.010
+user-level: 0.008
+boot: 0.008
+VMM: 0.006
+network: 0.005
+virtual: 0.005
+performance: 0.005
+vnc: 0.004
+peripherals: 0.004
+socket: 0.004
+graphic: 0.002
+mistranslation: 0.002
+permissions: 0.001
+KVM: 0.000
+x86: 0.000
+i386: 0.000
+ppc: 0.000
+
+illegal instructions for AArch64 ARMv8
+
+The test case is in the attachment. To reproduce as following (I tried both GCC and Clang):
+$aarch64-linux-gnu-gcc qemu.c -o test
+$./test
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction (core dumped)
+
+There are 3 intrinsics are tested in the test case: vqmovunh_s16,  vqmovuns_s32, vqmovund_s64. They will be compiled into instructions:
+SQXTUN Bd, Hn
+SQXTUN Hd, Sn
+SQXTUN Sd, Dn.
+
+It seems that these instructions are not supported in QEMU. Is this a bug?
+
+
+
+Can you attach a statically linked test case binary, please?
+
+
+
+Peter Maydell <email address hidden> writes:
+
+> Can you attach a statically linked test case binary, please?
+
+I can reproduce with the source file. It looks like:
+
+@@ -7553,12 +7555,9 @@ static void disas_simd_scalar_two_reg_misc(DisasContext *s, uint32_t insn)
+         }
+         break;
+     case 0x12: /* SQXTUN */
+-        if (u) {
+-            unallocated_encoding(s);
+-            return;
+-        }
+         /* fall through */
+
+Fixes it. Let me check why this slipped through the risu tests and
+re-validate. I'll submit a patch once I've double checked.
+
+-- 
+Alex Bennée
+
+
+
+On 16 April 2014 11:55, Alex Bennée <email address hidden> wrote:
+>
+> Peter Maydell <email address hidden> writes:
+>
+>> Can you attach a statically linked test case binary, please?
+>
+> I can reproduce with the source file. It looks like:
+>
+> @@ -7553,12 +7555,9 @@ static void disas_simd_scalar_two_reg_misc(DisasContext *s, uint32_t insn)
+>          }
+>          break;
+>      case 0x12: /* SQXTUN */
+> -        if (u) {
+> -            unallocated_encoding(s);
+> -            return;
+> -        }
+>          /* fall through */
+>
+> Fixes it.
+
+However the ARM ARM, unless I'm misreading it, requires scalar-2-misc
+SQXTUN to have U==1, so the correct fix should be to turn that "if (u)"
+into "if (!u)" I think. (Opcode 0x12 u==0 isn't in the table so should undef.)
+
+Better check we didn't make the same mistake in the vector-2-misc
+decode as well.
+
+thanks
+-- PMM
+
+
+Fix identified
+
+I've sent this patch to the mailing list but it fixes the attached test case and has been tested with risu patterns.
+
+@pmaydell: yeah vector is unaffected as U is used to select another opcode.
+
+Patch had been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e44a90c59697cf98
+==> Fix released
+
diff --git a/results/classifier/118/architecture-arm/1318281 b/results/classifier/118/architecture-arm/1318281
new file mode 100644
index 00000000..b07686c1
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1318281
@@ -0,0 +1,98 @@
+architecture: 0.946
+arm: 0.886
+user-level: 0.853
+graphic: 0.798
+performance: 0.779
+device: 0.693
+mistranslation: 0.677
+semantic: 0.676
+i386: 0.592
+x86: 0.587
+files: 0.466
+ppc: 0.400
+register: 0.383
+peripherals: 0.374
+permissions: 0.362
+debug: 0.351
+risc-v: 0.326
+PID: 0.321
+network: 0.316
+vnc: 0.315
+boot: 0.285
+kernel: 0.257
+socket: 0.252
+virtual: 0.232
+TCG: 0.202
+VMM: 0.200
+hypervisor: 0.189
+assembly: 0.182
+KVM: 0.077
+--------------------
+arm: 0.983
+debug: 0.956
+x86: 0.923
+virtual: 0.158
+files: 0.144
+kernel: 0.064
+PID: 0.044
+TCG: 0.041
+user-level: 0.037
+performance: 0.030
+hypervisor: 0.030
+architecture: 0.015
+register: 0.011
+semantic: 0.010
+device: 0.005
+boot: 0.004
+network: 0.003
+assembly: 0.002
+graphic: 0.002
+ppc: 0.002
+peripherals: 0.002
+i386: 0.002
+VMM: 0.002
+socket: 0.001
+permissions: 0.001
+risc-v: 0.001
+KVM: 0.001
+vnc: 0.001
+mistranslation: 0.000
+
+linux-user: x86_64 target fails to call sys_futex()
+
+I'm building the latest QEMU (06b4f00d53637f2c16a62c2cbaa30bffb045cf88) on ARM to run some x86_64 executables in user mode. This is my configuration:
+
+./configure \
+  --prefix=/root/qemu-x86_64 \
+  --target-list=x86_64-linux-user \
+  --disable-system \
+  --disable-tools
+
+The following program is used for testing:
+
+https://gist.github.com/hujiajie/e8cff43b574b399c8f59#file-test-c
+
+I compile the test program in Debian-7.5-amd64 like this:
+
+gcc -o test `pkg-config --cflags glib-2.0` test.c `pkg-config --static --libs glib-2.0` -static
+
+and launch the program on ARM with
+
+qemu-x86_64 test
+
+The test crashes with the following message:
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+The output of `strace qemu-x86_64 test` is here:
+
+https://gist.github.com/hujiajie/88d1d5e580d432d11b2d#file-test-strace-log
+
+It seems that the error is caused by the failure of the futex syscall.
+
+qemu-i386 could launch the 32-bit test perfectly, the problem only happens on a x86_64 target.
+
+The test program works fine with current git master, so I think we have fixed this bug at some point in the last two years.
+
+
diff --git a/results/classifier/118/architecture-arm/1324724 b/results/classifier/118/architecture-arm/1324724
new file mode 100644
index 00000000..79651f45
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1324724
@@ -0,0 +1,101 @@
+architecture: 0.915
+arm: 0.871
+x86: 0.852
+semantic: 0.778
+graphic: 0.765
+device: 0.732
+peripherals: 0.732
+user-level: 0.717
+mistranslation: 0.687
+performance: 0.683
+kernel: 0.665
+files: 0.661
+permissions: 0.650
+network: 0.609
+PID: 0.579
+VMM: 0.563
+i386: 0.541
+ppc: 0.537
+boot: 0.529
+hypervisor: 0.506
+risc-v: 0.472
+virtual: 0.466
+socket: 0.449
+debug: 0.443
+register: 0.442
+assembly: 0.389
+vnc: 0.360
+TCG: 0.330
+KVM: 0.315
+--------------------
+arm: 0.983
+TCG: 0.164
+virtual: 0.109
+hypervisor: 0.084
+architecture: 0.054
+debug: 0.029
+register: 0.017
+PID: 0.014
+device: 0.013
+files: 0.013
+user-level: 0.012
+VMM: 0.007
+semantic: 0.006
+socket: 0.002
+kernel: 0.002
+vnc: 0.002
+network: 0.001
+graphic: 0.001
+peripherals: 0.001
+performance: 0.001
+assembly: 0.001
+boot: 0.001
+x86: 0.001
+KVM: 0.000
+permissions: 0.000
+mistranslation: 0.000
+i386: 0.000
+risc-v: 0.000
+ppc: 0.000
+
+make install fails if running strip
+
+I do:
+   ./configure --target-list=arm-softmmu
+   make
+  sudo make install
+
+and see:
+install -d -m 0755 "/usr/local/bin"
+libtool --quiet --mode=install install -c -m 0755 qemu-ga qemu-nbd qemu-img qemu-io  fsdev/virtfs-proxy-helper "/usr/local/bin"
+strip "/usr/local/bin/qemu-ga" "/usr/local/bin/qemu-nbd" "/usr/local/bin/qemu-img" "/usr/local/bin/qemu-io" "/usr/local/bin/fsdev/virtfs-proxy-helper"
+strip: '/usr/local/bin/fsdev/virtfs-proxy-helper': No such file
+Makefile:379: recipe for target 'install' failed
+make: *** [install] Error 1
+
+
+Host is Odroid-XU running Debian Jessie.
+Source is at d7d3d6092cb7edc75dc49fb90c86dd5425ab4805 Merge remote-tracking branch 'remotes/afaerber/tags/qom-devices-for-peter'
+ 
+libtool version 2.4.2-1.7 armhf
+
+
+
+Not sure this is really ARM related, is it? It looks like it will happen any time we do a make install and we're using strip and we've built something in some subdir like fsdev.
+
+> ** Patch added: "Probably wrong fix."
+>    https://bugs.launchpad.net/bugs/1324724/+attachment/4122442/+files/fix.patch
+
+Looks fairly reasonable to me. I think I'd do both places the same way you did the libexec case, though (without the extra make variable).
+
+
+The libexec case doesn't actually work, which is why IO switched to a separate variable.  One of the reasons I said the patch is probably wrong.
+
+I suspect we need something like
+$(STRIP) $(addprefix $(DESTDIR)/$(BINDIR), $(notdir ${TOOLS)))
+
+And I didn't see the problem on x86_64, only on armhf. I think x86_64 doesn't need the fsdev helper.
+
+This was fixed by commit 0d6594261 back in 2014.
+
+
diff --git a/results/classifier/118/architecture-arm/1498 b/results/classifier/118/architecture-arm/1498
new file mode 100644
index 00000000..30ddd894
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1498
@@ -0,0 +1,65 @@
+arm: 0.986
+graphic: 0.914
+architecture: 0.861
+device: 0.849
+semantic: 0.841
+mistranslation: 0.800
+performance: 0.660
+network: 0.564
+debug: 0.543
+permissions: 0.425
+files: 0.393
+boot: 0.371
+vnc: 0.362
+register: 0.290
+ppc: 0.264
+PID: 0.226
+risc-v: 0.219
+VMM: 0.194
+peripherals: 0.190
+TCG: 0.183
+virtual: 0.173
+socket: 0.166
+assembly: 0.098
+kernel: 0.067
+i386: 0.064
+hypervisor: 0.063
+KVM: 0.027
+x86: 0.012
+user-level: 0.006
+--------------------
+arm: 0.999
+virtual: 0.783
+hypervisor: 0.675
+debug: 0.139
+files: 0.034
+performance: 0.025
+assembly: 0.024
+TCG: 0.021
+semantic: 0.020
+kernel: 0.019
+register: 0.018
+device: 0.013
+socket: 0.009
+peripherals: 0.008
+VMM: 0.007
+PID: 0.006
+architecture: 0.006
+boot: 0.006
+risc-v: 0.004
+vnc: 0.004
+network: 0.004
+user-level: 0.004
+permissions: 0.004
+ppc: 0.003
+graphic: 0.002
+mistranslation: 0.001
+KVM: 0.000
+x86: 0.000
+i386: 0.000
+
+LDC, STC unimplemented in qemu-system-arm
+Description of problem:
+I used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in LDC, SDC instruction was detected.
+
+The instructions run successfully in raspi2b, but cause undefined in QEMU. I found that LDC and SDC instructions remain unimplemented in QEMU.
diff --git a/results/classifier/118/architecture-arm/1514 b/results/classifier/118/architecture-arm/1514
new file mode 100644
index 00000000..9255b004
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1514
@@ -0,0 +1,61 @@
+architecture: 0.969
+arm: 0.951
+ppc: 0.831
+graphic: 0.679
+device: 0.607
+performance: 0.516
+semantic: 0.263
+mistranslation: 0.257
+risc-v: 0.181
+permissions: 0.145
+virtual: 0.134
+debug: 0.126
+user-level: 0.071
+boot: 0.071
+peripherals: 0.053
+i386: 0.029
+assembly: 0.026
+vnc: 0.025
+register: 0.017
+network: 0.012
+TCG: 0.008
+socket: 0.004
+x86: 0.004
+hypervisor: 0.003
+VMM: 0.002
+files: 0.001
+PID: 0.001
+kernel: 0.001
+KVM: 0.001
+--------------------
+arm: 0.964
+assembly: 0.420
+performance: 0.314
+architecture: 0.193
+debug: 0.048
+user-level: 0.031
+virtual: 0.029
+device: 0.026
+kernel: 0.023
+semantic: 0.016
+PID: 0.013
+files: 0.009
+boot: 0.006
+peripherals: 0.005
+permissions: 0.005
+KVM: 0.004
+VMM: 0.004
+TCG: 0.003
+register: 0.003
+graphic: 0.002
+risc-v: 0.002
+mistranslation: 0.002
+hypervisor: 0.001
+socket: 0.001
+ppc: 0.000
+vnc: 0.000
+network: 0.000
+x86: 0.000
+i386: 0.000
+
+Cpu flags for ARM is surprising
diff --git a/results/classifier/118/architecture-arm/1608 b/results/classifier/118/architecture-arm/1608
new file mode 100644
index 00000000..ffd4ba42
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1608
@@ -0,0 +1,61 @@
+architecture: 0.948
+mistranslation: 0.916
+arm: 0.882
+device: 0.533
+performance: 0.529
+debug: 0.502
+graphic: 0.483
+ppc: 0.354
+risc-v: 0.345
+boot: 0.328
+vnc: 0.291
+i386: 0.286
+x86: 0.224
+semantic: 0.212
+socket: 0.193
+TCG: 0.182
+VMM: 0.157
+kernel: 0.151
+register: 0.143
+KVM: 0.129
+network: 0.114
+permissions: 0.107
+virtual: 0.094
+user-level: 0.051
+PID: 0.051
+peripherals: 0.021
+hypervisor: 0.009
+files: 0.008
+assembly: 0.008
+--------------------
+arm: 0.992
+virtual: 0.898
+hypervisor: 0.863
+user-level: 0.560
+register: 0.557
+architecture: 0.357
+performance: 0.036
+debug: 0.029
+device: 0.018
+semantic: 0.017
+assembly: 0.012
+files: 0.011
+kernel: 0.010
+peripherals: 0.006
+mistranslation: 0.004
+socket: 0.003
+boot: 0.003
+graphic: 0.003
+VMM: 0.003
+risc-v: 0.002
+PID: 0.002
+TCG: 0.001
+KVM: 0.001
+ppc: 0.000
+network: 0.000
+permissions: 0.000
+vnc: 0.000
+i386: 0.000
+x86: 0.000
+
+QEMU gives wrong MPIDR value for Arm CPU types with MT=1
diff --git a/results/classifier/118/architecture-arm/1619 b/results/classifier/118/architecture-arm/1619
new file mode 100644
index 00000000..8e4f2e34
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1619
@@ -0,0 +1,61 @@
+architecture: 0.991
+arm: 0.905
+device: 0.845
+performance: 0.632
+semantic: 0.568
+files: 0.489
+x86: 0.488
+permissions: 0.485
+assembly: 0.461
+network: 0.436
+virtual: 0.431
+graphic: 0.423
+boot: 0.363
+register: 0.319
+peripherals: 0.274
+hypervisor: 0.216
+mistranslation: 0.216
+user-level: 0.203
+kernel: 0.142
+TCG: 0.128
+socket: 0.112
+PID: 0.094
+VMM: 0.080
+debug: 0.079
+risc-v: 0.065
+vnc: 0.063
+ppc: 0.057
+i386: 0.007
+KVM: 0.007
+--------------------
+arm: 0.948
+virtual: 0.904
+architecture: 0.604
+x86: 0.144
+VMM: 0.125
+KVM: 0.124
+device: 0.039
+user-level: 0.026
+files: 0.018
+hypervisor: 0.012
+assembly: 0.010
+kernel: 0.008
+semantic: 0.007
+TCG: 0.005
+boot: 0.004
+peripherals: 0.003
+graphic: 0.002
+debug: 0.002
+performance: 0.002
+PID: 0.001
+register: 0.001
+socket: 0.001
+ppc: 0.001
+vnc: 0.001
+risc-v: 0.000
+permissions: 0.000
+mistranslation: 0.000
+network: 0.000
+i386: 0.000
+
+Emulate x86_64 on ARM machine
diff --git a/results/classifier/118/architecture-arm/1679358 b/results/classifier/118/architecture-arm/1679358
new file mode 100644
index 00000000..865c4152
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1679358
@@ -0,0 +1,115 @@
+arm: 0.953
+architecture: 0.951
+peripherals: 0.914
+register: 0.853
+debug: 0.842
+permissions: 0.817
+assembly: 0.806
+performance: 0.747
+boot: 0.676
+graphic: 0.675
+device: 0.657
+semantic: 0.642
+user-level: 0.622
+files: 0.616
+kernel: 0.613
+mistranslation: 0.562
+risc-v: 0.557
+hypervisor: 0.546
+x86: 0.543
+socket: 0.475
+network: 0.471
+PID: 0.460
+vnc: 0.424
+ppc: 0.412
+KVM: 0.398
+i386: 0.391
+VMM: 0.324
+virtual: 0.311
+TCG: 0.297
+--------------------
+arm: 0.978
+debug: 0.900
+architecture: 0.200
+hypervisor: 0.054
+files: 0.045
+virtual: 0.044
+user-level: 0.041
+boot: 0.034
+semantic: 0.030
+VMM: 0.020
+TCG: 0.017
+device: 0.012
+PID: 0.012
+kernel: 0.011
+register: 0.010
+network: 0.009
+socket: 0.006
+vnc: 0.005
+performance: 0.004
+risc-v: 0.004
+assembly: 0.004
+permissions: 0.004
+peripherals: 0.002
+graphic: 0.002
+ppc: 0.001
+mistranslation: 0.001
+KVM: 0.000
+x86: 0.000
+i386: 0.000
+
+ARM: RES0/RES1 SCTLR fields not read-only
+
+There are fields in SCTLR that are RAO/SBOP or WI or in the case of the RR field, accessible only in secure mode. Currently it seems that qemu just propagates any write to SCTLR to the register and this screwed up in a bootloader that I am debugging.
+
+On 3 April 2017 at 23:17, Yifan <email address hidden> wrote:
+> There are fields in SCTLR that are RAO/SBOP or WI or in the case of the
+> RR field, accessible only in secure mode. Currently it seems that qemu
+> just propagates any write to SCTLR to the register and this screwed up
+> in a bootloader that I am debugging.
+
+Yes, we're a bit loose in QEMU on the handling of reserved bits.
+
+Note that most of the SCTLR bits like this are RAO/SBOP or RAZ/SBZP,
+so the guest should not be writing wrong values to them.
+
+thanks
+-- PMM
+
+
+So there won't be a fix in the future? I'm working with debugging a proprietary bootloader that I do not have the source code for. I wonder if this becomes an issue for any other platform targets.  
+
+Well, I wouldn't object to a patch to fix it (it would have to correctly handle the various different versions of the CPU architecture we implement, etc), but I'm not planning on writing one today myself.
+
+
+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/architecture-arm/1740887 b/results/classifier/118/architecture-arm/1740887
new file mode 100644
index 00000000..e99ee3cd
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1740887
@@ -0,0 +1,91 @@
+arm: 0.933
+architecture: 0.891
+user-level: 0.860
+graphic: 0.826
+ppc: 0.814
+boot: 0.805
+vnc: 0.797
+mistranslation: 0.783
+semantic: 0.782
+register: 0.780
+PID: 0.743
+performance: 0.739
+permissions: 0.735
+debug: 0.728
+device: 0.722
+files: 0.717
+socket: 0.669
+network: 0.658
+assembly: 0.584
+risc-v: 0.583
+VMM: 0.574
+peripherals: 0.560
+hypervisor: 0.560
+kernel: 0.553
+TCG: 0.549
+virtual: 0.545
+KVM: 0.410
+i386: 0.398
+x86: 0.368
+--------------------
+arm: 0.907
+hypervisor: 0.496
+user-level: 0.487
+virtual: 0.245
+debug: 0.069
+boot: 0.053
+files: 0.028
+TCG: 0.013
+PID: 0.013
+device: 0.012
+network: 0.009
+semantic: 0.007
+performance: 0.006
+socket: 0.004
+risc-v: 0.004
+VMM: 0.003
+register: 0.003
+vnc: 0.003
+assembly: 0.002
+architecture: 0.002
+kernel: 0.002
+ppc: 0.001
+permissions: 0.001
+peripherals: 0.001
+graphic: 0.001
+mistranslation: 0.001
+x86: 0.001
+i386: 0.001
+KVM: 0.000
+
+qemu-system-arm & qemu-system-aarch64 for windows crash at start
+
+In Windows 7 64 bit (both 32 & 64 bit QEMU emulator version 2.11.0 (v2.11.0-11693-g21057c841e-dirty)).
+
+With arguments:
+
+qemu-system-arm.exe -M raspi2
+
+It crashes and reports:
+
+ERROR:/home/stefan/src/qemu/repo.or.cz/qemu/ar7/qom/object.c:176:type_get_parent: assertion failed: (type->parent_type != NULL)
+
+Same goes for qemu-system-aarch64.exe or with -M raspi argument.
+
+Have a nice day,
+f.
+
+I've got th exact same crash under Windows 10 64 bits with QEMU emulator version 2.10.95 (v2.11.0-rc5-11692-g50cdacc703-dirty)
+
+Any idea how to fix it or is there a previous known working version for "-M raspi" option?
+
+Thanks.
+Raphaël.
+
+I had to switch back to the following installer "2016-03-03: New QEMU installers. Fixed, first version with support for Raspberry Pi 1 and 2." for having a working version with the "-M raspi" option.
+
+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/architecture-arm/1756538 b/results/classifier/118/architecture-arm/1756538
new file mode 100644
index 00000000..0b8e243e
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1756538
@@ -0,0 +1,85 @@
+architecture: 0.954
+performance: 0.888
+boot: 0.871
+graphic: 0.855
+user-level: 0.851
+device: 0.841
+semantic: 0.827
+arm: 0.822
+hypervisor: 0.773
+virtual: 0.771
+KVM: 0.737
+PID: 0.658
+mistranslation: 0.655
+permissions: 0.639
+register: 0.631
+kernel: 0.563
+peripherals: 0.553
+debug: 0.544
+VMM: 0.541
+files: 0.539
+ppc: 0.533
+risc-v: 0.512
+network: 0.473
+TCG: 0.467
+assembly: 0.461
+vnc: 0.447
+socket: 0.421
+i386: 0.325
+x86: 0.255
+--------------------
+arm: 0.932
+virtual: 0.922
+user-level: 0.719
+hypervisor: 0.198
+debug: 0.030
+files: 0.013
+semantic: 0.013
+TCG: 0.009
+socket: 0.007
+device: 0.007
+risc-v: 0.007
+boot: 0.007
+register: 0.006
+PID: 0.005
+network: 0.005
+KVM: 0.002
+vnc: 0.002
+x86: 0.002
+kernel: 0.002
+architecture: 0.002
+performance: 0.002
+VMM: 0.002
+graphic: 0.001
+permissions: 0.001
+assembly: 0.001
+ppc: 0.001
+peripherals: 0.001
+i386: 0.001
+mistranslation: 0.000
+
+Minimal Ubuntu vs. Debian differences
+
+I'm using Qemu on Ubuntu (minimal) and Debian (minimal) on Android (Arch64) via Linux Deploy to run Windows guests. Here's a few issues I encountered:
+
+1) Qemu on (minimal) Debian 9 and Ubuntu cannot run Windows 7-10 guests (only Windows XP and below) because there's a black screen after the boot menu. Qemu on Debian 10, however, can run Windows 7. Incidentally, these distros run on the host in bios compatibility mode instead of UEFI. Ubuntu Desktop (full distro) on other hosts does not display the black screen when running Qemu.
+
+2) Qemu on Debian 9-10 (minimal) does not display fullscreen - but Ubuntu minimal does display full-screen.
+
+3) Qemu on Limbo PC Emulator and on Debian 9-10 only run windows guests at 1 GHz using the default Qemu CPU, but Ubuntu runs windows guests at 2 GHz using the default Qemu CPU.
+
+4) Enable KVM doesn't work, and virtualization isn't detected through Limbo PC Emulator and minimal Linux distros running on Android - perhaps is a problem with running Linux distros via Linux Deploy using Chroot on Android (not so much a Qemu-KVM issue) and failing to detect ARMv8-A CPUs that are indeed capable of virtualization.
+
+Can anyone explain these differences? I believe they are all using the latest versions of Qemu.
+
+One more: Qemu on Debian 9-10 minimal requires -show cursor command to use the mouse inside a windows guest, but with Qemu on Ubuntu minimal the cursor is controllable by default. Again, this is all within the context of an Android/Arm8/Linux minimal/Chroot-based host. 
+
+Qemu Virtual CPU is capping at 1 GHz for version 2.5+ and 2 GHz for version 2.4
+
+I tested qemu32 and qemu64. This is strange because my ARMv8-a CPU is 2.4 GHz. 
+
+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/architecture-arm/1761401 b/results/classifier/118/architecture-arm/1761401
new file mode 100644
index 00000000..f57b5afe
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1761401
@@ -0,0 +1,79 @@
+architecture: 0.890
+graphic: 0.881
+vnc: 0.879
+arm: 0.807
+performance: 0.678
+device: 0.639
+risc-v: 0.632
+semantic: 0.611
+socket: 0.441
+VMM: 0.436
+boot: 0.416
+TCG: 0.413
+PID: 0.407
+ppc: 0.398
+permissions: 0.392
+network: 0.348
+virtual: 0.335
+files: 0.310
+mistranslation: 0.274
+debug: 0.256
+user-level: 0.241
+x86: 0.177
+i386: 0.155
+register: 0.117
+kernel: 0.111
+peripherals: 0.097
+assembly: 0.094
+KVM: 0.077
+hypervisor: 0.045
+--------------------
+arm: 0.999
+user-level: 0.840
+debug: 0.124
+virtual: 0.056
+TCG: 0.043
+performance: 0.030
+files: 0.028
+register: 0.022
+network: 0.019
+kernel: 0.011
+VMM: 0.007
+hypervisor: 0.007
+device: 0.006
+peripherals: 0.006
+PID: 0.006
+socket: 0.005
+semantic: 0.004
+vnc: 0.003
+assembly: 0.003
+architecture: 0.003
+permissions: 0.002
+graphic: 0.002
+boot: 0.001
+risc-v: 0.001
+mistranslation: 0.000
+ppc: 0.000
+KVM: 0.000
+x86: 0.000
+i386: 0.000
+
+ARM/Neon: vcvt rounding error
+
+Hello,
+
+While using QEMU commit 47d3b60858d90ac8a0cc3a72af7f95c96781125a (March 28, 2018), I've noticed failures in one of the GCC ARM/Neon tests. The test passes on hardware, and with QEMU-2.11.0, so it looks like a recent regression.
+
+The test builds a vector of 4 float32 with "125.9" as value, then converts them to 4 uint32_t.
+The expected result is 125, but we get 126 instead.
+
+Maybe it's just a matter of default rounding mode?
+
+Hi Christophe -- we think that commit bd49e6027cbc207c, now in master, should have fixed this bug. Could you retry your testcase with a QEMU build including that fix?
+
+
+I updated my QEMU git tree such that it includes commit bd49e6027cbc207c, and the test now passes.
+
+Thanks for the prompt fix!
+
+
diff --git a/results/classifier/118/architecture-arm/1772 b/results/classifier/118/architecture-arm/1772
new file mode 100644
index 00000000..d7947a67
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1772
@@ -0,0 +1,72 @@
+architecture: 0.917
+kernel: 0.916
+device: 0.891
+arm: 0.859
+performance: 0.837
+mistranslation: 0.812
+ppc: 0.807
+graphic: 0.765
+files: 0.736
+permissions: 0.725
+peripherals: 0.714
+vnc: 0.704
+socket: 0.652
+x86: 0.642
+semantic: 0.640
+network: 0.638
+PID: 0.633
+register: 0.585
+debug: 0.585
+risc-v: 0.537
+i386: 0.514
+TCG: 0.478
+assembly: 0.450
+user-level: 0.413
+VMM: 0.395
+boot: 0.393
+hypervisor: 0.357
+virtual: 0.210
+KVM: 0.139
+--------------------
+arm: 0.998
+virtual: 0.478
+kernel: 0.469
+device: 0.328
+TCG: 0.235
+debug: 0.165
+architecture: 0.057
+hypervisor: 0.049
+files: 0.031
+PID: 0.026
+register: 0.023
+performance: 0.013
+peripherals: 0.008
+semantic: 0.007
+user-level: 0.007
+assembly: 0.007
+socket: 0.004
+VMM: 0.003
+boot: 0.003
+risc-v: 0.003
+network: 0.003
+ppc: 0.002
+graphic: 0.002
+vnc: 0.002
+permissions: 0.002
+KVM: 0.002
+x86: 0.001
+i386: 0.001
+mistranslation: 0.000
+
+MPS2 AN521 has the wrong number of MPU region defined
+Description of problem:
+The AN521 is integrating SSE-200 on the MPS2+ FPGA prototyping board.
+The current implementation in qemu behaves as though there are 16MPU regions when it really only has 8, as describes as `MPU_NS` and `MPU_S` core configuration parameters in the SSE-200's [Techincal Reference Manual](https://developer.arm.com/documentation/101104/0200/functional-description/cpu-elements/cortex-m33-configurations?lang=en).
+Steps to reproduce:
+1. Prepare your Zephyr dev environment
+2. fix `boards/arm/mps2_an521/mps2_an521.dts` to set `arm,num-mpu-regions`  to the appropriate value of 8.
+3. build a Zephyr test such as `west build -p -b mps2_an521 -T tests/kernel/interrupt/arch.interrupt` 
+4. run `qemu-system-arm -machine mps2-an521 -chardev stdio,id=con,mux=on -serial chardev:con -kernel ./build/zephyr/zephyr.elf`
+Additional information:
+With matching MPU region number in QEMU and Zephyr's DTS, the application shows the test suite's progress & outcome.
+If there's a mismatch, the application will enter a fault and not display the expected traces.
diff --git a/results/classifier/118/architecture-arm/1819 b/results/classifier/118/architecture-arm/1819
new file mode 100644
index 00000000..9a6f49f0
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1819
@@ -0,0 +1,70 @@
+architecture: 0.993
+device: 0.913
+graphic: 0.910
+arm: 0.830
+debug: 0.722
+PID: 0.689
+semantic: 0.639
+network: 0.626
+performance: 0.438
+register: 0.425
+VMM: 0.420
+permissions: 0.396
+TCG: 0.320
+mistranslation: 0.315
+vnc: 0.298
+boot: 0.285
+user-level: 0.279
+socket: 0.273
+files: 0.248
+risc-v: 0.240
+ppc: 0.238
+virtual: 0.148
+peripherals: 0.147
+hypervisor: 0.106
+assembly: 0.101
+kernel: 0.048
+KVM: 0.044
+x86: 0.036
+i386: 0.023
+--------------------
+arm: 0.947
+debug: 0.715
+virtual: 0.585
+TCG: 0.356
+kernel: 0.163
+register: 0.120
+architecture: 0.053
+socket: 0.040
+PID: 0.033
+performance: 0.030
+user-level: 0.026
+files: 0.022
+risc-v: 0.020
+network: 0.017
+VMM: 0.011
+peripherals: 0.010
+KVM: 0.008
+semantic: 0.007
+assembly: 0.007
+device: 0.007
+graphic: 0.006
+hypervisor: 0.005
+boot: 0.002
+ppc: 0.002
+permissions: 0.001
+x86: 0.001
+vnc: 0.001
+mistranslation: 0.000
+i386: 0.000
+
+segmentation fault for rpm -qa command on centos:centos7 linux/arm/v7 architecture for docker container in shell.
+Description of problem:
+
+Steps to reproduce:
+1. docker pull centos:centos7@sha256:6887440ab977f751d6675157b73e42428d8ac05cf244c5d09ba036cc22d40d13 //pull an image centos:centos7 linux/arm/v7 tag
+2. docker run -it b22fdcc90005 //docker run in interactive mode just pulled image
+3. on shell run command -\> rpm -qa.
+4. docker run -it b22fdcc90005
+
+   WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64) and no specific platform was requested \[root@e23bc92686e8 /\]# rpm -qa Segmentation fault (core dumped)
diff --git a/results/classifier/118/architecture-arm/1840922 b/results/classifier/118/architecture-arm/1840922
new file mode 100644
index 00000000..c6c8ac96
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1840922
@@ -0,0 +1,129 @@
+arm: 0.873
+architecture: 0.857
+performance: 0.692
+user-level: 0.661
+semantic: 0.642
+permissions: 0.558
+mistranslation: 0.552
+vnc: 0.521
+x86: 0.503
+graphic: 0.492
+ppc: 0.477
+device: 0.472
+network: 0.449
+register: 0.435
+kernel: 0.405
+socket: 0.377
+VMM: 0.370
+boot: 0.352
+peripherals: 0.351
+PID: 0.331
+virtual: 0.321
+i386: 0.295
+risc-v: 0.266
+assembly: 0.260
+debug: 0.242
+hypervisor: 0.241
+TCG: 0.228
+KVM: 0.161
+files: 0.159
+--------------------
+arm: 0.983
+debug: 0.810
+register: 0.087
+performance: 0.080
+architecture: 0.033
+user-level: 0.028
+hypervisor: 0.022
+assembly: 0.021
+semantic: 0.018
+TCG: 0.018
+PID: 0.016
+kernel: 0.012
+files: 0.008
+device: 0.007
+virtual: 0.006
+peripherals: 0.005
+VMM: 0.004
+network: 0.004
+graphic: 0.003
+socket: 0.003
+vnc: 0.003
+boot: 0.003
+permissions: 0.002
+risc-v: 0.001
+KVM: 0.001
+mistranslation: 0.001
+x86: 0.000
+ppc: 0.000
+i386: 0.000
+
+qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
+
+Hi,
+
+While experimenting with running the GCC testsuite with cortex-m33 as target (to exercise v8-m code), I came across this failure:
+qemu: unhandled CPU exception 0x8 - aborting
+R00=fffeaf58 R01=fffeaf58 R02=00000000 R03=fffeaf5d
+R04=fffeaf5c R05=fffeaf9c R06=00000000 R07=fffeaf80
+R08=00000000 R09=00000000 R10=00019dbc R11=00000000
+R12=000000f0 R13=fffeaf58 R14=000081f3 R15=fffeaf5c
+XPSR=61000000 -ZC- T NS priv-thread
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6033c908
+
+I'm using arm-eabi-gcc, so it targets bare-metal, not linux.
+
+The testcase is GCC's gcc/testsuite/gcc.c-torture/execute/20000822-1.c; it works when compiled at -O2, but crashes when compiled at -Os. The test uses nested functions, so it creates a trampoline on the stack, whose address may be a problem. But since the stack address seems to be in the same range in the O2 and Os cases, it's not that clear.
+
+I'm attaching the C source, asm, binary executables and qemu traces with in_asm,cpu.
+
+I execute the binaries with:
+qemu-arm --cpu cortex-m33  ./20000822-1.exe.Os
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+This happens because we're applying a loose test for the v8m magic
+exception return address.
+
+There are two possible fixes for this, and perhaps we should
+apply both of them:
+
+(1) Unset ARM_FEATURE_M_SECURITY for arm-linux-user.
+    This would disable the FNC_RETURN_MIN_MAGIC test,
+    which, unlike EXC_RETURN_MIN_MAGIC, is not protected
+    by a condition that linux-user cannot satisfy (Handler mode).
+
+(2) Limit the address space to 0x7ffffff, the normal end of
+    write-back cached ram.  Since M-profile doesn't have an MMU,
+    this would make linux-user addresses more like what we'd see
+    running the same test under system mode.
+
+The test for v8m magic return addresses is not too loose -- see the v8M pseudocode IsReturn(). Architecturally the whole range of these values is special, even though in fact the exception return address encoding currently doesn't use all the bits that are reserved in this manner.
+
+I would prefer not to unset ARM_FEATURE_M_SECURITY if we can avoid it.
+
+We should definitely not allow guest code to be loaded at weird addresses in linux-user mode, I agree.
+
+
+Just posted 
+https://<email address hidden>/
+
+which is basically RTH's hack from #8 with a big pile of commentary and commit message...
+
+Thanks Peter and Richard for the quick patch. It works for me.
+
+Fixed in master as commit 5e5584c89f36b, will be in the 4.2 release.
+
+
diff --git a/results/classifier/118/architecture-arm/1843254 b/results/classifier/118/architecture-arm/1843254
new file mode 100644
index 00000000..e8853014
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1843254
@@ -0,0 +1,73 @@
+architecture: 0.909
+arm: 0.897
+register: 0.755
+peripherals: 0.743
+device: 0.723
+mistranslation: 0.638
+network: 0.572
+socket: 0.561
+ppc: 0.555
+vnc: 0.554
+permissions: 0.548
+kernel: 0.528
+risc-v: 0.524
+files: 0.521
+TCG: 0.515
+graphic: 0.510
+performance: 0.472
+boot: 0.426
+semantic: 0.425
+PID: 0.419
+hypervisor: 0.415
+VMM: 0.403
+KVM: 0.396
+user-level: 0.389
+virtual: 0.327
+assembly: 0.323
+debug: 0.305
+i386: 0.274
+x86: 0.173
+--------------------
+arm: 0.999
+register: 0.395
+architecture: 0.171
+kernel: 0.082
+TCG: 0.032
+device: 0.029
+assembly: 0.029
+semantic: 0.028
+virtual: 0.021
+files: 0.021
+debug: 0.018
+PID: 0.015
+VMM: 0.013
+peripherals: 0.012
+hypervisor: 0.006
+vnc: 0.005
+performance: 0.005
+socket: 0.003
+user-level: 0.003
+KVM: 0.002
+network: 0.002
+boot: 0.001
+permissions: 0.001
+graphic: 0.001
+mistranslation: 0.001
+risc-v: 0.000
+i386: 0.000
+x86: 0.000
+ppc: 0.000
+
+arm emulation of HCR.TID3 traps are not implemented
+
+On ARM (aarch64), HCR_EL2.TID3 [bit18] is supposed to trap ID group 3, which includes the ID_AA64{PFR,DFR,ISAR,MMFR,AFR}*_EL1 registers. However, setting that HCR bit has no effect and accesses to those ID registers are not trapped to EL2 with an EC syndrome value of 0x18.
+
+Yes, we don't currently implement most of the 'trap system register access' bits in HCR_EL2. Last time I checked we were missing TID0 TID1 TID2 TID3 TIDCP TAC TSW TPC TPU TTLB TVM TRVM TDZ, but it's possible we've implemented one or two of those since then.
+
+
+TID3 trapping should be mostly fixed for 4.2 -- we will trap accesses to all the coprocessor/sysreg ID registers that TID3 covers. Trapping of aarch32 MVFR* (which are accessed via vmrs) will not make it into this release, but should be in 5.0.
+
+
+The last bit of TID3 trapping is now in QEMU git master and will be in 5.0.
+
+
diff --git a/results/classifier/118/architecture-arm/1855072 b/results/classifier/118/architecture-arm/1855072
new file mode 100644
index 00000000..a1f2b627
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1855072
@@ -0,0 +1,84 @@
+architecture: 0.923
+arm: 0.886
+kernel: 0.845
+user-level: 0.832
+peripherals: 0.832
+semantic: 0.760
+device: 0.746
+mistranslation: 0.728
+performance: 0.654
+network: 0.613
+hypervisor: 0.611
+assembly: 0.606
+virtual: 0.599
+debug: 0.572
+graphic: 0.549
+socket: 0.543
+VMM: 0.505
+permissions: 0.503
+x86: 0.500
+files: 0.494
+register: 0.472
+ppc: 0.455
+vnc: 0.451
+risc-v: 0.442
+boot: 0.386
+i386: 0.381
+PID: 0.362
+TCG: 0.285
+KVM: 0.237
+--------------------
+arm: 0.999
+architecture: 0.434
+hypervisor: 0.206
+TCG: 0.060
+debug: 0.039
+files: 0.032
+virtual: 0.016
+device: 0.014
+kernel: 0.013
+VMM: 0.013
+register: 0.010
+user-level: 0.010
+PID: 0.005
+assembly: 0.005
+semantic: 0.004
+network: 0.003
+boot: 0.003
+performance: 0.002
+peripherals: 0.002
+risc-v: 0.002
+vnc: 0.002
+KVM: 0.001
+graphic: 0.001
+socket: 0.001
+permissions: 0.001
+mistranslation: 0.001
+ppc: 0.000
+x86: 0.000
+i386: 0.000
+
+ARM: HCR.TVM traps are not implemented
+
+On AARCH64, setting HCR.TVM to 1 is supposed to trap all writes to CTLR_EL1, TTBR0_EL1, TTBR1_EL1, TCR_EL1, ESR_EL1, FAR_EL1, AFSR0_EL1, AFSR1_EL1, MAIR_EL1, AMAIR_EL1, and CONTEXTIDR_EL1. However, it currently has no effect (QEMU emulator version 4.1.1).
+
+It is also likely that TRVM will not trap, but, I didn't verify this.
+
+Yes to both.
+
+Patch posted:
+https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg04401.html
+
+If you could help testing, that would be appreciated.
+
+Thank you for the patch! I am happy to test this for you. I will apply the patch/compile/test and get back to you.
+
+I tested in AArch64 mode and it worked for me. Looking at the patch, we might be missing trapping for "TTBCR"in AA32 though.
+
+Oops.  Thanks for the review.  Posted v2 with ttbcr included.
+
+Thank you! I also tested AArch32 and the code works. Ship it!
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=84929218512c
+
diff --git a/results/classifier/118/architecture-arm/1859713 b/results/classifier/118/architecture-arm/1859713
new file mode 100644
index 00000000..e9269bcd
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1859713
@@ -0,0 +1,117 @@
+architecture: 0.953
+arm: 0.937
+mistranslation: 0.936
+x86: 0.915
+kernel: 0.817
+graphic: 0.786
+device: 0.777
+peripherals: 0.741
+socket: 0.702
+semantic: 0.698
+performance: 0.667
+ppc: 0.637
+permissions: 0.623
+hypervisor: 0.606
+user-level: 0.604
+assembly: 0.600
+PID: 0.596
+network: 0.552
+risc-v: 0.543
+VMM: 0.517
+i386: 0.509
+KVM: 0.504
+debug: 0.492
+register: 0.485
+boot: 0.480
+TCG: 0.474
+files: 0.440
+vnc: 0.336
+virtual: 0.126
+--------------------
+arm: 0.986
+debug: 0.501
+assembly: 0.299
+kernel: 0.104
+hypervisor: 0.076
+register: 0.062
+architecture: 0.045
+files: 0.030
+TCG: 0.025
+PID: 0.020
+virtual: 0.012
+device: 0.011
+peripherals: 0.009
+semantic: 0.004
+user-level: 0.004
+permissions: 0.004
+socket: 0.004
+performance: 0.003
+VMM: 0.003
+network: 0.002
+vnc: 0.002
+x86: 0.002
+boot: 0.002
+risc-v: 0.002
+graphic: 0.002
+KVM: 0.001
+ppc: 0.001
+mistranslation: 0.001
+i386: 0.000
+
+ARM v8.3a pauth not working
+
+Host: Ubuntu 19.10 - x86_64 machine
+QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master)
+
+ARMV8.3 pauth is not working well.
+
+With a test code containing two pauth instructions:
+    - paciasp that sign LR with A key and sp as context;
+    - autiasp that verify the signature.
+
+Test:
+    - Run the program and corrupt LR just before autiasp (ex 0x3e00000400660 instead of 0x3e000000400664)
+
+Expected:
+    - autiasp places an invalid pointer in LR
+
+Result:
+    - autiasp successfully auth the pointer and places 0x0400660 in LR.
+
+Further explanations:
+    Adding traces in qemu code shows that "pauth_computepac" is not robust enough against truncating.
+    With 0x31000000400664 as input of pauth_auth, we obtain "0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
+    With 0x310040008743ec as input of pauth (with same key), we obtain "0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
+    Values of top_bit and bottom_bit are strictly the same and it should not.
+
+Hi,
+
+Here is a patch for this bug. The sbox function was using "b+=16" instead of "b+=4".
+
+Also, you check test vector using :
+
+```c
+    uint64_t P = 0xfb623599da6e8127ull;
+    uint64_t T = 0x477d469dec0b8762ull;
+    uint64_t w0 = 0x84be85ce9804e94bull;
+    uint64_t k0 = 0xec2802d4e0a488e9ull;
+    ARMPACKey key = { .hi = w0, .lo = k0 };
+    uint64_t C5 = pauth_computepac(P, T, key);
+    /* C5 should be 0xc003b93999b33765 */
+```
+
+Ooof.  Good catch on the sbox error.
+
+That said, how did you test pauth_computepac?
+I still do not get the C5 result above, but 0x99d88f4472f3be39.
+
+The following test case sets up the parameters.
+
+Oops again.  The test case has the parts of the key the wrong way around.
+I'll submit the pair of patches to the mailing list.
+
+Now upstream as commit de0b1bae6461f67243282555475f88b2384a1eb9.
+
+Apparently this fixed bug is the official CVE-2020-10702:
+https://security-tracker.debian.org/tracker/CVE-2020-10702
+
diff --git a/results/classifier/118/architecture-arm/1861341 b/results/classifier/118/architecture-arm/1861341
new file mode 100644
index 00000000..27bc5438
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1861341
@@ -0,0 +1,97 @@
+architecture: 0.937
+arm: 0.878
+x86: 0.834
+kernel: 0.711
+device: 0.708
+graphic: 0.635
+semantic: 0.554
+user-level: 0.530
+files: 0.529
+socket: 0.466
+ppc: 0.461
+PID: 0.443
+register: 0.393
+performance: 0.389
+network: 0.383
+permissions: 0.359
+boot: 0.356
+vnc: 0.355
+mistranslation: 0.311
+TCG: 0.281
+risc-v: 0.275
+VMM: 0.241
+virtual: 0.217
+peripherals: 0.190
+hypervisor: 0.167
+debug: 0.124
+assembly: 0.113
+KVM: 0.096
+i386: 0.076
+--------------------
+arm: 0.997
+virtual: 0.310
+kernel: 0.046
+debug: 0.038
+hypervisor: 0.037
+files: 0.024
+TCG: 0.018
+register: 0.015
+architecture: 0.011
+user-level: 0.010
+performance: 0.007
+device: 0.006
+PID: 0.006
+semantic: 0.003
+boot: 0.002
+assembly: 0.002
+socket: 0.002
+peripherals: 0.001
+network: 0.001
+graphic: 0.001
+VMM: 0.001
+vnc: 0.001
+permissions: 0.000
+x86: 0.000
+risc-v: 0.000
+mistranslation: 0.000
+ppc: 0.000
+i386: 0.000
+KVM: 0.000
+
+ARM QEMU: Unknown syscall 397
+
+QEMU is reporting 
+
+```
+Unknown syscall 397
+```
+
+(statx if I read tables right) when used via flatpak for ARM images on x86_64. This has been reproduced on Fedora and Gentoo.
+
+To reproduce:
+
+- get flatpak KDE 5.12 for arm: 
+
+flatpak install --user org.kde.Sdk/arm/5.12 org.kde.Platform/arm/5.12
+
+
+- run qmake inside Sdk:
+
+QEMU_STRACE=1 flatpak run --filesystem=host --command=qmake org.kde.Sdk/arm/5.12 .
+
+
+You will get a host of messages with unknown syscall. In practice, qmake will fail to find .pro files if you have them in that folder and libraries in the system.
+
+As far as I understand, Flatpak images are built on AARCH64 hardware. 
+
+My config on Gentoo:
+
+kernel: 4.19.86-gentoo x86_64
+app-emulation/qemu: ~4.2.0-r1 , same with 4.0.0
+
+New syscall definitions for ARM have been added lately by:
+
+73209e1f15c6 ("linux-user: arm: Update syscall numbers to kernel 5.5 level")
+
+It will available in QEMU 5.0
+
diff --git a/results/classifier/118/architecture-arm/1869241 b/results/classifier/118/architecture-arm/1869241
new file mode 100644
index 00000000..b037abc5
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1869241
@@ -0,0 +1,85 @@
+architecture: 0.958
+arm: 0.810
+device: 0.770
+graphic: 0.706
+kernel: 0.674
+semantic: 0.664
+performance: 0.589
+files: 0.585
+vnc: 0.534
+virtual: 0.475
+user-level: 0.458
+debug: 0.412
+permissions: 0.401
+PID: 0.399
+network: 0.389
+register: 0.341
+VMM: 0.335
+risc-v: 0.322
+ppc: 0.299
+mistranslation: 0.290
+boot: 0.225
+TCG: 0.220
+socket: 0.204
+hypervisor: 0.173
+peripherals: 0.156
+assembly: 0.115
+KVM: 0.054
+x86: 0.039
+i386: 0.009
+--------------------
+arm: 0.994
+risc-v: 0.331
+kernel: 0.315
+hypervisor: 0.241
+debug: 0.215
+virtual: 0.141
+TCG: 0.078
+register: 0.045
+user-level: 0.017
+files: 0.014
+network: 0.014
+device: 0.009
+VMM: 0.006
+performance: 0.006
+semantic: 0.004
+architecture: 0.004
+PID: 0.004
+socket: 0.001
+peripherals: 0.001
+boot: 0.001
+assembly: 0.001
+vnc: 0.001
+KVM: 0.001
+graphic: 0.001
+permissions: 0.000
+mistranslation: 0.000
+x86: 0.000
+ppc: 0.000
+i386: 0.000
+
+svn checkout fails with E000075 "Value too large for defined data type"
+
+I try to autobuild for ARM7 with qemu-arm-static. Part of this is downloading source via SVN.
+
+Whenever I try to download a SVN repository I get the following output:
+
+    svn: E000075: Can't read directory '...': Value too large for defined data type
+
+qemu-arm-static version is 4.2.0
+
+I've also tried older versions without change.
+
+Platform I try to emulate is armv7h (Arch Linux ARM for Raspberry Pi 2)
+
+Host system is AMD64
+
+This can be reproduced 100% of the time. Here I have the issue happening on Travis CI:
+
+https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/304839747#L7228
+
+Hi; thanks for the bug report. This is a duplicate of LP:1805913. It requires a host kernel change to fix this bug (which is being discussed but hasn't been written yet). Otherwise the only known workarounds are:
+ * downgrade the guest (arm) glibc to 2.27 or earlier
+ * use a filesystem on the host which is not ext3/ext4 (often not practical)
+
+
diff --git a/results/classifier/118/architecture-arm/1873898 b/results/classifier/118/architecture-arm/1873898
new file mode 100644
index 00000000..3e0771a6
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1873898
@@ -0,0 +1,104 @@
+arm: 0.912
+architecture: 0.823
+user-level: 0.747
+peripherals: 0.594
+ppc: 0.592
+mistranslation: 0.554
+device: 0.554
+graphic: 0.552
+network: 0.536
+files: 0.520
+semantic: 0.510
+socket: 0.496
+performance: 0.486
+permissions: 0.466
+kernel: 0.463
+debug: 0.441
+vnc: 0.432
+risc-v: 0.401
+register: 0.394
+assembly: 0.383
+TCG: 0.379
+PID: 0.367
+boot: 0.316
+x86: 0.292
+hypervisor: 0.283
+VMM: 0.234
+virtual: 0.226
+KVM: 0.182
+i386: 0.181
+--------------------
+arm: 0.994
+user-level: 0.888
+debug: 0.686
+TCG: 0.159
+virtual: 0.120
+performance: 0.088
+files: 0.087
+architecture: 0.056
+kernel: 0.020
+semantic: 0.016
+hypervisor: 0.012
+register: 0.008
+assembly: 0.008
+PID: 0.007
+boot: 0.005
+device: 0.003
+VMM: 0.003
+peripherals: 0.002
+network: 0.002
+permissions: 0.002
+graphic: 0.001
+mistranslation: 0.001
+vnc: 0.001
+socket: 0.001
+KVM: 0.001
+risc-v: 0.000
+ppc: 0.000
+x86: 0.000
+i386: 0.000
+
+arm linux-user: bkpt insn doesn't cause SIGTRAP
+
+QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signals. Test case:
+
+===begin bkpt.c===
+/* test bkpt insn */
+
+#include <stdlib.h>
+#include <stdio.h>
+
+int main(void)
+{
+    printf("breakpoint\n");
+#ifdef __aarch64__
+    __asm__ volatile("brk 0x42\n");
+#else
+    __asm__ volatile("bkpt 0x42\n");
+#endif
+    printf("done\n");
+    return 0;
+}
+===endit===
+
+Compile with
+$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c
+$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c
+
+Contrast aarch64 which delivers the SIGTRAP and arm which doesn't:
+
+$ qemu-aarch64 bkpt-aa64
+breakpoint
+qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
+Trace/breakpoint trap (core dumped)
+$ qemu-arm bkpt-aa32
+breakpoint
+done
+
+This is because in linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a syscall (which one depends on what happens to be in r7...). This code has been like this (more or less) since commit 06c949e62a098f in 2006 which added BKPT in the first place. This is probably because at the time the same code path was used to handle both Linux syscalls and semihosting calls, and (on M profile) BKPT does imply a semihosting call. But these days we've moved handling of semihosting out to an entirely different codepath, so we can fix this bug by simply removing this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like EXCP_DEBUG (as we do already on aarch64).
+
+Should be fixed in current git, will be in 5.2.
+
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=13a0c21e64bddf1a36
+
diff --git a/results/classifier/118/architecture-arm/1877137 b/results/classifier/118/architecture-arm/1877137
new file mode 100644
index 00000000..1f74fc58
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1877137
@@ -0,0 +1,81 @@
+architecture: 0.921
+register: 0.913
+arm: 0.906
+graphic: 0.845
+device: 0.763
+performance: 0.603
+PID: 0.525
+VMM: 0.523
+semantic: 0.500
+network: 0.479
+mistranslation: 0.450
+ppc: 0.443
+boot: 0.429
+vnc: 0.411
+TCG: 0.402
+debug: 0.379
+risc-v: 0.364
+files: 0.255
+socket: 0.215
+user-level: 0.195
+virtual: 0.190
+permissions: 0.171
+x86: 0.139
+peripherals: 0.089
+i386: 0.084
+hypervisor: 0.069
+kernel: 0.065
+assembly: 0.054
+KVM: 0.045
+--------------------
+arm: 0.980
+debug: 0.242
+hypervisor: 0.125
+PID: 0.088
+virtual: 0.087
+files: 0.068
+TCG: 0.052
+performance: 0.044
+architecture: 0.033
+user-level: 0.032
+semantic: 0.014
+device: 0.009
+register: 0.007
+kernel: 0.006
+assembly: 0.006
+network: 0.005
+graphic: 0.003
+socket: 0.002
+peripherals: 0.002
+boot: 0.002
+ppc: 0.002
+risc-v: 0.002
+permissions: 0.001
+x86: 0.001
+i386: 0.001
+mistranslation: 0.001
+vnc: 0.000
+VMM: 0.000
+KVM: 0.000
+
+32-bit Arm emulation spins at 100% during emacs build
+
+This test case exposes a QEMU bug when crossbuilding to arm32. The bug is only
+exposed on amd64 architecture or aarch64 hosts that can *only* execute
+64 bit applications.
+
+Usage:
+
+./setup.sh # installs docker and tweaks sysctl
+./qemu.sh # register qemu so you are able to run containers from other
+architectures
+./build.sh # try to build the docker image. Process should get stuck
+in a 100% CPU loop after a while
+
+Originally reported by, and test case developed by,
+Philippe Vaucher.
+
+
+
+Additional bug reports at https://bugs.launchpad.net/qemu/+bug/1861161 and https://bugs.launchpad.net/qemu/+bug/1805913
+
diff --git a/results/classifier/118/architecture-arm/1938 b/results/classifier/118/architecture-arm/1938
new file mode 100644
index 00000000..b5cce8bb
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1938
@@ -0,0 +1,96 @@
+architecture: 0.970
+arm: 0.948
+graphic: 0.858
+device: 0.845
+peripherals: 0.824
+debug: 0.801
+register: 0.744
+semantic: 0.724
+user-level: 0.678
+performance: 0.651
+mistranslation: 0.592
+ppc: 0.462
+socket: 0.405
+network: 0.368
+files: 0.366
+x86: 0.354
+PID: 0.350
+boot: 0.321
+VMM: 0.302
+risc-v: 0.284
+kernel: 0.257
+assembly: 0.249
+TCG: 0.201
+virtual: 0.188
+vnc: 0.164
+i386: 0.161
+hypervisor: 0.154
+KVM: 0.074
+permissions: 0.048
+--------------------
+arm: 0.905
+kernel: 0.351
+hypervisor: 0.308
+peripherals: 0.300
+debug: 0.281
+architecture: 0.192
+virtual: 0.187
+files: 0.081
+register: 0.077
+device: 0.046
+semantic: 0.040
+VMM: 0.030
+user-level: 0.027
+assembly: 0.023
+TCG: 0.018
+boot: 0.017
+socket: 0.013
+vnc: 0.010
+network: 0.009
+PID: 0.008
+KVM: 0.005
+performance: 0.005
+permissions: 0.004
+graphic: 0.003
+mistranslation: 0.003
+risc-v: 0.003
+ppc: 0.001
+x86: 0.000
+i386: 0.000
+
+[ARM/PL011] Wrong UART register spacing reported in DBG2/SPCR
+Description of problem:
+QEMU reports the UART address on aarch64 (for PL011 UART) via the ACPI DBG2 and SPCR tables using the ACPI GAS structure. According to MSFT documentation at https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table:
+
+> * The Register Bit Width field contains the register stride and must be a power of 2 that is at least as large as the access size. On 32-bit platforms this value cannot exceed 32. On 64-bit platforms this value cannot exceed 64.
+> * The Access Size field is used to determine whether byte, WORD, DWORD, or QWORD accesses are to be used. QWORD accesses are only valid on 64-bit architectures.
+
+For the PL011, the MMIO registers are:
+* spaced 4 bytes apart; therefore the reported bit width should be 32 instead of 8.
+* 16 bits wide; therefore the access width should be 2 instead of 1.
+
+In other words:
+```
+diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
+index 6b674231c2..cd284676d7 100644
+--- a/hw/arm/virt-acpi-build.c
++++ b/hw/arm/virt-acpi-build.c
+@@ -482,7 +482,7 @@ build_spcr(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
+     build_append_int_noprefix(table_data, 3, 1); /* ARM PL011 UART */
+     build_append_int_noprefix(table_data, 0, 3); /* Reserved */
+     /* Base Address */
+-    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 8, 0, 1,
++    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 32, 0, 2,
+                      vms->memmap[VIRT_UART].base);
+     /* Interrupt Type */
+     build_append_int_noprefix(table_data,
+@@ -673,7 +673,7 @@ build_dbg2(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
+     build_append_int_noprefix(table_data, 34, 2);
+ 
+     /* BaseAddressRegister[] */
+-    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 8, 0, 1,
++    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 32, 0, 2,
+                      vms->memmap[VIRT_UART].base);
+ 
+     /* AddressSize[] */
+```
diff --git a/results/classifier/118/architecture-arm/1948 b/results/classifier/118/architecture-arm/1948
new file mode 100644
index 00000000..8990d2ce
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1948
@@ -0,0 +1,63 @@
+arm: 0.920
+architecture: 0.902
+semantic: 0.847
+graphic: 0.839
+device: 0.767
+network: 0.554
+performance: 0.534
+vnc: 0.488
+socket: 0.478
+i386: 0.435
+kernel: 0.425
+risc-v: 0.424
+mistranslation: 0.421
+debug: 0.416
+VMM: 0.392
+peripherals: 0.378
+register: 0.362
+x86: 0.355
+ppc: 0.338
+PID: 0.335
+TCG: 0.325
+boot: 0.312
+hypervisor: 0.303
+assembly: 0.300
+KVM: 0.282
+files: 0.224
+permissions: 0.181
+virtual: 0.159
+user-level: 0.150
+--------------------
+arm: 0.999
+architecture: 0.376
+user-level: 0.128
+register: 0.079
+hypervisor: 0.066
+TCG: 0.047
+virtual: 0.032
+permissions: 0.019
+device: 0.016
+debug: 0.014
+kernel: 0.014
+semantic: 0.013
+peripherals: 0.012
+files: 0.011
+boot: 0.011
+PID: 0.010
+assembly: 0.007
+performance: 0.006
+VMM: 0.004
+network: 0.003
+risc-v: 0.002
+vnc: 0.002
+socket: 0.002
+graphic: 0.002
+KVM: 0.001
+mistranslation: 0.000
+ppc: 0.000
+i386: 0.000
+x86: 0.000
+
+ARM GICv3 cannot support irq number > 992
+Description of problem:
+If we want to create a gic with supported irq number 992, we need to set the `num-irq` property to 992 + 32 while 32 is the extra SGI number. But there is a problem, when QEMU initialize GICv3, it will check the variable `num_irq <= 1020 && (num_irq & 32) == 0`, which will lead to error abort. So there is no way to bypass the ```num_irq <= 1020``` check and we cannot use irq number bigger than 992 while in ARM GIC specification, irq number < 1020 should all be aviliable to use.
diff --git a/results/classifier/118/architecture-arm/1963 b/results/classifier/118/architecture-arm/1963
new file mode 100644
index 00000000..1d321583
--- /dev/null
+++ b/results/classifier/118/architecture-arm/1963
@@ -0,0 +1,88 @@
+arm: 0.905
+graphic: 0.900
+architecture: 0.863
+performance: 0.850
+device: 0.834
+files: 0.713
+permissions: 0.616
+debug: 0.600
+semantic: 0.599
+vnc: 0.531
+network: 0.513
+ppc: 0.502
+socket: 0.452
+PID: 0.357
+TCG: 0.352
+mistranslation: 0.340
+risc-v: 0.330
+kernel: 0.324
+boot: 0.319
+peripherals: 0.314
+VMM: 0.305
+x86: 0.281
+user-level: 0.278
+i386: 0.276
+virtual: 0.211
+hypervisor: 0.194
+register: 0.185
+KVM: 0.093
+assembly: 0.073
+--------------------
+arm: 0.978
+debug: 0.592
+register: 0.498
+assembly: 0.484
+virtual: 0.258
+TCG: 0.071
+files: 0.068
+semantic: 0.039
+user-level: 0.023
+performance: 0.020
+PID: 0.012
+kernel: 0.009
+network: 0.008
+device: 0.006
+hypervisor: 0.004
+graphic: 0.004
+peripherals: 0.003
+architecture: 0.003
+boot: 0.003
+socket: 0.002
+permissions: 0.001
+VMM: 0.001
+risc-v: 0.001
+ppc: 0.001
+mistranslation: 0.001
+x86: 0.001
+vnc: 0.001
+i386: 0.000
+KVM: 0.000
+
+EOF is not detected, when semihosting is reading from stdin
+Description of problem:
+QEMU hangs.
+Steps to reproduce:
+1. Run the program with stdin from a pipe.
+Additional information:
+The code is compiled from this source:
+```
+#include <stdio.h>
+
+int main(int argc, char** argv) {
+    int i = -1;
+    int result = scanf("%d", &i);
+    printf("result = %d, i = %d\n", result, i);
+    return 0;
+}
+```
+compiled with GCC and picolibc:
+```
+arm-none-eabi-gcc --specs=picolibc.specs -march=armv7-m ~/sources/picolibc/git/test-stdin.c -o test-stdin -lc -lsemihost --crt0=hosted -O0 -g
+```
+[test-stdin](/uploads/dbd2650c8e0aaca353fd7630ac9c8440/test-stdin)
+The execution hangs at semihosting SYS_READC(0x7) call:
+```
+	movs r0, #7
+(...)
+	bkpt #0xab
+```
diff --git a/results/classifier/118/architecture-arm/2011 b/results/classifier/118/architecture-arm/2011
new file mode 100644
index 00000000..9c7d681f
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2011
@@ -0,0 +1,61 @@
+architecture: 0.983
+arm: 0.937
+device: 0.823
+x86: 0.802
+mistranslation: 0.548
+risc-v: 0.476
+performance: 0.441
+permissions: 0.401
+boot: 0.398
+semantic: 0.388
+register: 0.369
+graphic: 0.353
+socket: 0.343
+PID: 0.326
+vnc: 0.293
+VMM: 0.278
+files: 0.242
+ppc: 0.240
+TCG: 0.173
+virtual: 0.163
+debug: 0.110
+network: 0.107
+peripherals: 0.048
+user-level: 0.047
+assembly: 0.040
+kernel: 0.022
+hypervisor: 0.021
+i386: 0.015
+KVM: 0.005
+--------------------
+virtual: 0.922
+arm: 0.886
+VMM: 0.432
+x86: 0.396
+hypervisor: 0.144
+architecture: 0.105
+KVM: 0.045
+files: 0.038
+TCG: 0.029
+user-level: 0.027
+semantic: 0.025
+device: 0.014
+boot: 0.011
+register: 0.010
+kernel: 0.007
+debug: 0.006
+peripherals: 0.005
+risc-v: 0.004
+permissions: 0.004
+assembly: 0.003
+PID: 0.003
+graphic: 0.002
+socket: 0.001
+performance: 0.001
+mistranslation: 0.001
+ppc: 0.001
+vnc: 0.000
+i386: 0.000
+network: 0.000
+
+ARM emulation layer for Windows x86_64 OS request
diff --git a/results/classifier/118/architecture-arm/2084 b/results/classifier/118/architecture-arm/2084
new file mode 100644
index 00000000..38b8c874
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2084
@@ -0,0 +1,61 @@
+arm: 0.974
+architecture: 0.923
+mistranslation: 0.861
+device: 0.712
+performance: 0.618
+hypervisor: 0.601
+semantic: 0.586
+debug: 0.447
+graphic: 0.387
+virtual: 0.382
+peripherals: 0.266
+x86: 0.206
+network: 0.177
+assembly: 0.116
+VMM: 0.110
+user-level: 0.079
+register: 0.071
+boot: 0.050
+permissions: 0.049
+KVM: 0.027
+vnc: 0.022
+PID: 0.019
+i386: 0.015
+TCG: 0.012
+kernel: 0.008
+socket: 0.006
+files: 0.006
+ppc: 0.005
+risc-v: 0.004
+--------------------
+arm: 0.988
+virtual: 0.970
+hypervisor: 0.935
+VMM: 0.777
+user-level: 0.496
+KVM: 0.284
+debug: 0.046
+assembly: 0.037
+semantic: 0.026
+register: 0.014
+files: 0.013
+boot: 0.013
+architecture: 0.012
+TCG: 0.011
+kernel: 0.010
+device: 0.009
+performance: 0.006
+peripherals: 0.003
+socket: 0.003
+PID: 0.002
+risc-v: 0.002
+graphic: 0.002
+network: 0.001
+permissions: 0.001
+vnc: 0.001
+mistranslation: 0.000
+ppc: 0.000
+x86: 0.000
+i386: 0.000
+
+"qemu-system-arm -machine virt -cpu cortex-a9" error message includes a lot of "(null)"s
diff --git a/results/classifier/118/architecture-arm/2173 b/results/classifier/118/architecture-arm/2173
new file mode 100644
index 00000000..ade61a40
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2173
@@ -0,0 +1,61 @@
+architecture: 0.984
+arm: 0.898
+device: 0.896
+hypervisor: 0.709
+ppc: 0.658
+network: 0.601
+performance: 0.507
+VMM: 0.501
+risc-v: 0.489
+TCG: 0.482
+register: 0.468
+PID: 0.459
+debug: 0.423
+semantic: 0.391
+vnc: 0.367
+graphic: 0.343
+files: 0.327
+boot: 0.319
+permissions: 0.302
+socket: 0.246
+assembly: 0.215
+virtual: 0.212
+kernel: 0.205
+mistranslation: 0.201
+user-level: 0.170
+peripherals: 0.118
+i386: 0.096
+KVM: 0.039
+x86: 0.037
+--------------------
+hypervisor: 0.987
+virtual: 0.966
+arm: 0.963
+kernel: 0.817
+performance: 0.470
+debug: 0.177
+architecture: 0.106
+assembly: 0.058
+TCG: 0.041
+PID: 0.040
+device: 0.029
+semantic: 0.021
+user-level: 0.018
+register: 0.017
+socket: 0.011
+files: 0.008
+permissions: 0.007
+boot: 0.005
+risc-v: 0.002
+VMM: 0.002
+graphic: 0.002
+peripherals: 0.001
+network: 0.001
+KVM: 0.001
+mistranslation: 0.000
+vnc: 0.000
+ppc: 0.000
+x86: 0.000
+i386: 0.000
+
+Disable CPU dirty region tracking on Xen + Arm64 where xen migration is not supported.
diff --git a/results/classifier/118/architecture-arm/2250 b/results/classifier/118/architecture-arm/2250
new file mode 100644
index 00000000..4e1e3fc9
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2250
@@ -0,0 +1,104 @@
+architecture: 0.917
+performance: 0.910
+peripherals: 0.901
+mistranslation: 0.876
+arm: 0.855
+virtual: 0.852
+kernel: 0.842
+device: 0.836
+PID: 0.828
+KVM: 0.821
+ppc: 0.814
+debug: 0.803
+hypervisor: 0.799
+graphic: 0.776
+permissions: 0.773
+semantic: 0.760
+vnc: 0.733
+register: 0.729
+network: 0.711
+user-level: 0.691
+VMM: 0.690
+socket: 0.675
+files: 0.672
+risc-v: 0.668
+TCG: 0.593
+x86: 0.565
+boot: 0.562
+assembly: 0.492
+i386: 0.453
+--------------------
+arm: 0.975
+virtual: 0.718
+user-level: 0.393
+assembly: 0.366
+debug: 0.343
+kernel: 0.092
+KVM: 0.064
+hypervisor: 0.058
+files: 0.055
+performance: 0.051
+TCG: 0.041
+architecture: 0.024
+PID: 0.023
+device: 0.023
+semantic: 0.022
+register: 0.019
+boot: 0.016
+peripherals: 0.014
+permissions: 0.011
+vnc: 0.010
+VMM: 0.010
+risc-v: 0.008
+network: 0.007
+graphic: 0.005
+socket: 0.003
+mistranslation: 0.003
+ppc: 0.002
+x86: 0.000
+i386: 0.000
+
+FEAT_RME: NS EL1/0 Address Translation from EL3 fails
+Description of problem:
+I'm playing around with the QEMU RME Stack (TF-A, TF-RMM, Linux/KVM) for a research project.  
+For this I want to access some virtual normal world memory address from within EL3.
+To translate the address to the physical address I use the `AT` instructions (e.g., `ats1e2r`).  
+If the NW memory is initially mapped in the GPT as `GPT_GPI_ANY`, this works fine, however, if the NW memory is mapped as `GPT_GPI_NS` the address translation fails with the error `0b100101`/GPT on PTW.  
+However, EL3/Root World should be able to access memory from all PAS, and therefore, if I understand the ARM documentation correctly, should also be able to execute a PTW for an address marked NS in the GPT.
+Steps to reproduce:
+1. Setup GPT with some memory marked as `GPT_GPI_NS`
+2. Forward some NW virtual address from the kernel to EL3
+3. Execute a PTW on this address via the `AT` instructions.
+Additional information:
+I also took a look into the QEMU source code and potentially found the issue.  
+When executing a PTW we execute `target/arm/ptw.c:granule_protection_check`.  
+The function extracts the target page's GPI (`ptw.c:440'):  
+```c 
+ switch (gpi) {
+    case 0b0000: /* no access */
+        break;
+    case 0b1111: /* all access */
+        return true;
+    case 0b1000:
+    case 0b1001:
+    case 0b1010:
+    case 0b1011:
+        if (pspace == (gpi & 3)) {
+            return true;
+        }
+        break;
+    default:
+        goto fault_walk; /* reserved */
+    }
+```
+The if statement checks if the current `pstate` (previously set to `ptw->in_space`) is the same security state as the one contained in the GPI.  
+If this is not the case, we generate a GPF.  
+However, I think the code misses the fact, that EL3/Root world can access memory from each PAS, meaning that the if statement should be something like
+```c
+if (pspace == (gpi & 3) || (pspace == ARMSS_Root)) {
+            return true;
+}
+```
+Additionally, as both Secure and Realm World can also access Normal World memory, similar checks should also be added in such cases.  
+ 
+I have a patch prepared for this, however, I first want to check in if I'm in line with the Arm ARM or if I'm missing something and EL3 is indeed not supposed to execute PTWs for NS memory.
diff --git a/results/classifier/118/architecture-arm/2322 b/results/classifier/118/architecture-arm/2322
new file mode 100644
index 00000000..97552d34
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2322
@@ -0,0 +1,61 @@
+architecture: 0.975
+arm: 0.932
+device: 0.907
+hypervisor: 0.608
+graphic: 0.583
+network: 0.579
+performance: 0.461
+files: 0.426
+permissions: 0.396
+boot: 0.391
+kernel: 0.372
+user-level: 0.359
+ppc: 0.329
+semantic: 0.320
+PID: 0.312
+peripherals: 0.295
+register: 0.288
+mistranslation: 0.266
+socket: 0.254
+debug: 0.246
+virtual: 0.235
+risc-v: 0.230
+vnc: 0.181
+TCG: 0.138
+assembly: 0.108
+VMM: 0.075
+i386: 0.030
+x86: 0.018
+KVM: 0.004
+--------------------
+arm: 0.995
+hypervisor: 0.986
+virtual: 0.958
+user-level: 0.068
+KVM: 0.057
+architecture: 0.053
+files: 0.025
+VMM: 0.015
+semantic: 0.012
+device: 0.010
+TCG: 0.008
+kernel: 0.006
+assembly: 0.005
+debug: 0.005
+PID: 0.005
+performance: 0.004
+register: 0.004
+graphic: 0.003
+socket: 0.002
+boot: 0.002
+peripherals: 0.001
+risc-v: 0.001
+network: 0.000
+ppc: 0.000
+mistranslation: 0.000
+permissions: 0.000
+vnc: 0.000
+x86: 0.000
+i386: 0.000
+
+Qemu 9 make install failed on Ubuntu 23.10 ARM64
diff --git a/results/classifier/118/architecture-arm/2529 b/results/classifier/118/architecture-arm/2529
new file mode 100644
index 00000000..da17ae7d
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2529
@@ -0,0 +1,92 @@
+architecture: 0.942
+graphic: 0.914
+device: 0.897
+permissions: 0.894
+arm: 0.894
+performance: 0.761
+PID: 0.754
+hypervisor: 0.741
+register: 0.701
+semantic: 0.678
+boot: 0.629
+peripherals: 0.574
+risc-v: 0.559
+debug: 0.545
+mistranslation: 0.520
+ppc: 0.504
+vnc: 0.448
+TCG: 0.441
+kernel: 0.407
+VMM: 0.380
+user-level: 0.349
+socket: 0.320
+network: 0.287
+files: 0.198
+assembly: 0.097
+KVM: 0.088
+virtual: 0.080
+x86: 0.024
+i386: 0.015
+--------------------
+arm: 0.904
+virtual: 0.856
+TCG: 0.561
+PID: 0.509
+debug: 0.354
+register: 0.138
+risc-v: 0.095
+kernel: 0.095
+files: 0.047
+hypervisor: 0.033
+socket: 0.026
+user-level: 0.017
+ppc: 0.017
+performance: 0.016
+device: 0.014
+network: 0.009
+x86: 0.006
+VMM: 0.005
+assembly: 0.004
+semantic: 0.004
+boot: 0.003
+architecture: 0.003
+peripherals: 0.003
+permissions: 0.002
+graphic: 0.002
+vnc: 0.001
+KVM: 0.001
+i386: 0.001
+mistranslation: 0.000
+
+`stack smashing detected` running arm64 image from amd64 machine
+Description of problem:
+When running a linux/arm64 `ubuntu:20.04` docker image on a linux/amd64 machine, an single command `apt-get update` will through below error
+```sh
+root@189bd36b9ae7:/# apt-get update
+0% [Working]*** stack smashing detected ***: terminated
+Reading package lists... Done
+E: Method http has died unexpectedly!
+E: Sub-process http received signal 6.
+
+```
+
+Tested this is happening for ubuntu:18.04, ubuntu:20.04, ubuntu:22.04 so far
+
+If running same image directly from an ARM64 host, issue is gone
+Steps to reproduce:
+1. install QEMU on an AMD64 host machine (Ubuntu20)
+   ```sh
+   docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
+   ```
+2. run linux/arm64 docker image of ubuntu:20.04
+   ```sh
+   docker run --platform linux/arm64 -it --entrypoint /bin/bash ubuntu:20.04
+   ``` 
+3. from within the container, run `apt-get update`, it will through below error
+   ```sh
+   root@189bd36b9ae7:/# apt-get update
+   0% [Working]*** stack smashing detected ***: terminated
+   Reading package lists... Done
+   E: Method http has died unexpectedly!
+   E: Sub-process http received signal 6.
+   ```
diff --git a/results/classifier/118/architecture-arm/2549 b/results/classifier/118/architecture-arm/2549
new file mode 100644
index 00000000..653f6789
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2549
@@ -0,0 +1,63 @@
+architecture: 0.962
+arm: 0.960
+register: 0.898
+device: 0.842
+assembly: 0.802
+performance: 0.768
+graphic: 0.643
+network: 0.462
+ppc: 0.440
+VMM: 0.409
+i386: 0.389
+mistranslation: 0.362
+vnc: 0.354
+semantic: 0.335
+x86: 0.328
+socket: 0.313
+debug: 0.296
+boot: 0.281
+files: 0.266
+PID: 0.261
+kernel: 0.261
+hypervisor: 0.247
+TCG: 0.242
+peripherals: 0.200
+virtual: 0.138
+user-level: 0.122
+permissions: 0.118
+risc-v: 0.037
+KVM: 0.023
+--------------------
+arm: 0.997
+virtual: 0.918
+register: 0.821
+device: 0.066
+TCG: 0.063
+VMM: 0.050
+assembly: 0.033
+debug: 0.028
+performance: 0.023
+hypervisor: 0.021
+semantic: 0.018
+files: 0.011
+user-level: 0.010
+peripherals: 0.008
+architecture: 0.007
+KVM: 0.006
+PID: 0.006
+kernel: 0.005
+socket: 0.003
+boot: 0.002
+graphic: 0.002
+permissions: 0.002
+network: 0.001
+risc-v: 0.001
+ppc: 0.001
+vnc: 0.001
+x86: 0.000
+mistranslation: 0.000
+i386: 0.000
+
+qemu-system-arm, ast2400-a1, The ECC_TEST_CTRL register of aspeed_2400_sdmc_write is not implemented
+Additional information:
+The ast2400-a1 has a few more memory test modes compared to the ast2500-a2 (1xxb in 8:6 and 11b in 2:1), but I think it should be enough to always return a test pass result.
diff --git a/results/classifier/118/architecture-arm/268 b/results/classifier/118/architecture-arm/268
new file mode 100644
index 00000000..d1550aee
--- /dev/null
+++ b/results/classifier/118/architecture-arm/268
@@ -0,0 +1,61 @@
+arm: 0.996
+architecture: 0.913
+device: 0.877
+performance: 0.603
+debug: 0.509
+register: 0.507
+vnc: 0.435
+assembly: 0.414
+risc-v: 0.398
+semantic: 0.374
+graphic: 0.346
+VMM: 0.343
+network: 0.323
+permissions: 0.319
+boot: 0.289
+PID: 0.269
+ppc: 0.262
+kernel: 0.246
+i386: 0.233
+TCG: 0.206
+files: 0.174
+peripherals: 0.159
+socket: 0.125
+mistranslation: 0.120
+KVM: 0.103
+virtual: 0.083
+user-level: 0.081
+hypervisor: 0.077
+x86: 0.012
+--------------------
+arm: 0.997
+kernel: 0.638
+debug: 0.334
+register: 0.100
+assembly: 0.086
+architecture: 0.067
+device: 0.027
+performance: 0.022
+TCG: 0.022
+peripherals: 0.017
+VMM: 0.016
+semantic: 0.015
+KVM: 0.014
+files: 0.011
+virtual: 0.011
+hypervisor: 0.007
+PID: 0.006
+vnc: 0.003
+socket: 0.003
+user-level: 0.002
+graphic: 0.002
+network: 0.001
+permissions: 0.001
+risc-v: 0.001
+boot: 0.001
+mistranslation: 0.000
+x86: 0.000
+i386: 0.000
+ppc: 0.000
+
+arm gic: gic_acknowledge_irq doesn't clear line level for other cores for 1-n level-sensitive interrupts and gic_clear_pending uses GIC_DIST_TEST_MODEL (even on v2 where it always read 0 - "N-N")
diff --git a/results/classifier/118/architecture-arm/271 b/results/classifier/118/architecture-arm/271
new file mode 100644
index 00000000..a232d376
--- /dev/null
+++ b/results/classifier/118/architecture-arm/271
@@ -0,0 +1,61 @@
+architecture: 0.967
+arm: 0.951
+device: 0.818
+performance: 0.680
+graphic: 0.489
+debug: 0.450
+risc-v: 0.256
+permissions: 0.255
+boot: 0.254
+files: 0.248
+register: 0.229
+ppc: 0.228
+semantic: 0.174
+PID: 0.170
+vnc: 0.168
+mistranslation: 0.144
+socket: 0.143
+i386: 0.113
+user-level: 0.083
+TCG: 0.071
+network: 0.069
+virtual: 0.062
+VMM: 0.059
+assembly: 0.021
+x86: 0.021
+kernel: 0.019
+hypervisor: 0.019
+peripherals: 0.003
+KVM: 0.003
+--------------------
+arm: 0.998
+virtual: 0.906
+user-level: 0.107
+debug: 0.105
+hypervisor: 0.085
+register: 0.060
+architecture: 0.056
+performance: 0.045
+files: 0.030
+kernel: 0.025
+device: 0.021
+PID: 0.017
+TCG: 0.016
+semantic: 0.011
+assembly: 0.008
+boot: 0.005
+graphic: 0.004
+risc-v: 0.003
+peripherals: 0.003
+socket: 0.003
+mistranslation: 0.000
+VMM: 0.000
+permissions: 0.000
+network: 0.000
+vnc: 0.000
+KVM: 0.000
+x86: 0.000
+i386: 0.000
+ppc: 0.000
+
+ARM cpu emulation regression on QEMU 4.2.0
diff --git a/results/classifier/118/architecture-arm/2721 b/results/classifier/118/architecture-arm/2721
new file mode 100644
index 00000000..5c299172
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2721
@@ -0,0 +1,61 @@
+architecture: 0.951
+arm: 0.916
+device: 0.816
+performance: 0.684
+debug: 0.674
+boot: 0.646
+network: 0.558
+graphic: 0.539
+files: 0.484
+register: 0.427
+semantic: 0.412
+TCG: 0.335
+risc-v: 0.324
+mistranslation: 0.294
+vnc: 0.279
+VMM: 0.259
+ppc: 0.196
+peripherals: 0.186
+virtual: 0.167
+user-level: 0.162
+hypervisor: 0.159
+permissions: 0.120
+kernel: 0.115
+PID: 0.087
+socket: 0.077
+assembly: 0.047
+KVM: 0.008
+x86: 0.003
+i386: 0.002
+--------------------
+arm: 0.998
+semantic: 0.583
+architecture: 0.188
+kernel: 0.109
+debug: 0.079
+device: 0.033
+boot: 0.026
+TCG: 0.025
+assembly: 0.023
+virtual: 0.019
+performance: 0.018
+files: 0.018
+VMM: 0.018
+socket: 0.014
+KVM: 0.009
+PID: 0.008
+user-level: 0.007
+register: 0.004
+hypervisor: 0.004
+risc-v: 0.003
+peripherals: 0.001
+network: 0.001
+graphic: 0.001
+vnc: 0.001
+permissions: 0.000
+mistranslation: 0.000
+ppc: 0.000
+x86: 0.000
+i386: 0.000
+
+Failure with macOS 15.2 on ARM64: Property 'host-arm-cpu.sme' not found
diff --git a/results/classifier/118/architecture-arm/2725 b/results/classifier/118/architecture-arm/2725
new file mode 100644
index 00000000..6b4be750
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2725
@@ -0,0 +1,61 @@
+architecture: 0.970
+arm: 0.842
+device: 0.803
+graphic: 0.648
+files: 0.532
+semantic: 0.508
+debug: 0.506
+performance: 0.481
+risc-v: 0.380
+network: 0.378
+mistranslation: 0.374
+PID: 0.343
+VMM: 0.337
+TCG: 0.299
+vnc: 0.276
+register: 0.261
+assembly: 0.250
+permissions: 0.245
+ppc: 0.220
+peripherals: 0.189
+hypervisor: 0.146
+user-level: 0.120
+virtual: 0.093
+boot: 0.092
+socket: 0.085
+kernel: 0.041
+KVM: 0.013
+x86: 0.008
+i386: 0.003
+--------------------
+architecture: 0.896
+arm: 0.501
+TCG: 0.035
+VMM: 0.032
+files: 0.027
+kernel: 0.022
+virtual: 0.021
+debug: 0.019
+assembly: 0.012
+register: 0.011
+semantic: 0.010
+device: 0.010
+KVM: 0.007
+user-level: 0.006
+boot: 0.005
+performance: 0.005
+socket: 0.004
+PID: 0.003
+risc-v: 0.002
+permissions: 0.002
+hypervisor: 0.002
+graphic: 0.001
+peripherals: 0.001
+vnc: 0.000
+network: 0.000
+mistranslation: 0.000
+ppc: 0.000
+x86: 0.000
+i386: 0.000
+
+multi-arch build at AMD64 for ARM64 fails without flag "F"
diff --git a/results/classifier/118/architecture-arm/2797 b/results/classifier/118/architecture-arm/2797
new file mode 100644
index 00000000..33743312
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2797
@@ -0,0 +1,63 @@
+arm: 0.942
+architecture: 0.835
+device: 0.770
+network: 0.511
+graphic: 0.499
+peripherals: 0.453
+performance: 0.422
+vnc: 0.393
+VMM: 0.389
+register: 0.380
+PID: 0.370
+ppc: 0.339
+semantic: 0.338
+TCG: 0.310
+assembly: 0.302
+socket: 0.294
+debug: 0.263
+risc-v: 0.254
+i386: 0.235
+boot: 0.229
+KVM: 0.187
+mistranslation: 0.186
+hypervisor: 0.165
+kernel: 0.106
+x86: 0.104
+user-level: 0.101
+files: 0.097
+permissions: 0.092
+virtual: 0.081
+--------------------
+arm: 0.992
+user-level: 0.631
+files: 0.181
+kernel: 0.103
+virtual: 0.059
+performance: 0.034
+VMM: 0.029
+device: 0.017
+TCG: 0.016
+assembly: 0.012
+register: 0.011
+permissions: 0.009
+debug: 0.006
+semantic: 0.006
+architecture: 0.005
+risc-v: 0.004
+peripherals: 0.004
+network: 0.003
+PID: 0.003
+KVM: 0.003
+boot: 0.003
+socket: 0.002
+hypervisor: 0.002
+ppc: 0.001
+graphic: 0.001
+vnc: 0.001
+mistranslation: 0.000
+x86: 0.000
+i386: 0.000
+
+arm/raspi.c - incease memory limit
+Additional information:
+I can attempt to make a PR that increases this limit, but not sure if others would find it useful.
diff --git a/results/classifier/118/architecture-arm/2944 b/results/classifier/118/architecture-arm/2944
new file mode 100644
index 00000000..c630040c
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2944
@@ -0,0 +1,81 @@
+architecture: 0.932
+arm: 0.910
+graphic: 0.893
+kernel: 0.893
+vnc: 0.876
+network: 0.859
+device: 0.856
+PID: 0.844
+permissions: 0.791
+ppc: 0.764
+boot: 0.733
+risc-v: 0.686
+semantic: 0.680
+TCG: 0.668
+files: 0.651
+socket: 0.629
+debug: 0.611
+register: 0.599
+peripherals: 0.587
+performance: 0.584
+x86: 0.553
+VMM: 0.524
+user-level: 0.523
+mistranslation: 0.465
+hypervisor: 0.456
+assembly: 0.264
+virtual: 0.260
+KVM: 0.122
+i386: 0.039
+--------------------
+arm: 0.999
+boot: 0.947
+kernel: 0.826
+debug: 0.605
+TCG: 0.185
+files: 0.052
+register: 0.030
+hypervisor: 0.022
+virtual: 0.019
+device: 0.017
+VMM: 0.011
+user-level: 0.009
+PID: 0.005
+performance: 0.004
+network: 0.004
+semantic: 0.003
+peripherals: 0.003
+assembly: 0.002
+architecture: 0.002
+socket: 0.001
+graphic: 0.001
+risc-v: 0.001
+vnc: 0.001
+permissions: 0.001
+KVM: 0.000
+x86: 0.000
+mistranslation: 0.000
+ppc: 0.000
+i386: 0.000
+
+Commit 59754f85 introduces regression with U-Boot on Cortex-A9 platforms
+Description of problem:
+In U-Boot CI, we started to update from v8.2.0 to v9.2.3 and found that the vexpress_ca9x4 platform was now failing one of the CI tests. I have reconfirmed the problem on top of tree QEMU, and bisected the failure to commit [59754f85("target/arm: Do memory type alignment check when translation disabled
+")](https://gitlab.com/qemu-project/qemu/-/commit/59754f85ed35cbd5f4bf2663ca2136c78d5b2413). I have also re-verified the test is fine on a physical platform with a Cortex-A9 that is as follows (per the RM):
+```
+Table 12-2. Cortex-A9 revision
+Core MP004-BU-50000-r2p10-0rel0
+NEON AT397-BU-50001- r2p0-00rel0
+PL310 PL310-BU-00000-r3p2-50rel0
+```
+Steps to reproduce:
+1. git clone https://source.denx.de/u-boot/u-boot.git; cd u-boot
+2. make O=/tmp/vexpress_ca9x4 CROSS_COMPILE=arm-linux-gnueabi- vexpress_ca9x4_config
+3. make O=/tmp/vexpress_ca9x4 CROSS_COMPILE=arm-linux-gnueabi- -sj$(nproc)
+4. qemu-system-arm -nographic -m 1G -audio none -net user,tftp=/tmp/vexpress_ca9x4 -net nic -M vexpress-a9 -kernel /tmp/vexpress_ca9x4/u-boot
+5. Stop autoboot with any key
+6. setenv autoload no
+7. dhcp
+8. tftpboot 60200000 lib/efi_loader/helloworld.efi
+Additional information:
+
diff --git a/results/classifier/118/architecture-arm/2986 b/results/classifier/118/architecture-arm/2986
new file mode 100644
index 00000000..daf775d3
--- /dev/null
+++ b/results/classifier/118/architecture-arm/2986
@@ -0,0 +1,61 @@
+arm: 0.947
+architecture: 0.936
+register: 0.907
+device: 0.886
+network: 0.795
+mistranslation: 0.648
+performance: 0.596
+debug: 0.536
+boot: 0.364
+graphic: 0.358
+semantic: 0.258
+ppc: 0.209
+i386: 0.156
+hypervisor: 0.152
+assembly: 0.095
+permissions: 0.087
+kernel: 0.086
+peripherals: 0.079
+x86: 0.042
+TCG: 0.036
+vnc: 0.031
+KVM: 0.029
+risc-v: 0.028
+VMM: 0.027
+virtual: 0.020
+user-level: 0.014
+files: 0.011
+PID: 0.006
+socket: 0.006
+--------------------
+arm: 0.999
+register: 0.989
+assembly: 0.884
+debug: 0.847
+architecture: 0.492
+semantic: 0.055
+virtual: 0.043
+kernel: 0.032
+peripherals: 0.027
+device: 0.024
+performance: 0.016
+files: 0.013
+user-level: 0.009
+KVM: 0.009
+mistranslation: 0.009
+graphic: 0.005
+risc-v: 0.005
+hypervisor: 0.004
+boot: 0.003
+TCG: 0.003
+VMM: 0.003
+PID: 0.002
+vnc: 0.002
+permissions: 0.002
+ppc: 0.001
+network: 0.001
+socket: 0.000
+i386: 0.000
+x86: 0.000
+
+ARM register DBGDTR_EL0 incorrectly causes undefined exception
diff --git a/results/classifier/118/architecture-arm/373 b/results/classifier/118/architecture-arm/373
new file mode 100644
index 00000000..5c59d04c
--- /dev/null
+++ b/results/classifier/118/architecture-arm/373
@@ -0,0 +1,61 @@
+architecture: 0.888
+arm: 0.875
+mistranslation: 0.807
+device: 0.698
+graphic: 0.423
+network: 0.351
+register: 0.344
+ppc: 0.340
+risc-v: 0.333
+semantic: 0.298
+performance: 0.290
+PID: 0.282
+vnc: 0.275
+TCG: 0.275
+socket: 0.264
+boot: 0.263
+VMM: 0.254
+files: 0.219
+debug: 0.205
+i386: 0.178
+virtual: 0.177
+permissions: 0.122
+assembly: 0.076
+peripherals: 0.049
+kernel: 0.035
+hypervisor: 0.021
+x86: 0.020
+KVM: 0.012
+user-level: 0.011
+--------------------
+arm: 0.947
+semantic: 0.128
+device: 0.039
+virtual: 0.028
+files: 0.017
+user-level: 0.016
+mistranslation: 0.013
+peripherals: 0.012
+PID: 0.009
+assembly: 0.008
+architecture: 0.007
+debug: 0.006
+register: 0.005
+TCG: 0.005
+ppc: 0.004
+VMM: 0.004
+risc-v: 0.003
+performance: 0.003
+socket: 0.003
+boot: 0.003
+kernel: 0.002
+graphic: 0.001
+network: 0.001
+vnc: 0.001
+KVM: 0.001
+hypervisor: 0.000
+permissions: 0.000
+i386: 0.000
+x86: 0.000
+
+Indentation should be done with spaces, not with TABs, in the ARM subsystem
diff --git a/results/classifier/118/architecture-arm/447 b/results/classifier/118/architecture-arm/447
new file mode 100644
index 00000000..05dde610
--- /dev/null
+++ b/results/classifier/118/architecture-arm/447
@@ -0,0 +1,61 @@
+arm: 0.936
+architecture: 0.894
+virtual: 0.781
+device: 0.776
+network: 0.658
+VMM: 0.569
+performance: 0.541
+debug: 0.520
+vnc: 0.417
+i386: 0.404
+assembly: 0.402
+graphic: 0.398
+files: 0.391
+socket: 0.361
+x86: 0.340
+PID: 0.331
+boot: 0.308
+hypervisor: 0.291
+permissions: 0.262
+kernel: 0.253
+peripherals: 0.252
+register: 0.221
+mistranslation: 0.208
+semantic: 0.183
+TCG: 0.135
+ppc: 0.107
+risc-v: 0.095
+user-level: 0.062
+KVM: 0.003
+--------------------
+arm: 0.996
+virtual: 0.954
+hypervisor: 0.812
+VMM: 0.418
+debug: 0.167
+register: 0.097
+performance: 0.033
+TCG: 0.025
+user-level: 0.024
+kernel: 0.015
+permissions: 0.014
+assembly: 0.014
+semantic: 0.012
+files: 0.011
+device: 0.011
+architecture: 0.007
+KVM: 0.005
+boot: 0.003
+PID: 0.002
+graphic: 0.002
+risc-v: 0.001
+socket: 0.001
+network: 0.001
+peripherals: 0.001
+vnc: 0.001
+mistranslation: 0.000
+x86: 0.000
+i386: 0.000
+ppc: 0.000
+
+qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option)
diff --git a/results/classifier/118/architecture-arm/480 b/results/classifier/118/architecture-arm/480
new file mode 100644
index 00000000..fbb919ce
--- /dev/null
+++ b/results/classifier/118/architecture-arm/480
@@ -0,0 +1,61 @@
+architecture: 0.980
+arm: 0.871
+device: 0.782
+permissions: 0.541
+performance: 0.474
+network: 0.391
+peripherals: 0.328
+assembly: 0.292
+socket: 0.259
+mistranslation: 0.254
+hypervisor: 0.253
+boot: 0.253
+register: 0.215
+risc-v: 0.215
+semantic: 0.196
+graphic: 0.156
+x86: 0.154
+user-level: 0.136
+vnc: 0.130
+virtual: 0.119
+PID: 0.098
+ppc: 0.091
+debug: 0.083
+TCG: 0.082
+kernel: 0.082
+VMM: 0.078
+files: 0.064
+KVM: 0.015
+i386: 0.006
+--------------------
+arm: 0.995
+architecture: 0.614
+assembly: 0.093
+virtual: 0.076
+semantic: 0.068
+files: 0.028
+device: 0.026
+mistranslation: 0.015
+user-level: 0.011
+kernel: 0.008
+performance: 0.008
+register: 0.006
+boot: 0.006
+PID: 0.006
+VMM: 0.005
+graphic: 0.004
+debug: 0.003
+TCG: 0.003
+risc-v: 0.002
+hypervisor: 0.002
+KVM: 0.002
+socket: 0.002
+permissions: 0.001
+peripherals: 0.001
+vnc: 0.001
+ppc: 0.000
+network: 0.000
+i386: 0.000
+x86: 0.000
+
+Supported ARMv8.? Opcodes
diff --git a/results/classifier/118/architecture-arm/613 b/results/classifier/118/architecture-arm/613
new file mode 100644
index 00000000..7f2d239d
--- /dev/null
+++ b/results/classifier/118/architecture-arm/613
@@ -0,0 +1,61 @@
+architecture: 0.954
+device: 0.892
+arm: 0.858
+performance: 0.766
+permissions: 0.638
+graphic: 0.550
+mistranslation: 0.440
+boot: 0.406
+network: 0.197
+semantic: 0.191
+ppc: 0.191
+debug: 0.157
+assembly: 0.142
+user-level: 0.097
+register: 0.088
+peripherals: 0.088
+vnc: 0.069
+virtual: 0.056
+socket: 0.044
+hypervisor: 0.040
+VMM: 0.036
+risc-v: 0.030
+files: 0.023
+i386: 0.022
+TCG: 0.021
+PID: 0.015
+x86: 0.014
+kernel: 0.007
+KVM: 0.001
+--------------------
+arm: 0.984
+virtual: 0.857
+assembly: 0.833
+architecture: 0.791
+performance: 0.066
+hypervisor: 0.059
+device: 0.045
+user-level: 0.045
+debug: 0.039
+files: 0.008
+semantic: 0.007
+TCG: 0.004
+register: 0.004
+graphic: 0.004
+kernel: 0.003
+peripherals: 0.003
+VMM: 0.002
+PID: 0.001
+boot: 0.001
+mistranslation: 0.001
+socket: 0.001
+risc-v: 0.000
+permissions: 0.000
+network: 0.000
+ppc: 0.000
+KVM: 0.000
+vnc: 0.000
+i386: 0.000
+x86: 0.000
+
+ARM cortex-m55 LOB instructions make QEMU crash
diff --git a/results/classifier/118/architecture-arm/732 b/results/classifier/118/architecture-arm/732
new file mode 100644
index 00000000..9b6484cb
--- /dev/null
+++ b/results/classifier/118/architecture-arm/732
@@ -0,0 +1,61 @@
+architecture: 0.966
+device: 0.912
+arm: 0.883
+performance: 0.708
+network: 0.695
+ppc: 0.656
+files: 0.571
+graphic: 0.557
+kernel: 0.539
+PID: 0.530
+peripherals: 0.524
+semantic: 0.513
+hypervisor: 0.495
+TCG: 0.483
+register: 0.399
+user-level: 0.399
+assembly: 0.395
+socket: 0.392
+debug: 0.378
+mistranslation: 0.372
+permissions: 0.370
+risc-v: 0.356
+vnc: 0.330
+VMM: 0.329
+boot: 0.322
+virtual: 0.173
+KVM: 0.109
+x86: 0.092
+i386: 0.066
+--------------------
+arm: 0.891
+architecture: 0.790
+permissions: 0.742
+kernel: 0.570
+user-level: 0.067
+device: 0.032
+virtual: 0.028
+files: 0.026
+semantic: 0.018
+TCG: 0.015
+debug: 0.014
+PID: 0.010
+hypervisor: 0.009
+socket: 0.009
+performance: 0.005
+VMM: 0.005
+assembly: 0.003
+boot: 0.003
+KVM: 0.001
+peripherals: 0.001
+graphic: 0.001
+risc-v: 0.001
+network: 0.001
+register: 0.001
+ppc: 0.001
+mistranslation: 0.001
+vnc: 0.000
+x86: 0.000
+i386: 0.000
+
+Can not use --enable-fuzzing on Ubuntu 20.04 Aarch64
diff --git a/results/classifier/118/architecture-arm/73660729 b/results/classifier/118/architecture-arm/73660729
new file mode 100644
index 00000000..c8bc62e3
--- /dev/null
+++ b/results/classifier/118/architecture-arm/73660729
@@ -0,0 +1,86 @@
+arm: 0.920
+architecture: 0.913
+graphic: 0.858
+kernel: 0.798
+performance: 0.786
+x86: 0.785
+peripherals: 0.733
+virtual: 0.733
+semantic: 0.698
+device: 0.697
+hypervisor: 0.677
+ppc: 0.673
+files: 0.640
+mistranslation: 0.633
+network: 0.598
+VMM: 0.588
+register: 0.583
+debug: 0.580
+socket: 0.556
+user-level: 0.556
+PID: 0.549
+TCG: 0.541
+i386: 0.532
+risc-v: 0.497
+vnc: 0.467
+permissions: 0.403
+assembly: 0.393
+boot: 0.367
+KVM: 0.272
+--------------------
+arm: 0.988
+debug: 0.925
+kernel: 0.875
+hypervisor: 0.821
+user-level: 0.793
+virtual: 0.156
+files: 0.096
+architecture: 0.062
+device: 0.035
+VMM: 0.033
+TCG: 0.028
+network: 0.013
+PID: 0.009
+register: 0.009
+performance: 0.006
+socket: 0.005
+risc-v: 0.003
+semantic: 0.003
+ppc: 0.002
+assembly: 0.002
+peripherals: 0.002
+KVM: 0.001
+boot: 0.001
+graphic: 0.001
+permissions: 0.001
+vnc: 0.001
+x86: 0.001
+i386: 0.000
+mistranslation: 0.000
+
+[BUG]The latest qemu crashed when I tested cxl
+
+I test cxl with the patch:[v11,0/2] arm/virt:
+ CXL support via pxb_cxl.
+https://patchwork.kernel.org/project/cxl/cover/20220616141950.23374-1-Jonathan.Cameron@huawei.com/
+But the qemu crashed,and showing an error:
+qemu-system-aarch64: ../hw/arm/virt.c:1735: virt_get_high_memmap_enabled:
+ Assertion `ARRAY_SIZE(extended_memmap) - VIRT_LOWMEMMAP_LAST == ARRAY_SIZE(enabled_array)' failed.
+Then I modify the patch to fix the bug:
+diff --git a/hw/arm/virt.c b/hw/arm/virt.c
+index ea2413a0ba..3d4cee3491 100644
+--- a/hw/arm/virt.c
++++ b/hw/arm/virt.c
+@@ -1710,6 +1730,7 @@ static inline bool *virt_get_high_memmap_enabled(VirtMachineState
+ *vms,
+&vms->highmem_redists,
+&vms->highmem_ecam,
+&vms->highmem_mmio,
++ &vms->cxl_devices_state.is_enabled,
+};
+Now qemu works good.
+Could you tell me when the patch(
+arm/virt:
+ CXL support via pxb_cxl
+) will be merged into upstream?
+
diff --git a/results/classifier/118/architecture-arm/944628 b/results/classifier/118/architecture-arm/944628
new file mode 100644
index 00000000..b61d563d
--- /dev/null
+++ b/results/classifier/118/architecture-arm/944628
@@ -0,0 +1,78 @@
+arm: 0.851
+architecture: 0.847
+device: 0.716
+graphic: 0.407
+network: 0.395
+peripherals: 0.304
+mistranslation: 0.304
+boot: 0.299
+socket: 0.283
+kernel: 0.215
+hypervisor: 0.202
+semantic: 0.189
+performance: 0.155
+files: 0.153
+virtual: 0.151
+register: 0.147
+debug: 0.138
+permissions: 0.132
+PID: 0.123
+VMM: 0.106
+ppc: 0.096
+risc-v: 0.087
+vnc: 0.080
+user-level: 0.078
+TCG: 0.069
+KVM: 0.052
+i386: 0.021
+assembly: 0.019
+x86: 0.009
+--------------------
+arm: 0.979
+hypervisor: 0.398
+TCG: 0.255
+files: 0.069
+architecture: 0.067
+device: 0.060
+VMM: 0.058
+debug: 0.051
+kernel: 0.041
+semantic: 0.026
+user-level: 0.024
+virtual: 0.024
+peripherals: 0.022
+risc-v: 0.017
+PID: 0.012
+network: 0.010
+boot: 0.010
+register: 0.008
+ppc: 0.005
+socket: 0.005
+i386: 0.005
+x86: 0.004
+assembly: 0.004
+graphic: 0.003
+permissions: 0.003
+performance: 0.003
+vnc: 0.002
+mistranslation: 0.001
+KVM: 0.001
+
+Documentation for mtdblock, option-rom, and pflash is non-existent
+
+The options -mtdblock, -option-rom, and -pflash are severely under-documented.  For example:
+
+-mtdblock  -- It isn't at all clear what this does from --help or the documentation, and it's especially not clear that it's only implemented for ARM right now
+
+-option-rom is only implemented for a handful of architectures, including palm, pc, pci, and one or two others
+
+-pflash looks to be implemented for most if not all architectures, but there's nothing informing the user that it replaces the bios if -bios isn't used in tandem with -pflash, and it isn't clear whether the user could add multiple pflash roms
+
+
+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/89
+
+
diff --git a/results/classifier/118/architecture-arm/970 b/results/classifier/118/architecture-arm/970
new file mode 100644
index 00000000..5653db4c
--- /dev/null
+++ b/results/classifier/118/architecture-arm/970
@@ -0,0 +1,93 @@
+architecture: 0.936
+arm: 0.880
+graphic: 0.879
+performance: 0.862
+peripherals: 0.826
+mistranslation: 0.807
+semantic: 0.799
+register: 0.700
+device: 0.671
+VMM: 0.647
+network: 0.636
+permissions: 0.604
+ppc: 0.571
+debug: 0.528
+kernel: 0.527
+vnc: 0.510
+assembly: 0.502
+user-level: 0.479
+PID: 0.470
+socket: 0.403
+hypervisor: 0.385
+risc-v: 0.369
+x86: 0.369
+boot: 0.353
+virtual: 0.335
+i386: 0.289
+TCG: 0.277
+KVM: 0.234
+files: 0.226
+--------------------
+arm: 0.986
+user-level: 0.813
+debug: 0.740
+register: 0.305
+files: 0.049
+virtual: 0.040
+hypervisor: 0.039
+kernel: 0.025
+architecture: 0.022
+semantic: 0.021
+device: 0.018
+assembly: 0.017
+boot: 0.015
+TCG: 0.011
+risc-v: 0.007
+permissions: 0.007
+performance: 0.007
+PID: 0.007
+VMM: 0.003
+peripherals: 0.003
+socket: 0.002
+vnc: 0.001
+network: 0.001
+graphic: 0.001
+KVM: 0.001
+mistranslation: 0.001
+i386: 0.000
+x86: 0.000
+ppc: 0.000
+
+ARM SCTLR allows writes to "write ignore" bits
+Description of problem:
+The firmware I have executed in qemu sets up pagetables and then enables the MMU.
+A few instructions later, a prefetch abort was occurring. After debugging it turned out the problem was because get_phys_addr_v5 was being used to walk the pagetable instead of get_phys_addr_v6.
+qemu has this code:
+```c
+regime_sctlr(env, mmu_idx) & SCTLR_XP
+// where SCTLR_XP is commented as
+#define SCTLR_XP      (1U << 23) /* up to v6; v7 onward RAO */
+```
+Somewhat interestingly, A5 has a lot of bits marked as `/WI`: https://developer.arm.com/documentation/ddi0433/c/system-control/register-descriptions/system-control-register
+
+A9 has less, but still a few which qemu is not handling: https://developer.arm.com/documentation/ddi0388/e/the-system-control-coprocessors/summary-of-system-control-coprocessor-registers/system-control-register
+I've made this hacky patch to fix it for myself:
+```diff
+diff --git a/qemu/target/arm/helper.c b/qemu/target/arm/helper.c
+index 60c9db9e..d8fd5a7d 100644
+--- a/qemu/target/arm/helper.c
++++ b/qemu/target/arm/helper.c
+@@ -4306,6 +4306,11 @@ static void sctlr_write(CPUARMState *env, const ARMCPRegInfo *ri,
+ {
+     ARMCPU *cpu = env_archcpu(env);
+
++    // for cortex-a5 specifically
++    value |= (0b11 << 22) | (1 << 18) | (1 << 16) | (0b1111 << 3);
++    value &= ~((1 << 31) | (0b11 << 26) | (1 << 24) | (0b111 << 19) |
++        (1 << 17) | (0b11 << 14) | (0b111 << 7));
++
+     if (raw_read(env, ri) == value) {
+         /* Skip the TLB flush if nothing actually changed; Linux likes
+          * to do a lot of pointless SCTLR writes.
+```
+I think the real fix would allow expressing the ones/zeros mask as part of `ARMCPU` per-arch.
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/architecture-arm
parent	b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download	emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip