diff options
Diffstat (limited to 'results/classifier/118/arm')
44 files changed, 2018 insertions, 0 deletions
diff --git a/results/classifier/118/arm/1070 b/results/classifier/118/arm/1070 new file mode 100644 index 000000000..486d426c7 --- /dev/null +++ b/results/classifier/118/arm/1070 @@ -0,0 +1,40 @@ +arm: 0.826 +device: 0.770 +architecture: 0.706 +graphic: 0.678 +register: 0.628 +debug: 0.578 +performance: 0.520 +semantic: 0.397 +kernel: 0.376 +ppc: 0.346 +risc-v: 0.337 +vnc: 0.309 +mistranslation: 0.304 +PID: 0.298 +boot: 0.277 +files: 0.271 +user-level: 0.230 +socket: 0.224 +TCG: 0.205 +permissions: 0.190 +VMM: 0.107 +virtual: 0.093 +network: 0.087 +hypervisor: 0.048 +assembly: 0.033 +i386: 0.020 +peripherals: 0.012 +KVM: 0.006 +x86: 0.001 + +gdbstub XML generation for ARM is done for every CPU +Description of problem: +- As arm_cpu_register_gdb_regs_for_features is called from the device + realize stage for each vCPU in user mode we end up uselessly + regenerating the XML for every new thread. Once you get up to 100 + threads this starts exceeding the large maps done for QHT and PageDesc +Steps to reproduce: +See above command line, valgrind picks it up +Additional information: +See also #866, #967 diff --git a/results/classifier/118/arm/1154 b/results/classifier/118/arm/1154 new file mode 100644 index 000000000..a85028c09 --- /dev/null +++ b/results/classifier/118/arm/1154 @@ -0,0 +1,31 @@ +arm: 0.991 +device: 0.807 +network: 0.735 +architecture: 0.702 +performance: 0.617 +debug: 0.491 +register: 0.488 +risc-v: 0.429 +graphic: 0.405 +boot: 0.385 +vnc: 0.326 +TCG: 0.285 +VMM: 0.266 +files: 0.256 +hypervisor: 0.250 +semantic: 0.242 +PID: 0.202 +ppc: 0.192 +i386: 0.191 +KVM: 0.188 +assembly: 0.180 +mistranslation: 0.148 +kernel: 0.147 +x86: 0.145 +permissions: 0.116 +socket: 0.099 +peripherals: 0.099 +virtual: 0.037 +user-level: 0.029 + +arm: M-profile loads and stores done via helpers should enforce alignment restrictions diff --git a/results/classifier/118/arm/1204 b/results/classifier/118/arm/1204 new file mode 100644 index 000000000..78b944f8b --- /dev/null +++ b/results/classifier/118/arm/1204 @@ -0,0 +1,59 @@ +arm: 0.836 +architecture: 0.730 +device: 0.406 +graphic: 0.397 +kernel: 0.376 +semantic: 0.357 +network: 0.356 +socket: 0.345 +assembly: 0.330 +ppc: 0.322 +vnc: 0.306 +risc-v: 0.301 +performance: 0.295 +mistranslation: 0.284 +x86: 0.278 +PID: 0.251 +TCG: 0.227 +peripherals: 0.227 +debug: 0.208 +i386: 0.195 +hypervisor: 0.175 +VMM: 0.168 +permissions: 0.165 +boot: 0.147 +KVM: 0.125 +files: 0.113 +virtual: 0.107 +user-level: 0.096 +register: 0.077 + +AArch64 unaligned accesses are allowed by QEMU when SCTLR_EL3.A is 0, but SCTLR_EL3.M is also 0 +Description of problem: +As per the ARM ARM, when address translation is disabled and the access is not done from EL1/0 with HCR_EL2.DC set to 1, data accesses receive the 'Device-nGnRnE' memory attribute (D.8.2.10 The effects of disabling an address translation stage - DDi0487I.a, Page D8-5119). +Memory regions marked as Device do not support unaligned access. +Steps to reproduce: +Run the following snippet under EL3, and notice the last load instruction completes successfully (doesn't raise an alignment fault) +``` +.balign 8 +.global first_variable +first_variable: + .word 0x1 +.balign 4 +.global second_variable +second_variable: + .word 0x2 + +no_mmu_sctlr: .dword 0x0000000030C51834 + +.globl reproducer +reproducer: + ldr x1, no_mmu_sctlr // A=0,M=0 + msr sctlr_el3, x1 + dsb sy + isb + + ldr x0, =first_variable + ldr x1, [x0, #0] // Aligned - Success + ldr x1, [x0, #4] // Unaligned - Success??? (Should be failure) +``` diff --git a/results/classifier/118/arm/121 b/results/classifier/118/arm/121 new file mode 100644 index 000000000..84de3d54e --- /dev/null +++ b/results/classifier/118/arm/121 @@ -0,0 +1,31 @@ +arm: 0.902 +device: 0.779 +performance: 0.728 +debug: 0.662 +network: 0.621 +mistranslation: 0.564 +ppc: 0.531 +architecture: 0.460 +graphic: 0.417 +permissions: 0.414 +VMM: 0.364 +boot: 0.341 +socket: 0.285 +register: 0.282 +user-level: 0.260 +vnc: 0.217 +semantic: 0.201 +PID: 0.194 +TCG: 0.187 +peripherals: 0.175 +files: 0.152 +kernel: 0.132 +x86: 0.126 +hypervisor: 0.124 +risc-v: 0.071 +virtual: 0.060 +KVM: 0.024 +i386: 0.021 +assembly: 0.004 + +multiprocess program gets incorrect results with qemu arm-linux-user diff --git a/results/classifier/118/arm/1255 b/results/classifier/118/arm/1255 new file mode 100644 index 000000000..85762b310 --- /dev/null +++ b/results/classifier/118/arm/1255 @@ -0,0 +1,41 @@ +arm: 0.882 +graphic: 0.818 +device: 0.781 +performance: 0.694 +VMM: 0.686 +user-level: 0.540 +semantic: 0.495 +network: 0.482 +vnc: 0.435 +risc-v: 0.378 +architecture: 0.375 +socket: 0.366 +PID: 0.352 +debug: 0.348 +mistranslation: 0.340 +files: 0.330 +ppc: 0.304 +peripherals: 0.293 +register: 0.292 +TCG: 0.280 +virtual: 0.276 +hypervisor: 0.253 +permissions: 0.218 +boot: 0.190 +kernel: 0.190 +i386: 0.187 +KVM: 0.111 +x86: 0.097 +assembly: 0.097 + +32bit qemu-arm fails to run systemctl "Allocating guest commpage: Cannot allocate memory" +Description of problem: +I am using a bare minimal install of the latest 32 bit version of debian with only ssh installed. I have compiled qemu from the latest git with "./configure --target-list=arm-linux-user --static --disable-pie". When I try to run systemctl from the latest version of raspbian, I experience the error: "Allocating guest commpage: Cannot allocate memory". +Steps to reproduce: +1. Download and extract the included systemctl and required libs. [systemctl+libs.tgz](/uploads/a2834ed651a981fded4bcc19ea9ca31b/systemctl+libs.tgz) +2. run "qemu-arm -L ./ systemctl --version" +Additional information: +- I think this is related to [Issue 690](https://gitlab.com/qemu-project/qemu/-/issues/690). +- When I run "qemu-arm -L ./ -B 0x20000 systemctl --version" there is no error. +- The error still happens when setting vm.mmap_min_addr to 0. +- The error does not occur on v5.0.0, but does occur on v5.1.0 and v6.1.0. diff --git a/results/classifier/118/arm/1263 b/results/classifier/118/arm/1263 new file mode 100644 index 000000000..f78a50793 --- /dev/null +++ b/results/classifier/118/arm/1263 @@ -0,0 +1,31 @@ +arm: 0.918 +device: 0.900 +debug: 0.798 +performance: 0.791 +network: 0.748 +architecture: 0.620 +peripherals: 0.511 +vnc: 0.503 +risc-v: 0.497 +files: 0.476 +graphic: 0.460 +ppc: 0.369 +boot: 0.360 +VMM: 0.285 +mistranslation: 0.228 +register: 0.202 +TCG: 0.202 +user-level: 0.196 +semantic: 0.162 +hypervisor: 0.133 +kernel: 0.125 +permissions: 0.076 +socket: 0.074 +PID: 0.060 +KVM: 0.055 +virtual: 0.051 +i386: 0.044 +assembly: 0.018 +x86: 0.009 + +arm/imx EPIT timer interrupt does not fire properly on sabrelight diff --git a/results/classifier/118/arm/1304 b/results/classifier/118/arm/1304 new file mode 100644 index 000000000..6beecbdef --- /dev/null +++ b/results/classifier/118/arm/1304 @@ -0,0 +1,39 @@ +arm: 0.988 +performance: 0.904 +graphic: 0.891 +device: 0.887 +network: 0.747 +architecture: 0.634 +semantic: 0.608 +hypervisor: 0.593 +debug: 0.559 +permissions: 0.512 +socket: 0.479 +peripherals: 0.460 +mistranslation: 0.397 +kernel: 0.360 +assembly: 0.352 +register: 0.319 +user-level: 0.227 +virtual: 0.218 +vnc: 0.217 +KVM: 0.210 +files: 0.197 +x86: 0.182 +PID: 0.171 +boot: 0.165 +VMM: 0.153 +ppc: 0.146 +i386: 0.088 +TCG: 0.088 +risc-v: 0.034 + +loadvm for arm vexpress-a9 +Description of problem: + +Steps to reproduce: +1. savevm test +2. loadvm test +3. After I execute savevm and loadvm,the guest is not responding +Additional information: +I have read this issue(https://github.com/panda-re/panda/issues/643). If secure is set to off,the guest works well. But I need to use security extensions,so secure cannot be set to off.What do I need to do to solve this problem？ diff --git a/results/classifier/118/arm/1389 b/results/classifier/118/arm/1389 new file mode 100644 index 000000000..b168f6c5f --- /dev/null +++ b/results/classifier/118/arm/1389 @@ -0,0 +1,91 @@ +arm: 0.877 +debug: 0.873 +PID: 0.829 +permissions: 0.824 +i386: 0.807 +vnc: 0.785 +peripherals: 0.775 +x86: 0.750 +boot: 0.749 +ppc: 0.747 +risc-v: 0.745 +graphic: 0.732 +mistranslation: 0.701 +assembly: 0.679 +device: 0.675 +architecture: 0.667 +register: 0.660 +performance: 0.653 +VMM: 0.629 +hypervisor: 0.602 +socket: 0.602 +kernel: 0.596 +TCG: 0.589 +network: 0.588 +files: 0.546 +semantic: 0.515 +virtual: 0.488 +KVM: 0.447 +user-level: 0.428 + +Qemu 7.2.0 My hobbby bootloader seemed to stop working +Description of problem: +I wrote a BIOS bootloader and OS, but updated to QEMU 7.2.0 and now I get an exception in my bootloader. +Specifically I am getting a page fault on the first line of map_pd: +``` +next_pdpt: + ; PDPT + mov [0xa000 + rdx * 8], rax ; PDPT[rdx] -> PD + and al, 0xfc ;; clear bits 1 and 2 + + mov rcx, 0 +map_pd: + mov [rax + rcx * 8], rdi ; PD[rcx] -> rax + add rdi, 0x200000 ; maps first 512 * 0x200000 or 1 GiB + sub rsi, 1 + cmp rsi, 0 + je done_map_rest + + add rcx, 1 + cmp rcx, 512 + jb map_pd + + add rdx, 1 ; do next GiB + add rax, 0x1000 ; next PD + or rax, (1 | 2) + + jmp next_pdpt +``` +I am getting the exception: +``` +check_exception old: 0xffffffff new 0xe + 0: v=0e e=0002 i=0 cpl=0 IP=0008:0000000000001311 pc=0000000000001311 SP=0010:0000000000007bf8 CR2=000000000020c000 +RAX=000000000020c000 RBX=00000000000b8040 RCX=0000000000000000 RDX=0000000000000201 +RSI=000000000003fe00 RDI=0000008040000083 RBP=0000000000000008 RSP=0000000000007bf8 +R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 +R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=0000000000001311 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +CS =0008 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-] +SS =0010 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +DS =0010 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +FS =0010 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +GS =0010 0000000000000000 00000000 00009300 DPL=0 DS [-WA] +LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 0000000000001888 00000018 +IDT= 0000000090909000 00000000 +CR0=80000011 CR2=000000000020c000 CR3=0000000000009000 CR4=00000020 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +CCS=0000000000000200 CCD=0000000000000000 CCO=LOGICB +EFER=0000000000000500 +``` + +I am able to read the 0x20c000 address with gdb +Steps to reproduce: +1. clone and build https://github.com/darbysauter/myOS +2. run with `make run` on 7.0.0 +3. run with `make run` on 7.2.0 and there is an exception +Additional information: +I looked through the changelogs from 7.1 and 7.2 and nothing stood out to me. Not sure if some behaviour changed or some default changed. diff --git a/results/classifier/118/arm/1412 b/results/classifier/118/arm/1412 new file mode 100644 index 000000000..df4de3cf5 --- /dev/null +++ b/results/classifier/118/arm/1412 @@ -0,0 +1,35 @@ +arm: 0.919 +device: 0.794 +graphic: 0.745 +ppc: 0.700 +architecture: 0.667 +network: 0.666 +register: 0.630 +vnc: 0.606 +risc-v: 0.528 +socket: 0.527 +debug: 0.448 +PID: 0.420 +semantic: 0.404 +assembly: 0.397 +i386: 0.382 +VMM: 0.379 +TCG: 0.344 +x86: 0.336 +peripherals: 0.308 +kernel: 0.277 +boot: 0.260 +performance: 0.224 +hypervisor: 0.221 +permissions: 0.218 +mistranslation: 0.190 +files: 0.139 +user-level: 0.134 +virtual: 0.114 +KVM: 0.057 + +QEMU segfault (null pointer dereference) in sve_probe_page from ldff1* instructions +Description of problem: +After upgrading to QEMU v7.2.0 from v7.1.0, when executing any SVE ldff1* instructions with a faulting address, QEMU crashes due to a null pointer dereference at target/arm/sve_helper.c:5364 + +I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `full` is dereferenced before the `flags & TLB_INVALID_MASK` check at line 5369, and full is set to null by `probe_access_full` when `TLB_INVALID_MASK` is given. diff --git a/results/classifier/118/arm/1460523 b/results/classifier/118/arm/1460523 new file mode 100644 index 000000000..0e4fb82d6 --- /dev/null +++ b/results/classifier/118/arm/1460523 @@ -0,0 +1,43 @@ +arm: 0.831 +device: 0.795 +ppc: 0.778 +mistranslation: 0.745 +permissions: 0.732 +TCG: 0.686 +PID: 0.673 +performance: 0.651 +vnc: 0.629 +graphic: 0.603 +socket: 0.602 +network: 0.589 +architecture: 0.584 +register: 0.568 +files: 0.564 +semantic: 0.555 +debug: 0.467 +VMM: 0.447 +peripherals: 0.334 +KVM: 0.318 +risc-v: 0.311 +i386: 0.308 +virtual: 0.299 +kernel: 0.293 +hypervisor: 0.280 +boot: 0.276 +x86: 0.268 +assembly: 0.242 +user-level: 0.198 + +target-arm/op_helper.c:424: bad assert + +/home/dcb/qemu/trunk/qemu/target-arm/op_helper.c: In function ‘helper_access_check_cp_reg’: +/home/dcb/qemu/trunk/qemu/target-arm/op_helper.c:424:52: error: comparison of constant ‘3’ with boolean expression is always false [-Werror=bool-compare] + assert(!arm_is_secure(env) && !arm_current_el(env) == 3); + ^ + +Maybe + + assert(!arm_is_secure(env) && arm_current_el(env) != 3); + +Fixed by commit 3fc827d591679f3e262b9d1f8b34528eabfca8c0 + diff --git a/results/classifier/118/arm/1463338 b/results/classifier/118/arm/1463338 new file mode 100644 index 000000000..812d8b8b1 --- /dev/null +++ b/results/classifier/118/arm/1463338 @@ -0,0 +1,54 @@ +arm: 0.858 +register: 0.770 +mistranslation: 0.709 +user-level: 0.687 +performance: 0.654 +peripherals: 0.620 +architecture: 0.618 +device: 0.586 +graphic: 0.534 +permissions: 0.462 +network: 0.454 +ppc: 0.435 +semantic: 0.432 +socket: 0.386 +hypervisor: 0.357 +files: 0.320 +kernel: 0.311 +x86: 0.304 +i386: 0.284 +assembly: 0.284 +vnc: 0.280 +boot: 0.258 +PID: 0.252 +VMM: 0.227 +risc-v: 0.200 +debug: 0.164 +KVM: 0.153 +TCG: 0.144 +virtual: 0.127 + +qemu-system-arm injects #UND exception with wrong PC + +Usually all accesses to coprocessor registers are only possible in PL1 or higher. When accessing a coprocessor register in user mode, QEMU generates a trap and the PC of the trapping instruction is passed to the OS with an offset of+ 4. Some coprocessor registers can be configured to allow access to them in usermode (PL0). The latest qemu-git (ee09f84e6bf5383a23c9624115c26b72aa1e076c) seems to add an offest of 8 instead of four if such a register is accessed from user mode. This happens only if the coprocessors register that is accessed might also be accessed from PL0. In case all accesses to the coprocessor register from PL0 cause a trap, qemu injects the #UND trap with the correct PC value. + +Attached is a small test program that installs a signal handler for "SIGILL". On a pandaboard the progam prints "Val=0x2 Val2=0x2" whereas on the latest "qemu-system-arm" the output is : "Val=0x1 Val2=0x2" + +Qemu was configured with: "./configure --python=`which python2.7` --target-list=arm-softmmu" +The test can be compiled with: "gcc -g -static test2.c -o test2" + +If further information is needed, feel free to ask. + +Regards, + +Robert + + + +Thanks for the clear bug report and the test case. I've submitted a patch which fixes this: +http://patchwork.ozlabs.org/patch/482273/ + + +Should be in 2.6. + + diff --git a/results/classifier/118/arm/1495 b/results/classifier/118/arm/1495 new file mode 100644 index 000000000..9237ec821 --- /dev/null +++ b/results/classifier/118/arm/1495 @@ -0,0 +1,36 @@ +arm: 0.894 +graphic: 0.795 +architecture: 0.790 +device: 0.703 +TCG: 0.436 +semantic: 0.435 +mistranslation: 0.403 +PID: 0.391 +files: 0.390 +vnc: 0.251 +debug: 0.248 +ppc: 0.209 +boot: 0.174 +performance: 0.097 +register: 0.081 +user-level: 0.076 +risc-v: 0.057 +VMM: 0.037 +virtual: 0.031 +socket: 0.026 +permissions: 0.022 +network: 0.021 +peripherals: 0.018 +hypervisor: 0.017 +kernel: 0.017 +assembly: 0.010 +KVM: 0.005 +i386: 0.003 +x86: 0.002 + +MacOS fails check-unit for test-io-channel-command for some reason +Description of problem: +While adding the socat dependency to the CI system it triggers a failure on the ARM MacOS build, eg: https://gitlab.com/stsquad/qemu/-/jobs/3769189709 +Steps to reproduce: +1. install socat +2. make check-unit diff --git a/results/classifier/118/arm/1550503 b/results/classifier/118/arm/1550503 new file mode 100644 index 000000000..7fdc614eb --- /dev/null +++ b/results/classifier/118/arm/1550503 @@ -0,0 +1,73 @@ +arm: 0.930 +device: 0.755 +socket: 0.731 +ppc: 0.715 +PID: 0.706 +mistranslation: 0.705 +register: 0.655 +architecture: 0.640 +files: 0.605 +semantic: 0.591 +vnc: 0.573 +graphic: 0.554 +performance: 0.525 +network: 0.525 +risc-v: 0.502 +kernel: 0.489 +debug: 0.459 +boot: 0.457 +permissions: 0.434 +virtual: 0.426 +user-level: 0.422 +VMM: 0.377 +hypervisor: 0.369 +peripherals: 0.332 +TCG: 0.331 +x86: 0.327 +assembly: 0.314 +i386: 0.288 +KVM: 0.238 + +target-arm/helper.c:5493: bad test ? + +[qemu/target-arm/helper.c:5493]: (style) Expression '(X & 0x1f) != 0xf80f0000' is always true. + +Source code is + + (env->uncached_cpsr & CPSR_M) != CPSR_USER && + +but + +./qemu/target-arm/cpu.h:#define CPSR_M (0x1fU) + +./qemu/target-arm/cpu.h:#define CPSR_USER (CPSR_NZCV | CPSR_Q | CPSR_GE) + +On 26 February 2016 at 20:07, dcb <email address hidden> wrote: +> Public bug reported: +> +> [qemu/target-arm/helper.c:5493]: (style) Expression '(X & 0x1f) != +> 0xf80f0000' is always true. +> +> Source code is +> +> (env->uncached_cpsr & CPSR_M) != CPSR_USER && +> +> but +> +> ./qemu/target-arm/cpu.h:#define CPSR_M (0x1fU) +> +> ./qemu/target-arm/cpu.h:#define CPSR_USER (CPSR_NZCV | CPSR_Q | CPSR_GE) + +Yeah, that's a bug. Should be ARM_CPU_MODE_USR, not CPSR_USER. + +thanks +-- PMM + + +Should be fixed by http://patchwork.ozlabs.org/patch/590051/ + + +Fix should be part of QEMU v2.6.0: +http://git.qemu.org/?p=qemu.git;a=commit;h=8c4f0eb94cc65ee32a +... so I think this ticket can now be closed. + diff --git a/results/classifier/118/arm/1581695 b/results/classifier/118/arm/1581695 new file mode 100644 index 000000000..b0bbfaf87 --- /dev/null +++ b/results/classifier/118/arm/1581695 @@ -0,0 +1,52 @@ +arm: 0.829 +graphic: 0.771 +device: 0.756 +socket: 0.747 +network: 0.689 +semantic: 0.608 +PID: 0.551 +mistranslation: 0.474 +user-level: 0.434 +boot: 0.423 +performance: 0.346 +architecture: 0.309 +peripherals: 0.280 +virtual: 0.240 +debug: 0.226 +register: 0.217 +ppc: 0.196 +permissions: 0.189 +vnc: 0.114 +VMM: 0.040 +TCG: 0.039 +files: 0.033 +x86: 0.022 +hypervisor: 0.012 +kernel: 0.010 +risc-v: 0.010 +i386: 0.009 +assembly: 0.009 +KVM: 0.004 + +getifaddrs: Address family not supported by protocol + +Calling ip addr fails with the following error message: +Cannot open netlink socket: Address family not supported by protocol + + +My use case is running a docker raspberry pi arm container on Ubuntu 14.04 x64 with qemu-static. + +My steps to reproduce are the following: + +# docker pull philipz/rpi-raspbian:latest +# docker run -it --rm -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static philipz/rpi-raspbian bash +root@3b4ddc174279:/# ip addr +Cannot open netlink socket: Address family not supported by protocol + +A fix or an workaround would be awesome. + +note: we are also working with a embedded arm distro which has no package manager available, would be nice if the workaround would not depend on apt-get + +We got netlink sockets working for linux-user over the course of 2016, and "ip addr" now works for me with a 32-bit arm chroot. This should be fixed in QEMU 2.10. + + diff --git a/results/classifier/118/arm/1591 b/results/classifier/118/arm/1591 new file mode 100644 index 000000000..bdcc9b62a --- /dev/null +++ b/results/classifier/118/arm/1591 @@ -0,0 +1,31 @@ +arm: 0.934 +ppc: 0.829 +performance: 0.752 +device: 0.741 +architecture: 0.670 +network: 0.510 +graphic: 0.438 +peripherals: 0.326 +VMM: 0.224 +semantic: 0.203 +TCG: 0.199 +PID: 0.191 +boot: 0.162 +virtual: 0.125 +mistranslation: 0.120 +risc-v: 0.115 +user-level: 0.111 +hypervisor: 0.105 +files: 0.098 +vnc: 0.079 +register: 0.065 +permissions: 0.064 +assembly: 0.045 +debug: 0.044 +socket: 0.041 +kernel: 0.032 +KVM: 0.018 +x86: 0.009 +i386: 0.009 + +test-mmap (4096 byte pages) on arm fails on ppc64le host diff --git a/results/classifier/118/arm/1658506 b/results/classifier/118/arm/1658506 new file mode 100644 index 000000000..c415e040e --- /dev/null +++ b/results/classifier/118/arm/1658506 @@ -0,0 +1,48 @@ +arm: 0.906 +device: 0.718 +mistranslation: 0.654 +network: 0.641 +kernel: 0.615 +vnc: 0.580 +files: 0.573 +ppc: 0.533 +graphic: 0.487 +socket: 0.471 +x86: 0.434 +risc-v: 0.432 +i386: 0.383 +performance: 0.362 +architecture: 0.355 +assembly: 0.332 +hypervisor: 0.316 +semantic: 0.298 +boot: 0.293 +PID: 0.283 +TCG: 0.263 +VMM: 0.261 +peripherals: 0.257 +register: 0.238 +KVM: 0.221 +permissions: 0.165 +debug: 0.164 +virtual: 0.152 +user-level: 0.127 + +qemu/hw/intc/arm_gicv3_cpuif.c:2433: bad expression ? + +qemu/hw/intc/arm_gicv3_cpuif.c:2433]: (style) Expression '(X & 0x2000000000000000) == 0x1' is always false. + +Source code is + + ((lr & ICH_LR_EL2_HW) == 1 || (lr & ICH_LR_EL2_EOI) == 0)) { + +Maybe better code + + ((lr & ICH_LR_EL2_HW) != 0 || (lr & ICH_LR_EL2_EOI) == 0)) { + +Thanks for this bug report -- I have sent a patch making the proposed change: http://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg05030.html + + +Now fixed in git master, commit d87576e38df7. + + diff --git a/results/classifier/118/arm/1776486 b/results/classifier/118/arm/1776486 new file mode 100644 index 000000000..96c3e3453 --- /dev/null +++ b/results/classifier/118/arm/1776486 @@ -0,0 +1,44 @@ +arm: 0.898 +architecture: 0.741 +performance: 0.713 +device: 0.712 +KVM: 0.706 +boot: 0.654 +kernel: 0.650 +risc-v: 0.622 +hypervisor: 0.619 +graphic: 0.616 +vnc: 0.603 +PID: 0.592 +i386: 0.557 +semantic: 0.532 +register: 0.515 +VMM: 0.513 +mistranslation: 0.494 +x86: 0.482 +permissions: 0.481 +user-level: 0.479 +ppc: 0.476 +network: 0.443 +socket: 0.430 +TCG: 0.427 +debug: 0.420 +peripherals: 0.401 +files: 0.401 +virtual: 0.397 +assembly: 0.304 + +detect error when kernel and initrd images exceed ram size + +I was unable to figure out why my VM wasn't booting when I added a "-initrd" image. I would launch qemu and get no output, and no error message, it would just spin. + +Turns out my initrd image was around 270 MB but I wasn't giving an explicit ram size to qemu. I was told the default memory size was around 120 MB so this was definitely a problem. I think that the qemu "pseudo-bootloader" should detect when the kernel image and initrd image sizes exceed the size of ram and print a nice error to the user, something like: + +Error: the total size of the given boot images (342M) exceeds the size allocated for memory (120M) + +We could also do a better job of identifying when different things (initrd, kernel, dtb) overlap in memory. + + +As of the 4.1 release we should now do a better job of identifying overlaps between initrd, kernel, end of ram, etc, for the built-in arm bootloader. + + diff --git a/results/classifier/118/arm/1813460 b/results/classifier/118/arm/1813460 new file mode 100644 index 000000000..ea13293ea --- /dev/null +++ b/results/classifier/118/arm/1813460 @@ -0,0 +1,51 @@ +arm: 0.896 +device: 0.666 +semantic: 0.513 +graphic: 0.512 +performance: 0.508 +architecture: 0.501 +network: 0.445 +ppc: 0.413 +x86: 0.413 +i386: 0.410 +PID: 0.398 +files: 0.393 +socket: 0.363 +kernel: 0.353 +TCG: 0.334 +register: 0.289 +mistranslation: 0.275 +vnc: 0.267 +user-level: 0.264 +peripherals: 0.261 +hypervisor: 0.255 +debug: 0.242 +risc-v: 0.235 +boot: 0.233 +VMM: 0.231 +assembly: 0.224 +KVM: 0.214 +permissions: 0.196 +virtual: 0.193 + +qemu/target/arm/translate-a64.c:2039: bad test ? + +qemu/target/arm/translate-a64.c:2039]: (warning) Logical disjunction always evaluates to true: op3 != 2 || op3 != 3. + +Source code is + + if (op3 != 2 || op3 != 3) { + +Maybe better code + + if (op3 != 2 && op3 != 3) { + +Maybe using gcc flag -Wlogical-op might help find bugs like this in future. + +There is a patch on list for this: +https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06728.html + +Using the flag is a good idea. + +The patch is now in master. + diff --git a/results/classifier/118/arm/1836192 b/results/classifier/118/arm/1836192 new file mode 100644 index 000000000..b26ff5017 --- /dev/null +++ b/results/classifier/118/arm/1836192 @@ -0,0 +1,65 @@ +arm: 0.821 +ppc: 0.798 +device: 0.784 +architecture: 0.784 +debug: 0.773 +performance: 0.771 +files: 0.763 +user-level: 0.734 +PID: 0.734 +register: 0.704 +boot: 0.695 +semantic: 0.685 +network: 0.682 +risc-v: 0.678 +hypervisor: 0.651 +permissions: 0.651 +kernel: 0.641 +virtual: 0.639 +vnc: 0.638 +graphic: 0.634 +mistranslation: 0.614 +VMM: 0.614 +peripherals: 0.613 +TCG: 0.597 +socket: 0.593 +x86: 0.591 +assembly: 0.551 +KVM: 0.524 +i386: 0.518 + +Regressions on arm926 target with some GCC tests + +Hi, + +After trying qemu master: +commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde +Merge: 68d7ff0 14f5d87 +Author: Peter Maydell <email address hidden> +Date: Fri Jun 21 15:40:50 2019 +0100 + +even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, +I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite, with GCC configured to generate arm10tdmi code by default, and using qemu's --cpu arm926. + +I'm attaching a tarball containing one of the GCC tests (binaries), needed shared libs, and a short script to run the test. + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabi +--with-cpu arm10tdmi +--with-fpu vfp + +Thanks + + + +We didn't spot that armv5 CPUs don't have mvfr0, so now the vfp refactor is looking at mvfr0 fields to gate feature presence we need to initialize cpu->isar.mvfr0 specifically to a value that indicates the right thing even on the armv5 CPUs which don't have a guest-visible mvfr0. This specifically affects just arm926 and arm1026, which have accidentally lost short-vector support and double-precision support. + + +We didn't spot that armv5 CPUs don't have mvfr0, so now the vfp refactor is looking at mvfr0 fields to gate feature presence we need to initialize cpu->isar.mvfr0 specifically to a value that indicates the right thing even on the armv5 CPUs which don't have a guest-visible mvfr0. This specifically affects just arm926 and arm1026, which have accidentally lost short-vector support and double-precision support. + + +I confirm this patch fixes the problem I reported. Thanks! + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cb7cef8b32033f6284a47d797 + diff --git a/results/classifier/118/arm/1838475 b/results/classifier/118/arm/1838475 new file mode 100644 index 000000000..a86925dde --- /dev/null +++ b/results/classifier/118/arm/1838475 @@ -0,0 +1,65 @@ +arm: 0.954 +kernel: 0.840 +semantic: 0.780 +device: 0.738 +ppc: 0.719 +architecture: 0.705 +socket: 0.693 +performance: 0.686 +network: 0.620 +vnc: 0.608 +permissions: 0.603 +debug: 0.567 +peripherals: 0.545 +files: 0.544 +PID: 0.543 +graphic: 0.542 +register: 0.538 +user-level: 0.532 +boot: 0.517 +risc-v: 0.517 +TCG: 0.468 +mistranslation: 0.452 +x86: 0.429 +hypervisor: 0.423 +virtual: 0.421 +VMM: 0.416 +i386: 0.409 +KVM: 0.343 +assembly: 0.245 + +qemu-system-arm exits when cortex-m4 floating point used and irq occurs + +qemu-system-arm exits with + +"...Secure UsageFault with CFSR.NOCP because NSACR.CP10 prevents stacking FP regs +...taking pending nonsecure exception 3 +Taking exception 7 [Breakpoint] +qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)" + +when emulating Cortex-m4, executing at least 1 floating point instruction, and then an irq (e.g. sys tick) occurring. + +CPACR.CP10 and CPACR.CP11 are set to 0x3 respectively prior to executing the fp instructions. + +NOTE: NSACR does not appear to be a cortex m4 register. + +Attached is a simplified elf to repro the issue. + +The qemu command line is: "qemu-system-arm --gdb tcp::1234 -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel QemuExitWhenUsingFPAndIRQOccurs.elf -d int" + + + +I think this patch should fix this bug: + +https://<email address hidden>/ + + +I confirm that this fixes the issue above. + +Thank you for your help! It is much appreciated. + +Now fixed in git master; will be in the imminent 4.1 release. + + +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=02ac2f7f613b47f6a5b3 + diff --git a/results/classifier/118/arm/1849879 b/results/classifier/118/arm/1849879 new file mode 100644 index 000000000..0dbca9827 --- /dev/null +++ b/results/classifier/118/arm/1849879 @@ -0,0 +1,43 @@ +arm: 0.935 +mistranslation: 0.778 +device: 0.774 +graphic: 0.721 +semantic: 0.574 +architecture: 0.516 +vnc: 0.498 +performance: 0.480 +user-level: 0.351 +virtual: 0.349 +permissions: 0.334 +debug: 0.284 +boot: 0.267 +socket: 0.259 +i386: 0.243 +register: 0.233 +files: 0.213 +x86: 0.198 +assembly: 0.184 +network: 0.142 +kernel: 0.135 +peripherals: 0.126 +VMM: 0.056 +PID: 0.038 +KVM: 0.036 +ppc: 0.026 +hypervisor: 0.019 +TCG: 0.011 +risc-v: 0.006 + +qemu-arm should accept vmrs apsr_nzcv, fpscr on M-profile + +I've noticed that qemu-arm for cortex-M considers +vmrs apsr_nzcv, fpscr +as an illegal instruction. + +In this case, rt==15 means APSR, and the instruction should be accepted and executed like for A-profile. + +I posted a small patch: +https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg06978.html + +Fixed in 2529ab43b8a05534494704e803e0332d111d8b91, which is in 4.2. + diff --git a/results/classifier/118/arm/1870477 b/results/classifier/118/arm/1870477 new file mode 100644 index 000000000..013c30573 --- /dev/null +++ b/results/classifier/118/arm/1870477 @@ -0,0 +1,84 @@ +arm: 0.879 +graphic: 0.826 +performance: 0.763 +x86: 0.750 +device: 0.647 +architecture: 0.630 +semantic: 0.601 +user-level: 0.575 +network: 0.565 +PID: 0.559 +mistranslation: 0.547 +register: 0.541 +i386: 0.530 +files: 0.526 +hypervisor: 0.518 +permissions: 0.501 +socket: 0.486 +ppc: 0.484 +peripherals: 0.478 +kernel: 0.452 +vnc: 0.426 +risc-v: 0.417 +debug: 0.410 +TCG: 0.397 +VMM: 0.397 +boot: 0.391 +KVM: 0.323 +assembly: 0.317 +virtual: 0.288 + +qemu-arm hangs when golang running test + + +1. Environment: +Ubuntu 16.04.5 X86_64 +qemu-arm version 4.2.0 +go version go 1.14.1 linux/arm + +2. Summary: +Sometimes "go run test.go" command hang + + +3. Reproduction Method (Attempts: 500 Occurred: 1 ): Frequency: 1/500 + + +test.go +====================================== +package main +import "fmt" +func main(){ + for i:=0; i<1000; i++ { + fmt.Printf("[%d] Hello world\n", i) + } +} +====================================== + +i tested "go run test.go" command called 500 times at qemu arm env. +qemu hangs about 200~300. + +attached strace log. + +please check. +thanks + + + + + +Is this still reproducible with the latest version of QEMU? + +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 older bugs to "Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/118/arm/1876187 b/results/classifier/118/arm/1876187 new file mode 100644 index 000000000..91a8fe0af --- /dev/null +++ b/results/classifier/118/arm/1876187 @@ -0,0 +1,44 @@ +arm: 0.849 +network: 0.748 +performance: 0.734 +device: 0.719 +mistranslation: 0.680 +ppc: 0.676 +files: 0.657 +architecture: 0.642 +vnc: 0.622 +PID: 0.618 +socket: 0.582 +graphic: 0.568 +permissions: 0.542 +TCG: 0.534 +register: 0.521 +kernel: 0.479 +semantic: 0.451 +VMM: 0.441 +risc-v: 0.371 +boot: 0.336 +debug: 0.261 +peripherals: 0.240 +virtual: 0.213 +hypervisor: 0.162 +i386: 0.161 +user-level: 0.135 +x86: 0.125 +assembly: 0.104 +KVM: 0.047 + +qemu-system-arm freezes when using SystickTimer on netduinoplus2 + +git commit 27c94566379069fb8930bb1433dcffbf7df3203d + +The global variable system_clock_scale used in hw/timer/armv7m_systick.c is never set on the netduinoplus2 platform, it stays initialized as zero. Using the timer with the clock source as cpu clock leads to an infinit loop because systick_timer->tick always stays the same. + +To reproduce use to CMSIS function SysTick_Config(uint32_t ticks) to setup the timer. + +Patch sent to list: https://<email address hidden>/ + + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e7e5a9595ab1136845c + diff --git a/results/classifier/118/arm/1890 b/results/classifier/118/arm/1890 new file mode 100644 index 000000000..74fabc592 --- /dev/null +++ b/results/classifier/118/arm/1890 @@ -0,0 +1,55 @@ +arm: 0.874 +graphic: 0.770 +user-level: 0.770 +device: 0.752 +ppc: 0.724 +PID: 0.714 +files: 0.704 +debug: 0.696 +vnc: 0.695 +semantic: 0.672 +socket: 0.662 +permissions: 0.659 +performance: 0.644 +architecture: 0.615 +network: 0.580 +boot: 0.514 +risc-v: 0.504 +mistranslation: 0.504 +kernel: 0.474 +hypervisor: 0.471 +register: 0.469 +VMM: 0.450 +assembly: 0.438 +TCG: 0.371 +x86: 0.348 +i386: 0.318 +peripherals: 0.307 +KVM: 0.277 +virtual: 0.267 + +qemu-arm 8.1.0 Error mapping file: Operation not permitted +Description of problem: +failed to execute the cortex-m binary hello_world, and says: +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +Steps to reproduce: +1. +``` +cat > hello_new.c <<EOF +#include <stdio.h> +int main() +{printf("hello world"); return 0;} +EOF +``` +2. +``` +arm-none-eabi-gcc -mcpu=cortex-m55 -g hello_world.c -o hello_world -specs=rdimon.specs +``` +3. +``` +qemu-arm -cpu cortex-m55 hello_world +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +``` +Additional information: +1, version 8.0.4 version is okay\ +2, arm-none-eabi-gcc version is 10.3.1 20210824 (release) diff --git a/results/classifier/118/arm/1897 b/results/classifier/118/arm/1897 new file mode 100644 index 000000000..0b3a75038 --- /dev/null +++ b/results/classifier/118/arm/1897 @@ -0,0 +1,51 @@ +arm: 0.881 +performance: 0.865 +graphic: 0.769 +device: 0.744 +vnc: 0.613 +semantic: 0.595 +debug: 0.582 +register: 0.568 +user-level: 0.563 +kernel: 0.528 +socket: 0.510 +network: 0.503 +PID: 0.487 +ppc: 0.456 +permissions: 0.445 +boot: 0.441 +mistranslation: 0.433 +TCG: 0.421 +VMM: 0.420 +risc-v: 0.416 +peripherals: 0.415 +files: 0.407 +x86: 0.374 +architecture: 0.300 +i386: 0.286 +hypervisor: 0.273 +KVM: 0.246 +virtual: 0.191 +assembly: 0.165 + +npcm7xx_timer-test.c is unreliable +Description of problem: +Sometimes npcm7xx_timer-test fails intermittently: +https://gitlab.com/qemu-project/qemu/-/jobs/5121787250 + +``` +38/96 qemu:qtest+qtest-arm / qtest-arm/npcm7xx_timer-test ERROR 0.95s exit status 1 +>>> QTEST_QEMU_BINARY=./qemu-system-arm QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=103 /builds/qemu-project/qemu/build/tests/qtest/npcm7xx_timer-test --tap -k +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +** +ERROR:../tests/qtest/npcm7xx_timer-test.c:475:test_periodic_interrupt: assertion failed (tim_read(td, TISR) == tim_timer_bit(td)): (0x00000000 == 0x00000004) +** +ERROR:../tests/qtest/npcm7xx_timer-test.c:476:test_periodic_interrupt: 'qtest_get_irq(global_qtest, tim_timer_irq(td))' should be TRUE +(test program exited with status code 1) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` + +When I reran the CI job, it passed. + +Please investigate why this test is unreliable and fix it. Thanks! diff --git a/results/classifier/118/arm/1900779 b/results/classifier/118/arm/1900779 new file mode 100644 index 000000000..a11580137 --- /dev/null +++ b/results/classifier/118/arm/1900779 @@ -0,0 +1,85 @@ +arm: 0.839 +PID: 0.802 +TCG: 0.794 +permissions: 0.791 +socket: 0.790 +risc-v: 0.789 +hypervisor: 0.778 +peripherals: 0.778 +x86: 0.771 +kernel: 0.768 +ppc: 0.761 +debug: 0.752 +device: 0.740 +virtual: 0.735 +KVM: 0.729 +i386: 0.723 +register: 0.721 +files: 0.719 +network: 0.711 +vnc: 0.702 +VMM: 0.698 +assembly: 0.698 +graphic: 0.692 +boot: 0.691 +performance: 0.688 +user-level: 0.660 +architecture: 0.610 +mistranslation: 0.587 +semantic: 0.585 + +xp /16i on arm mixes DWords + +I was working with qemuand wanted to understag ATAG structure. +In Monitor mode I used xp /16i 0x100 and I got really confused. +with xp /16i 0x100: +At address 0x120 the DWords are 0x00000000, 0x00000004, 0x54410009, 0x74736574 +with xp /16x 0x100: +At address 0x120 the DWords are 0x54410001, 0x00000001, 0x00000001, 0x00000000 + +from my Terminal: + +(qemu) xp /16x 0x100 +0000000000000100: 0x00000005 0x54410001 0x00000001 0x00001000 +0000000000000110: 0x00000000 0x00000004 0x54410002 0x3c000000 +0000000000000120: 0x00000000 0x00000004 0x54410009 0x74736574 +0000000000000130: 0x00000000 0x00000000 0x00000000 0x00000000 +(qemu) xp /16i 0x100 +0x00000100: 00000005 andeq r0, r0, r5 +0x00000104: 54410001 strbpl r0, [r1], #-1 +0x00000108: 00000001 andeq r0, r0, r1 +0x0000010c: 00001000 andeq r1, r0, r0 +0x00000110: 00000000 andeq r0, r0, r0 +0x00000114: 00000004 andeq r0, r0, r4 +0x00000118: 54410002 strbpl r0, [r1], #-2 +0x0000011c: 3c000000 .byte 0x00, 0x00, 0x00, 0x3c +0x00000120: 54410001 strbpl r0, [r1], #-1 +0x00000124: 00000001 andeq r0, r0, r1 +0x00000128: 00001000 andeq r1, r0, r0 +0x0000012c: 00000000 andeq r0, r0, r0 +0x00000130: 00000004 andeq r0, r0, r4 +0x00000134: 54410002 strbpl r0, [r1], #-2 +0x00000138: 3c000000 .byte 0x00, 0x00, 0x00, 0x3c +0x0000013c: 00000000 andeq r0, r0, r0 +(increasing length only results in more 00000000 andeq r0, r0, r0 Lines) + +Version: +4.2.1Debian 1:4.2-3ubuntu6.6 +Commandline: +qemu-system-arm -machine raspi2 --nographic -S -s -kernel ./vmlinuz --append "test" +./vmlinuz is a x64 linux kernel. I didn't care about architecture because i just wanted to see ATAG structure. +I also tried +qemu-system-arm -machine raspi2 --nographic -S -s -kernel ./overview.pdf --append "test" +same result. + +I compiled Qemu 5.1.0 +Same Problem. + +Thanks for the bug report; I've just posted a patch which should fix it: https://<email address hidden>/ + +Staged: 437588d81d99ac91cb1e4ff060610458e67852d5 + +https://gitlab.com/qemu-project/qemu/-/commit/437588d81d99ac91cb1e4ff060610458e67852d5 + +Released with QEMU v5.2.0. + diff --git a/results/classifier/118/arm/1906463 b/results/classifier/118/arm/1906463 new file mode 100644 index 000000000..4da55b2d3 --- /dev/null +++ b/results/classifier/118/arm/1906463 @@ -0,0 +1,53 @@ +arm: 0.890 +device: 0.792 +semantic: 0.558 +ppc: 0.480 +graphic: 0.434 +performance: 0.423 +network: 0.413 +socket: 0.369 +vnc: 0.345 +PID: 0.316 +boot: 0.306 +virtual: 0.291 +architecture: 0.286 +peripherals: 0.281 +debug: 0.280 +kernel: 0.276 +register: 0.260 +mistranslation: 0.229 +assembly: 0.207 +i386: 0.205 +VMM: 0.197 +x86: 0.189 +user-level: 0.188 +risc-v: 0.179 +permissions: 0.174 +hypervisor: 0.171 +TCG: 0.131 +KVM: 0.117 +files: 0.062 + +"-device help" does not report all devices + +-device help doesn't report all devices. +E.g., devices that are instantiated by a board don't get printed in part because they don't exist when "-device help" is processed. As an experiment I deferred processing of "-device help" as long as possible and some devices were still not printed, so there's more going on here. + +QEMU commit hash: 944fdc5e27a5b5adbb765891e8e70e88ba9a00ec + +Repro: +$ configure --target-list=arm-softmmu +$ make +$ ./qemu-system-arm -device help | grep npcm7xx +<empty> + +I'd expect to see things like npcm7xx-rng in the output. + +I can imagine enumerating board-provided devices is a challenge. +Still, it'd be really nice if "-device help" printed them, and having +"-device $driver,help" work as well. + +This works as intended, see Markus' reply here: +https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg00337.html + + diff --git a/results/classifier/118/arm/1924669 b/results/classifier/118/arm/1924669 new file mode 100644 index 000000000..2b041ffcb --- /dev/null +++ b/results/classifier/118/arm/1924669 @@ -0,0 +1,45 @@ +arm: 0.923 +graphic: 0.830 +kernel: 0.728 +architecture: 0.583 +mistranslation: 0.569 +device: 0.568 +semantic: 0.542 +vnc: 0.489 +network: 0.455 +performance: 0.448 +i386: 0.367 +ppc: 0.365 +x86: 0.359 +peripherals: 0.314 +VMM: 0.292 +virtual: 0.281 +risc-v: 0.269 +PID: 0.266 +socket: 0.263 +permissions: 0.248 +debug: 0.236 +TCG: 0.219 +boot: 0.206 +user-level: 0.196 +hypervisor: 0.193 +register: 0.179 +KVM: 0.173 +assembly: 0.160 +files: 0.120 + +VFP code cannot see CPACR write in the same TB + +If FPU is enabled by writing to CPACR, and the code is in the same translation block as the following VFP code, qemu generates "v7M NOCP UsageFault". + +This can be reproduced with git HEAD (commit 8fe9f1f891eff4e37f82622b7480ee748bf4af74). + +The target binary is attached. The qemu command is: +qemu-system-arm -nographic -monitor null -serial null -semihosting -machine mps2-an505 -cpu cortex-m33 -kernel cpacr_vfp.elf -d in_asm,int,exec,cpu,cpu_reset,unimp,guest_errors,nochain -D log + +If the code is changed a little, so that they are not in the same block, VFP code can see the effect of CPACR, or -singlestep of qemu has the same result. + + + +Sorry, it's because a "ISB" is missing after CPACR is changed. Not bug of qemu. + diff --git a/results/classifier/118/arm/1960 b/results/classifier/118/arm/1960 new file mode 100644 index 000000000..341dc550b --- /dev/null +++ b/results/classifier/118/arm/1960 @@ -0,0 +1,52 @@ +arm: 0.990 +peripherals: 0.911 +device: 0.896 +hypervisor: 0.874 +virtual: 0.781 +ppc: 0.679 +graphic: 0.664 +files: 0.584 +kernel: 0.581 +VMM: 0.538 +architecture: 0.530 +network: 0.499 +risc-v: 0.490 +performance: 0.474 +socket: 0.457 +x86: 0.448 +PID: 0.393 +vnc: 0.356 +mistranslation: 0.344 +TCG: 0.341 +i386: 0.322 +semantic: 0.316 +register: 0.315 +boot: 0.289 +debug: 0.239 +permissions: 0.214 +assembly: 0.144 +KVM: 0.103 +user-level: 0.089 + +Invalid pmu interrupt id in arm virt machine device-tree +Description of problem: +commit 9036e917f8357f4e5965ebfecdab5964d40e6a40 changes the definition of PPI interrupt ID, but forgets to modify the PMU device tree. +The following patch can solve this problem： +``` +diff --git a/hw/arm/virt.c b/hw/arm/virt.c +index dd6bb80ce2..1d118974ee 100644 +--- a/hw/arm/virt.c ++++ b/hw/arm/virt.c +@@ -663,7 +663,7 @@ static void fdt_add_pmu_nodes(const VirtMachineState *vms) + qemu_fdt_setprop(ms->fdt, "/pmu", "compatible", + compat, sizeof(compat)); + qemu_fdt_setprop_cells(ms->fdt, "/pmu", "interrupts", +- GIC_FDT_IRQ_TYPE_PPI, VIRTUAL_PMU_IRQ, irqflags); ++ GIC_FDT_IRQ_TYPE_PPI, INTID_TO_PPI(VIRTUAL_PMU_IRQ), irqflags); + } + } +``` +Steps to reproduce: +NA +Additional information: + diff --git a/results/classifier/118/arm/1985 b/results/classifier/118/arm/1985 new file mode 100644 index 000000000..3f08ed102 --- /dev/null +++ b/results/classifier/118/arm/1985 @@ -0,0 +1,31 @@ +arm: 0.960 +files: 0.776 +device: 0.715 +performance: 0.641 +ppc: 0.640 +assembly: 0.635 +debug: 0.608 +architecture: 0.597 +graphic: 0.547 +network: 0.453 +VMM: 0.439 +vnc: 0.415 +register: 0.412 +PID: 0.391 +TCG: 0.361 +socket: 0.326 +boot: 0.252 +i386: 0.236 +semantic: 0.236 +risc-v: 0.164 +mistranslation: 0.116 +peripherals: 0.114 +KVM: 0.093 +kernel: 0.093 +hypervisor: 0.092 +virtual: 0.090 +x86: 0.066 +permissions: 0.059 +user-level: 0.047 + +Possible infinite loop in target/arm/sme_helper.c: helper_sme_fmopa_h diff --git a/results/classifier/118/arm/205 b/results/classifier/118/arm/205 new file mode 100644 index 000000000..00eff221a --- /dev/null +++ b/results/classifier/118/arm/205 @@ -0,0 +1,31 @@ +arm: 0.884 +device: 0.809 +graphic: 0.639 +performance: 0.616 +risc-v: 0.564 +permissions: 0.460 +network: 0.418 +VMM: 0.374 +debug: 0.355 +vnc: 0.354 +semantic: 0.349 +ppc: 0.320 +TCG: 0.319 +kernel: 0.318 +hypervisor: 0.289 +mistranslation: 0.279 +KVM: 0.271 +files: 0.271 +register: 0.267 +PID: 0.265 +boot: 0.249 +peripherals: 0.245 +i386: 0.192 +x86: 0.115 +architecture: 0.109 +user-level: 0.090 +virtual: 0.053 +socket: 0.051 +assembly: 0.041 + +Arrow keys press is double in some programs in Dos diff --git a/results/classifier/118/arm/247 b/results/classifier/118/arm/247 new file mode 100644 index 000000000..d2e8e499d --- /dev/null +++ b/results/classifier/118/arm/247 @@ -0,0 +1,31 @@ +arm: 0.950 +device: 0.783 +register: 0.608 +architecture: 0.538 +graphic: 0.450 +debug: 0.307 +i386: 0.234 +performance: 0.229 +peripherals: 0.172 +x86: 0.158 +semantic: 0.147 +assembly: 0.126 +mistranslation: 0.089 +virtual: 0.079 +boot: 0.040 +ppc: 0.037 +network: 0.035 +VMM: 0.033 +hypervisor: 0.030 +PID: 0.024 +user-level: 0.018 +permissions: 0.017 +socket: 0.016 +risc-v: 0.011 +kernel: 0.011 +TCG: 0.011 +files: 0.010 +vnc: 0.009 +KVM: 0.003 + +qemu-system-arm segmentation fault using pmemsave on the interrupt controller registers diff --git a/results/classifier/118/arm/2536 b/results/classifier/118/arm/2536 new file mode 100644 index 000000000..c2021184b --- /dev/null +++ b/results/classifier/118/arm/2536 @@ -0,0 +1,31 @@ +arm: 0.908 +device: 0.869 +performance: 0.675 +debug: 0.576 +architecture: 0.565 +graphic: 0.483 +mistranslation: 0.472 +x86: 0.145 +boot: 0.076 +semantic: 0.062 +i386: 0.056 +hypervisor: 0.050 +virtual: 0.044 +user-level: 0.037 +risc-v: 0.027 +assembly: 0.026 +permissions: 0.021 +VMM: 0.014 +ppc: 0.012 +vnc: 0.011 +network: 0.010 +peripherals: 0.005 +register: 0.005 +socket: 0.004 +files: 0.004 +TCG: 0.002 +PID: 0.002 +KVM: 0.002 +kernel: 0.001 + +Dynamic translation issue of arm instruction VFNMA and VFNMS diff --git a/results/classifier/118/arm/2542 b/results/classifier/118/arm/2542 new file mode 100644 index 000000000..8b01ffcf2 --- /dev/null +++ b/results/classifier/118/arm/2542 @@ -0,0 +1,31 @@ +arm: 0.974 +device: 0.893 +graphic: 0.848 +debug: 0.410 +performance: 0.220 +vnc: 0.084 +ppc: 0.059 +register: 0.056 +mistranslation: 0.050 +i386: 0.045 +boot: 0.044 +virtual: 0.035 +semantic: 0.030 +PID: 0.028 +architecture: 0.022 +assembly: 0.018 +files: 0.016 +VMM: 0.014 +TCG: 0.013 +x86: 0.008 +network: 0.007 +socket: 0.007 +permissions: 0.005 +risc-v: 0.004 +kernel: 0.004 +peripherals: 0.003 +hypervisor: 0.003 +user-level: 0.003 +KVM: 0.001 + +qemu-system-arm failure with picolibc tests since 59754f85ed35cbd5f4bf2663ca2136c78d5b2413 diff --git a/results/classifier/118/arm/2665 b/results/classifier/118/arm/2665 new file mode 100644 index 000000000..6194005ca --- /dev/null +++ b/results/classifier/118/arm/2665 @@ -0,0 +1,41 @@ +arm: 0.884 +device: 0.821 +hypervisor: 0.771 +architecture: 0.758 +graphic: 0.749 +boot: 0.642 +semantic: 0.639 +mistranslation: 0.622 +performance: 0.543 +i386: 0.426 +vnc: 0.407 +debug: 0.392 +VMM: 0.364 +ppc: 0.364 +PID: 0.362 +files: 0.341 +register: 0.329 +user-level: 0.327 +virtual: 0.320 +x86: 0.311 +socket: 0.309 +network: 0.307 +peripherals: 0.272 +permissions: 0.231 +risc-v: 0.222 +assembly: 0.220 +KVM: 0.219 +kernel: 0.207 +TCG: 0.142 + +target/arm: cannot boot when CPU supports SME +Description of problem: +On macOS 15.2 beta, Apple's Hypervisor.framework exposes the SME feat flag to QEMU. As a result, in `arm_cpu_sme_finalize`, `cpu_isar_feature(aa64_sme, cpu)` returns true and the program will always exit with the following: + +``` +qemu-aarch64-softmmu: cannot disable sme4224 +All SME vector lengths are disabled. +With SME enabled, at least one vector length must be enabled. +``` + +This is because `vq_supported` and `vq_init` are both 0 as they are not initialized anywhere. It seems that in the original commit e74c097638d38b46d9c68f11565432034afc0ad0 the only place `cpu->sme_vq.supported` is initialized is with `aarch64_max_initfn` when KVM and HVF are not used as the backend. diff --git a/results/classifier/118/arm/2697 b/results/classifier/118/arm/2697 new file mode 100644 index 000000000..c194f2cad --- /dev/null +++ b/results/classifier/118/arm/2697 @@ -0,0 +1,31 @@ +arm: 0.949 +device: 0.882 +architecture: 0.764 +debug: 0.762 +peripherals: 0.711 +performance: 0.697 +permissions: 0.678 +ppc: 0.465 +semantic: 0.438 +graphic: 0.420 +mistranslation: 0.339 +hypervisor: 0.339 +register: 0.329 +VMM: 0.290 +risc-v: 0.237 +x86: 0.233 +PID: 0.200 +boot: 0.200 +virtual: 0.177 +socket: 0.166 +vnc: 0.159 +network: 0.149 +TCG: 0.128 +files: 0.087 +assembly: 0.056 +user-level: 0.047 +KVM: 0.034 +kernel: 0.033 +i386: 0.017 + +system/physmem: gdb memory rw no access on armv7m MPU diff --git a/results/classifier/118/arm/2850 b/results/classifier/118/arm/2850 new file mode 100644 index 000000000..596c9867e --- /dev/null +++ b/results/classifier/118/arm/2850 @@ -0,0 +1,33 @@ +arm: 0.968 +device: 0.878 +mistranslation: 0.696 +architecture: 0.652 +semantic: 0.640 +performance: 0.541 +graphic: 0.452 +ppc: 0.451 +register: 0.442 +permissions: 0.433 +peripherals: 0.430 +VMM: 0.392 +risc-v: 0.388 +KVM: 0.370 +assembly: 0.362 +network: 0.339 +boot: 0.321 +hypervisor: 0.268 +socket: 0.265 +PID: 0.251 +TCG: 0.250 +debug: 0.237 +user-level: 0.196 +vnc: 0.193 +kernel: 0.179 +files: 0.135 +x86: 0.118 +virtual: 0.093 +i386: 0.065 + +Available in a version for Windows on arm +Additional information: + diff --git a/results/classifier/118/arm/381 b/results/classifier/118/arm/381 new file mode 100644 index 000000000..b0bc1bd82 --- /dev/null +++ b/results/classifier/118/arm/381 @@ -0,0 +1,31 @@ +arm: 0.934 +mistranslation: 0.762 +device: 0.709 +graphic: 0.505 +performance: 0.479 +vnc: 0.440 +semantic: 0.427 +ppc: 0.415 +architecture: 0.410 +TCG: 0.381 +VMM: 0.379 +peripherals: 0.373 +network: 0.333 +permissions: 0.314 +files: 0.301 +PID: 0.295 +register: 0.280 +debug: 0.252 +socket: 0.242 +hypervisor: 0.234 +assembly: 0.202 +KVM: 0.198 +boot: 0.153 +virtual: 0.148 +risc-v: 0.132 +user-level: 0.120 +kernel: 0.099 +x86: 0.030 +i386: 0.015 + +ERROR:target/arm/translate-a64.c:13229:disas_simd_two_reg_misc_fp16: code should not be reached diff --git a/results/classifier/118/arm/467 b/results/classifier/118/arm/467 new file mode 100644 index 000000000..e54c12da6 --- /dev/null +++ b/results/classifier/118/arm/467 @@ -0,0 +1,31 @@ +arm: 0.919 +device: 0.843 +network: 0.810 +architecture: 0.683 +debug: 0.665 +performance: 0.581 +VMM: 0.489 +PID: 0.454 +socket: 0.440 +graphic: 0.428 +risc-v: 0.395 +vnc: 0.390 +kernel: 0.387 +hypervisor: 0.386 +mistranslation: 0.369 +ppc: 0.364 +files: 0.342 +TCG: 0.304 +peripherals: 0.284 +boot: 0.208 +semantic: 0.187 +register: 0.180 +permissions: 0.139 +KVM: 0.134 +user-level: 0.119 +virtual: 0.097 +i386: 0.094 +assembly: 0.064 +x86: 0.021 + +savevm/loadvm/migration broken for 32-bit arm guests that use TrustZone diff --git a/results/classifier/118/arm/61 b/results/classifier/118/arm/61 new file mode 100644 index 000000000..4c38521e2 --- /dev/null +++ b/results/classifier/118/arm/61 @@ -0,0 +1,31 @@ +arm: 0.949 +device: 0.916 +performance: 0.791 +network: 0.641 +graphic: 0.549 +debug: 0.532 +architecture: 0.483 +semantic: 0.276 +VMM: 0.266 +ppc: 0.250 +register: 0.201 +vnc: 0.194 +mistranslation: 0.190 +hypervisor: 0.188 +boot: 0.176 +peripherals: 0.108 +assembly: 0.106 +risc-v: 0.097 +socket: 0.095 +i386: 0.089 +user-level: 0.070 +TCG: 0.062 +virtual: 0.059 +kernel: 0.055 +files: 0.043 +permissions: 0.032 +x86: 0.023 +PID: 0.023 +KVM: 0.007 + +qemu-system-arm segfaults while servicing SYS_HEAPINFO diff --git a/results/classifier/118/arm/633 b/results/classifier/118/arm/633 new file mode 100644 index 000000000..9ff3230c0 --- /dev/null +++ b/results/classifier/118/arm/633 @@ -0,0 +1,62 @@ +arm: 0.901 +device: 0.874 +PID: 0.839 +debug: 0.806 +i386: 0.784 +permissions: 0.765 +x86: 0.746 +ppc: 0.740 +graphic: 0.704 +performance: 0.688 +kernel: 0.670 +socket: 0.657 +assembly: 0.625 +semantic: 0.620 +VMM: 0.615 +risc-v: 0.556 +KVM: 0.545 +boot: 0.525 +network: 0.520 +user-level: 0.519 +architecture: 0.505 +vnc: 0.488 +hypervisor: 0.451 +TCG: 0.445 +mistranslation: 0.443 +register: 0.442 +virtual: 0.431 +files: 0.396 +peripherals: 0.364 + +i686-arm-user-static - Allocating guest commpage: Operation not permitted +Steps to reproduce: +1. Run the test case linked earlier. +2. You'll see `apt update` failing: + +``` +Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB] +Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] +Err:1 http://archive.raspberrypi.org/debian buster InRelease + At least one invalid signature was encountered. +Err:2 http://raspbian.raspberrypi.org/raspbian buster InRelease + At least one invalid signature was encountered. +Reading package lists... Done +W: GPG error: http://archive.raspberrypi.org/debian buster InRelease: At least one invalid signature was encountered. +E: The repository 'http://archive.raspberrypi.org/debian buster InRelease' is not signed. +N: Updating from such a repository can't be done securely, and is therefore disabled by default. +N: See apt-secure(8) manpage for repository creation and user configuration details. +W: GPG error: http://raspbian.raspberrypi.org/raspbian buster InRelease: At least one invalid signature was encountered. +E: The repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' is not signed. +N: Updating from such a repository can't be done securely, and is therefore disabled by default. +N: See apt-secure(8) manpage for repository creation and user configuration details. +``` +Additional information: +Setting `sysctl vm.mmap_min_addr=53248` makes it work (as opposed to the system default of 65536). + +Bisecting the bug linked earlier also breaks this in a slightly different way. Everything works at 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1. After that, apt update appears to work, but the package lists end up empty, so nothing can be installed. Then after 975ac4559c4c00010e05f7a3e782eeb9497837ea, the output is as provided above. + +apt launches /usr/lib/apt/methods/gpgv and passes it some commands through stdin. gpgv launches /usr/bin/apt-key, which fails with `Allocating guest commpage: Operation not permitted`. Running gpgv directly and sending the same commands works without any issues. The problem only occurs when gpgv is run through apt. (I don't meant the normal system gpgv binary, but the transport method binary that comes with apt) + +Getting any output is tricky because by the time apt-key is launched, gpgv redirects stdout and stderr to /dev/null and communication takes place through fd 3. https://salsa.debian.org/apt-team/apt/-/blob/2.2.4/apt-pkg/contrib/gpgv.cc#L355 https://salsa.debian.org/apt-team/apt/-/blob/main/methods/gpgv.cc#L186 + +I had to do some ugly things with different versions of qemu and wrapper scripts to see the commpage error, but hopefully there's enough information provided here that it won't be necessary. diff --git a/results/classifier/118/arm/656 b/results/classifier/118/arm/656 new file mode 100644 index 000000000..89c88eb7a --- /dev/null +++ b/results/classifier/118/arm/656 @@ -0,0 +1,37 @@ +arm: 0.893 +graphic: 0.861 +device: 0.857 +files: 0.783 +network: 0.758 +architecture: 0.688 +semantic: 0.682 +vnc: 0.619 +boot: 0.619 +ppc: 0.613 +permissions: 0.601 +TCG: 0.508 +PID: 0.452 +performance: 0.436 +socket: 0.397 +mistranslation: 0.395 +VMM: 0.392 +peripherals: 0.381 +register: 0.377 +debug: 0.324 +risc-v: 0.323 +kernel: 0.305 +i386: 0.256 +user-level: 0.249 +virtual: 0.203 +hypervisor: 0.177 +x86: 0.172 +assembly: 0.076 +KVM: 0.030 + +qemu-system-arm sabrelite does not use sd card +Description of problem: +I have build qemu from source. Furthermore I build Uboot from source following [this Link](https://qemu.readthedocs.io/en/latest/system/arm/sabrelite.html). With the provided command lines I am able to create and image and start the sabrelite board and see Uboot console Output. The problem I am facing is, that I am not able to interact with the provided tmp.img. + +I was also using the -driver option instead of the -blockdev option, but did not get any different results with that. +Additional information: +I provide the console output in the attached file. [console.out](/uploads/996b8c07310ec3b008477e3e70a2e629/console.out) diff --git a/results/classifier/118/arm/725 b/results/classifier/118/arm/725 new file mode 100644 index 000000000..e6f612597 --- /dev/null +++ b/results/classifier/118/arm/725 @@ -0,0 +1,44 @@ +arm: 0.949 +graphic: 0.907 +device: 0.855 +network: 0.705 +kernel: 0.697 +files: 0.673 +socket: 0.661 +semantic: 0.561 +vnc: 0.560 +performance: 0.532 +register: 0.484 +debug: 0.458 +ppc: 0.421 +boot: 0.417 +risc-v: 0.388 +TCG: 0.384 +permissions: 0.356 +PID: 0.354 +architecture: 0.303 +mistranslation: 0.233 +i386: 0.225 +hypervisor: 0.211 +peripherals: 0.189 +assembly: 0.163 +VMM: 0.161 +x86: 0.152 +virtual: 0.149 +user-level: 0.137 +KVM: 0.135 + +GICv3 ITS CTLR[Enabled] bit can not be cleared +Description of problem: +ITS CTLR[Enabled] can not be cleared, + + `s->ctlr |= (value & ~(s->ctlr));` + +Link: +https://gitlab.com/qemu-project/qemu/-/blob/master/hw/intc/arm_gicv3_its.c#L899 +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/118/arm/803 b/results/classifier/118/arm/803 new file mode 100644 index 000000000..bfa4bf212 --- /dev/null +++ b/results/classifier/118/arm/803 @@ -0,0 +1,50 @@ +arm: 0.850 +graphic: 0.839 +vnc: 0.780 +device: 0.680 +peripherals: 0.631 +network: 0.584 +performance: 0.550 +architecture: 0.538 +x86: 0.524 +semantic: 0.515 +virtual: 0.426 +ppc: 0.349 +hypervisor: 0.341 +permissions: 0.340 +files: 0.315 +debug: 0.308 +PID: 0.299 +i386: 0.278 +mistranslation: 0.244 +VMM: 0.238 +register: 0.236 +socket: 0.192 +user-level: 0.163 +TCG: 0.149 +assembly: 0.132 +boot: 0.131 +risc-v: 0.079 +KVM: 0.079 +kernel: 0.060 + +v6.2.0 armv7m: savevm fails assertion +Description of problem: +Trying to take a snapshot on some arm machines just fails an assertion, while some work fine. +e.g. mps2-an385 and stm32vldiscovery don't work, while e.g. raspi0 does. +``` +$ build/qemu-system-arm -machine mps2-an385 -monitor stdio -drive file=dummy.qcow2 -S +QEMU 6.1.50 monitor - type 'help' for more information +(qemu) VNC server running on ::1:5900 +savevm test +qemu-system-arm: ../migration/vmstate.c:363: vmstate_save_state_v: Assertion `first_elem || !n_elems || !size' failed. +[1] 631940 IOT instruction (core dumped) build/qemu-system-arm -machine mps2-an385 -monitor stdio -drive -S +``` +This happens with or without a kernel (so -S is optional, if a kernel is present). +Steps to reproduce: +1. Create some image for snapshots (once): ``qemu-img create -f qcow2 dummy.qcow2 32M`` +2. ``qemu-system-arm -machine mps2-an385 -monitor stdio -drive file=dummy.qcow2 -S`` +3. In monitor: ``savevm something`` +Additional information: +Bisect indicates the Problem first presented itself in commit d5093d961585f02126191951ded9b90dbc52883b by @pm215. +This led me to test stm32vldiscovery, which also includes armv7m.h and fails, while some others don't. |