diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/247 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2470 | 46 | ||||
| -rw-r--r-- | results/classifier/108/other/2471 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2472 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2473 | 18 | ||||
| -rw-r--r-- | results/classifier/108/other/2474 | 111 | ||||
| -rw-r--r-- | results/classifier/108/other/2475 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2476 | 67 | ||||
| -rw-r--r-- | results/classifier/108/other/2477 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/2478 | 33 | ||||
| -rw-r--r-- | results/classifier/108/other/2479 | 45 |
11 files changed, 400 insertions, 0 deletions
diff --git a/results/classifier/108/other/247 b/results/classifier/108/other/247 new file mode 100644 index 000000000..a1709d1d3 --- /dev/null +++ b/results/classifier/108/other/247 @@ -0,0 +1,16 @@ +device: 0.783 +graphic: 0.450 +debug: 0.307 +performance: 0.229 +semantic: 0.147 +boot: 0.040 +network: 0.035 +other: 0.025 +PID: 0.024 +permissions: 0.017 +socket: 0.016 +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/108/other/2470 b/results/classifier/108/other/2470 new file mode 100644 index 000000000..b60c91c2d --- /dev/null +++ b/results/classifier/108/other/2470 @@ -0,0 +1,46 @@ +graphic: 0.898 +boot: 0.829 +device: 0.812 +socket: 0.712 +other: 0.623 +semantic: 0.614 +performance: 0.600 +permissions: 0.578 +PID: 0.566 +vnc: 0.495 +network: 0.494 +files: 0.490 +debug: 0.405 +KVM: 0.341 + +qemu-system-mipsel regression, Linux generated with Buildroot does not boot anymore +Description of problem: +Buildroot Toolchain Builders try to release a new version. See a message from Thomas Petazzoni with the remaining issues: +https://lore.kernel.org/buildroot/20240730223542.273693e5@windsurf/T/#u + +All toolchains generate a system that fails to boot: + +Run /sbin/init as init process +process '/bin/busybox' started with executable stack +Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 + +The interesting thing is that those images boot fine with Qemu v8.2.6, +but they fail to boot with Qemu v9.0.2. + +I tracked it down to this commit: +commit 4e999bf4197ae3dc58b7092260f98146920a7469 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Sun Jan 28 15:58:52 2024 +1000 + + target/mips: Pass ptw_mmu_idx down from mips_cpu_tlb_fill + + Rather than adjust env->hflags so that the value computed + by cpu_mmu_index() changes, compute the mmu_idx that we + want directly and pass it down. + + Introduce symbolic constants for MMU_{KERNEL,ERL}_IDX. + + Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + +Unfortunately just reverting this commit in 9.0.2 does not help, Qemu segfaults on Linux Kernel boot then. diff --git a/results/classifier/108/other/2471 b/results/classifier/108/other/2471 new file mode 100644 index 000000000..f813c9dda --- /dev/null +++ b/results/classifier/108/other/2471 @@ -0,0 +1,16 @@ +device: 0.854 +network: 0.701 +debug: 0.537 +graphic: 0.446 +performance: 0.360 +boot: 0.232 +vnc: 0.199 +socket: 0.192 +semantic: 0.181 +permissions: 0.179 +PID: 0.129 +other: 0.077 +KVM: 0.060 +files: 0.055 + +error handling in of_dpa_cmd_add_acl() diff --git a/results/classifier/108/other/2472 b/results/classifier/108/other/2472 new file mode 100644 index 000000000..f99fb1c2c --- /dev/null +++ b/results/classifier/108/other/2472 @@ -0,0 +1,16 @@ +performance: 0.895 +device: 0.870 +network: 0.765 +vnc: 0.625 +boot: 0.473 +files: 0.444 +PID: 0.435 +socket: 0.324 +permissions: 0.311 +KVM: 0.301 +semantic: 0.258 +graphic: 0.255 +debug: 0.063 +other: 0.055 + +optimize nvme_directive_receive() function diff --git a/results/classifier/108/other/2473 b/results/classifier/108/other/2473 new file mode 100644 index 000000000..fda2a835e --- /dev/null +++ b/results/classifier/108/other/2473 @@ -0,0 +1,18 @@ +device: 0.820 +performance: 0.644 +network: 0.509 +debug: 0.346 +boot: 0.304 +socket: 0.219 +vnc: 0.190 +semantic: 0.172 +PID: 0.145 +graphic: 0.113 +other: 0.102 +files: 0.102 +permissions: 0.064 +KVM: 0.026 + +qemu-system-aarch64: Stop execution on unhandled exceptions +Additional information: + diff --git a/results/classifier/108/other/2474 b/results/classifier/108/other/2474 new file mode 100644 index 000000000..5055d0109 --- /dev/null +++ b/results/classifier/108/other/2474 @@ -0,0 +1,111 @@ +other: 0.821 +device: 0.748 +permissions: 0.748 +debug: 0.747 +performance: 0.743 +vnc: 0.726 +semantic: 0.717 +socket: 0.696 +KVM: 0.695 +PID: 0.686 +graphic: 0.685 +boot: 0.676 +files: 0.665 +network: 0.617 + +x86_64: strange translation of "vpgatherqq" +Description of problem: +The translate of instruction "vpgatherqq" is confusing. + +It happens when register xmm4 is in the middle, like "vpgatherqq %xmmi,0x0(,%xmm4,1),%xmmj". +Steps to reproduce: +1. Make a simple embedded assembly code named test.c: +``` +int main() +{ + asm("vpgatherqq %xmm6,0x123(,%xmm2,4),%xmm7"); + asm("vpgatherqq %xmm6,0x123(,%xmm3,4),%xmm7"); + asm("vpgatherqq %xmm6,0x123(,%xmm4,4),%xmm7"); + asm("vpgatherqq %xmm6,0x123(,%xmm5,4),%xmm7"); + return 0; +} +``` +and compile it: +``` +gcc -o test test.c -static +``` + +2. Run it with QEMU, print the micro ops: +``` +qemu-x86_64 -d op -D a.out test +``` +We can get output like this (only contain vpgatherqq): +``` + ---- 000000000040174d 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc14,env,$0x3d0 #This is xmm2 + add_i64 loc16,env,$0x4d0 + add_i64 loc18,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc18,loc16,loc14,loc2,$0x2 + mov_vec v128,e8,tmp20,v128$0x0 + st_vec v128,e8,tmp20,env,$0x4e0 + mov_vec v128,e8,tmp22,v128$0x0 + st_vec v128,e8,tmp22,env,$0x520 + + ---- 0000000000401757 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc23,env,$0x410 #This is xmm3 + add_i64 loc25,env,$0x4d0 + add_i64 loc26,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc26,loc25,loc23,loc2,$0x2 + mov_vec v128,e8,tmp27,v128$0x0 + st_vec v128,e8,tmp27,env,$0x4e0 + mov_vec v128,e8,tmp28,v128$0x0 + st_vec v128,e8,tmp28,env,$0x520 + + ---- 0000000000401761 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc29,env,$0x310 #This is xmm4 ??? + add_i64 loc31,env,$0x4d0 + add_i64 loc32,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc32,loc31,loc29,loc2,$0x2 + mov_vec v128,e8,tmp33,v128$0x0 + st_vec v128,e8,tmp33,env,$0x4e0 + mov_vec v128,e8,tmp34,v128$0x0 + st_vec v128,e8,tmp34,env,$0x520 + + ---- 000000000040176b 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc35,env,$0x490 #This is xmm5 + add_i64 loc37,env,$0x4d0 + add_i64 loc38,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc38,loc37,loc35,loc2,$0x2 + mov_vec v128,e8,tmp39,v128$0x0 + st_vec v128,e8,tmp39,env,$0x4e0 + mov_vec v128,e8,tmp40,v128$0x0 + st_vec v128,e8,tmp40,env,$0x520 +``` +3. + +Since the register xmms are continuous within the structure CPUArchState, the offset of xmm2, xmm3, xmm4, xmm5 should be a arithmetic sequence. + +From the output, we can infer that the common difference should be 0x40 and the offset of xmm4 should be 0x450 but not 0x310. + +I used GDB to track it, the location where the change occurred is: + +target/i386/tcg/translate.c, gen_lea_modrm_0(), line 2215: +``` + if (rm == 4) { + int code = x86_ldub_code(env, s); + scale = (code >> 6) & 3; + index = ((code >> 3) & 7) | REX_X(s); + if (index == 4) { + index = -1; /* no index */ + } + base = (code & 7) | REX_B(s); + havesib = 1; + } +``` +This code turned 4 into -1, and -1 do explain the offset 0x310 (xmm0 has offset 0x350). +Additional information: +Monitoring the function "helper_vpgatherqq_xmm" can draw similar conclusions: it used wrong value but not xmm4. diff --git a/results/classifier/108/other/2475 b/results/classifier/108/other/2475 new file mode 100644 index 000000000..828a9f7ec --- /dev/null +++ b/results/classifier/108/other/2475 @@ -0,0 +1,16 @@ +device: 0.828 +performance: 0.660 +network: 0.619 +debug: 0.519 +graphic: 0.439 +boot: 0.368 +semantic: 0.349 +vnc: 0.197 +other: 0.149 +KVM: 0.148 +socket: 0.137 +PID: 0.031 +files: 0.029 +permissions: 0.019 + +Inconsistency between cpu_tb_exec() and qemu_plugin_register_vcpu_tb_exec_cb()? diff --git a/results/classifier/108/other/2476 b/results/classifier/108/other/2476 new file mode 100644 index 000000000..aa2fbc379 --- /dev/null +++ b/results/classifier/108/other/2476 @@ -0,0 +1,67 @@ +graphic: 0.722 +permissions: 0.719 +files: 0.692 +debug: 0.660 +PID: 0.640 +semantic: 0.639 +boot: 0.603 +device: 0.592 +network: 0.586 +socket: 0.561 +other: 0.549 +vnc: 0.521 +performance: 0.491 +KVM: 0.431 + +Regression 9.1.0-rc0: Msys2/Clang64 build fails +Description of problem: +Building QEMU in Msys2/Clang64 environment now fails. It is possible with 8.2.0 and 9.0.0 if option "--disable-plugins" is used. + +I suppose this option is broken now: + +``` +[2207/2362] Linking target qemu-system-aarch64.exe +FAILED: qemu-system-aarch64.exe +"cc" "-m64" @qemu-system-aarch64.exe.rsp +lld: error: unknown argument: --dynamic-list=D:/msys64plain/home/Normalo/qemu-9.1.0-rc0/plugins/qemu-plugins.symbols + + +cc: error: linker command failed with exit code 1 (use -v to see invocation) + + +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:167: run-ninja] Error 1 +make[1]: Leaving directory '/home/Normalo/qemu-9.1.0-rc0/build' +make: *** [GNUmakefile:6: build] Error 2 +``` +Steps to reproduce: +1. tar -xf qemu-9.1.0-rc0.tar.xz +2. cd qemu-9.1.0-rc0 +3. ./configure --target-list=aarch64-softmmu --disable-plugins +4. make +Additional information: +See attached log files [configure.log](/uploads/c56dd6c9064d98d3498923adcd61a4f9/configure.log) and [build.log](/uploads/c3f16160cffcd4a817f0304226db604e/build.log) + +After reverting the last commit on plugins/meson.build the build succeeds, because here the parameter causing the failure (`--dynamic-list`) is only applied, if plugins are enabled. +``` +commit 0082475e26430297ef65e598db5b67c8ac182620 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Thu Jun 6 15:07:23 2024 +0200 + + meson: merge plugin_ldflags into emulator_link_args + + These serve the same purpose, except plugin_ldflags ends up in the linker + command line in a more roundabout way (through specific_ss). Simplify. + + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> +``` + +Configuring with plugins enabled fails with: +``` +../plugins/meson.build:28:32: ERROR: Command `D:\msys64plain\clang64\bin/dlltool.EXE --input-def D:/msys64plain/home/Normalo/qemu-9.1.0-rc0/build/plugins/qemu_plugin_api.def --output-delaylib D:/msys64plain/home/Normalo/qemu-9.1.0-rc0/build/plugins/libqemu_plugin_api.a --dllname qemu.exe` failed with status 1. + +A full log can be found at D:/msys64plain/home/Normalo/qemu-9.1.0-rc0/build/meson-logs/meson-log.txt + +ERROR: meson setup failed +``` +See attached log files [configure-plugins-enabled.log](/uploads/5ce608791fe9a47165c3fecaddce1aa8/configure-plugins-enabled.log) and [meson-log-plugins-enabled.txt](/uploads/8dc1e95726847270052def5d7b0bd63a/meson-log-plugins-enabled.txt) diff --git a/results/classifier/108/other/2477 b/results/classifier/108/other/2477 new file mode 100644 index 000000000..acf2e6178 --- /dev/null +++ b/results/classifier/108/other/2477 @@ -0,0 +1,16 @@ +device: 0.813 +network: 0.619 +performance: 0.533 +debug: 0.512 +graphic: 0.500 +other: 0.491 +semantic: 0.449 +boot: 0.317 +socket: 0.233 +files: 0.183 +permissions: 0.133 +vnc: 0.109 +PID: 0.041 +KVM: 0.015 + +GDB_HAS_MTE detection is incomplete diff --git a/results/classifier/108/other/2478 b/results/classifier/108/other/2478 new file mode 100644 index 000000000..a36104ec7 --- /dev/null +++ b/results/classifier/108/other/2478 @@ -0,0 +1,33 @@ +graphic: 0.699 +device: 0.639 +performance: 0.509 +semantic: 0.473 +vnc: 0.389 +debug: 0.337 +PID: 0.277 +network: 0.260 +files: 0.248 +socket: 0.232 +other: 0.190 +permissions: 0.170 +boot: 0.132 +KVM: 0.048 + +STM32F1 STM32VLDicovery board: incorrect clock register setting +Description of problem: +The execution of the program hangs when testing, from libopencm3 clock initialization, the status of the clock in ``rcc_wait_for_osc_ready()``. This function https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/f1/rcc.c#L366 loops until the bit stating that the oscillator is stabilized is set. I am unable to find in qemu this bit being set upon clock initialization, which I believe is an hardware emulation shortcoming. Commenting this line in libopencm3 allows for the emulation to complete correctly, but I believe the error lies in the hardware emulation and not in the libopencm3 test. Reading the status of ``RCC_CR`` from ``gdb-multiarch`` probing the QEMU internal state returns 0, leading to the failure of the test at https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/f1/rcc.c#L353 + +See https://www.st.com/resource/en/reference_manual/rm0008-stm32f101xx-stm32f102xx-stm32f103xx-stm32f105xx-and-stm32f107xx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf for the expected behavior of this register content on page 99/1136 +``` +7.3.1 Clock control register (RCC_CR) + +Bit 17 HSERDY: External high-speed clock ready flag +Set by hardware to indicate that the HSE oscillator is stable. This bit needs 6 cycles of the +HSE oscillator clock to fall down after HSEON reset. +0: HSE oscillator not ready +1: HSE oscillator ready +``` +Steps to reproduce: +1. git clone --recursive https://github.com/libopencm3/libopencm3-examples +2. make +3. qemu-system-arm -M stm32vldiscovery -nographic -serial mon:stdio -kernel examples/stm32/f1/stm32vl-discovery/usart/usart.elf diff --git a/results/classifier/108/other/2479 b/results/classifier/108/other/2479 new file mode 100644 index 000000000..a48201bce --- /dev/null +++ b/results/classifier/108/other/2479 @@ -0,0 +1,45 @@ +debug: 0.751 +device: 0.714 +PID: 0.618 +performance: 0.605 +socket: 0.594 +other: 0.563 +vnc: 0.542 +permissions: 0.528 +graphic: 0.523 +files: 0.510 +boot: 0.475 +semantic: 0.384 +network: 0.379 +KVM: 0.284 + +Unable to remotely debug with gdbserver on debian while using qemu-system-m68k emulator +Description of problem: +When I use gdb-multiarch to try to connect to the gdbserver running on the guest machine the error message below is displayed by the gdbserver: + +``` +/build/gdb-Lhte76/gdb-13.2/gdbserver/tdesc.cc:195: A problem internal to GDBserver has been detected. +tdesc_get_features_xml: Assertion `tdesc->xmltarget != NULL || (!tdesc->features.empty () && tdesc->arch != NULL)' failed. +``` + +and the program execution is terminated abruptly. +Steps to reproduce: +1. Download the Debian Motorola 680x0 Port and install it using QEmu. +2. Update to unstable version (optional). +3. Download and install gdbserver and also a compiler for the C language. +4. Write a hello world and compile. +5. Run gdbserver targeting the program from the previous step. +6. Try connecting using gdb-multiarch. +Additional information: +The error persists when I download the QEmu source code and compile it. + +If this procedure is done with an older version of gdbserver (such as 7.12) then I can connect normally. However, if a breakpoint is placed anywhere in the program and if it is reached at any point during execution and if after it is reached the 'continue' command is entered, then the error message below is displayed by the gdbserver: + +``` +linux-low.c:2627: A problem internal to GDBserver has been detected. +int maybe_hw_step(thread_info*): Assertion `has_reinsert_breakpoints (thread)' failed. +``` + +and the program execution is terminated abruptly. + +I think it's working on real hardware. |