diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-05-30 16:52:07 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-05-30 16:52:17 +0200 |
| commit | 9260319e7411ff8281700a532caa436f40120ec4 (patch) | |
| tree | 2f6bfe5f3458dd49d328d3a9eb508595450adec0 /gitlab/issues_text/target_missing/host_missing/accel_TCG | |
| parent | 225caa38269323af1bfc2daadff5ec8bd930747f (diff) | |
| download | qemu-analysis-9260319e7411ff8281700a532caa436f40120ec4.tar.gz qemu-analysis-9260319e7411ff8281700a532caa436f40120ec4.zip | |
gitlab scraper: download in toml and text format
Diffstat (limited to 'gitlab/issues_text/target_missing/host_missing/accel_TCG')
63 files changed, 1347 insertions, 0 deletions
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1065 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1065 new file mode 100644 index 000000000..568555374 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1065 @@ -0,0 +1,5 @@ +cputlb: uninitialized local variable in tlb_set_page_with_attrs cause SIGSEGV when a CPU access an unmapped IOMMU page +Description of problem: +When a TCG cpu accesses an unmapped page within an IOMMU region that causes a translation fault, QEMU SIGSEGVs in `io_readx`. +The reason was that in `address_space_translate_for_iotlb`, `xlat` is not set on a permission fault. +As a result, `xlat` in `tlb_set_page_with_attr` is uninitialized. This in turn causes various mis-calculation and eventually crashes in `io_readx`. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1086 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1086 new file mode 100644 index 000000000..4cf0cef19 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1086 @@ -0,0 +1,69 @@ +Numpy/scipy test suites fails in QEMU on ppc64le (but not on aarch64) +Description of problem: +I'm not really qualified to report this problem, but after being affected by it for ~2 years (and QEMU 7 not fixing things), I decided to give it a shot. Please excuse reporting deficiencies, I'll endeavour to fix them as best I can once pointed out. + +In my spare time, I help out for the packaging effort in the [conda-forge](https://conda-forge.org/) ecosystem, which is mostly associated/attached to the python world, but - in contrast to the vanilla python tools - also deals with non-python dependencies, and in particular has strong enough abstractions to deal with ABI-issues and generally provides much better integration than the packages on PyPI. + +This strength of abstraction has also allowed conda-forge to publish artefacts for many more architectures than most projects are commonly able to provide precompiled binaries for. Due to the lack of (reliable) public CI for aarch64 & ppc64le, these packages are mostly cross-compiled from linux-x86. Where cross compilation is not possible, the packages are compiled in emulation through QEMU, coming through https://github.com/multiarch/qemu-user-static (this is the part of the infrastructure I don't fully understand myself...). The full infrastructure is somewhat involved, but should not be relevant (hopefully) to the issue at hand (see instructions below) - and even if that turns out to be the case, that would be a great information gain as well. + +In either case, the tests for the package (ideally comprising the entire upstream test suite) are then run in emulation. + +Two of the so-called "feedstocks" I co-maintain are for [numpy](https://github.com/conda-forge/numpy-feedstock) and [scipy](https://github.com/conda-forge/scipy-feedstock), and there have been persistent issues with running the test suite in emulation on PPC (interestingly, the same setup on a different architecture - aarch64 - has no problems). However, the compiled artefacts on PPC run fine on native hardware. + +Said otherwise, it appears numpy/scipy are exercising QEMU enough to uncover some bugs. I've seen similar problems also in other packages (e.g. the cvxpy-stack), reinforcing the impression that this is a QEMU issue, and not one on the level of the individual packages. + +Depending on the exact combination of python version, the result of the numpy test suite might be as follows: +``` +320 failed, 18900 passed, 361 skipped, 36 xfailed, 9 xpassed, 144 warnings in 2516.49s (0:41:56) +``` + +Looking at the test failures, sometimes the results are garbage +``` +> assert_array_max_ulp(x, x+eps, maxulp=20) +E AssertionError: Arrays are not almost equal up to 20 ULP (max difference is 8.55554e+08 ULP) + +eps = 1.1920929e-07 +self = <numpy.testing.tests.test_utils.TestULP object at 0x401ec8beb0> +x = array([ 2.3744986e-38, nan, 2.2482052e-15, 7.5780330e+28, + nan, nan, 5.8310814e+29, -5.6511531e+24, + 1.0010809e+00, 1.0101526e+00], dtype=float32) +``` +sometimes the values are permuted +``` +> assert_array_equal(actual, desired) +E AssertionError: +E Arrays are not equal +E +E x and y nan location mismatch: +E x: array([0.000000e+00, 6.704092e-39, 9.000000e+00, 2.350989e-38, +E 0.000000e+00, 0.000000e+00, 0.000000e+00, 0.000000e+00, +E 6.772341e-39, nan], dtype=float32) +E y: array([6.704092e-39, 6.772341e-39, 0.000000e+00, 0.000000e+00, +E 0.000000e+00, 0.000000e+00, nan, 2.350989e-38, +E 2.000000e+00, 7.000000e+00], dtype=float32) +``` +sometimes the results are fundamentally different (zero vs. non-zero) +``` +> raise AssertionError(msg) +E AssertionError: +E Arrays are not almost equal to 6 decimals +E +E Mismatched elements: 72 / 216 (33.3%) +E Max absolute difference: 1. +E Max relative difference: 1. +E x: array([[[[[0., 0., 0.], +E [0., 0., 0.], +E [0., 0., 0.]],... +E y: array([[[[[1., 0., 0.], +E [0., 1., 0.], +E [0., 0., 1.]],... +``` + +I don't know where it goes wrong, but it's not just a little tolerance violation. One PR that illustrates this is [here](https://github.com/conda-forge/numpy-feedstock/pull/274) and the respective CI run is [here](https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=526218&view=results) (ignore the errors for osx-arm64, those are unrelated). +Steps to reproduce: +1. In an emulated ppc64 machine, install miniforge from [here](https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-ppc64le.sh) +2. Run `conda create -n test_env numpy pytest cython hypothesis typing_extensions` and then `conda activate test_env` +3. Run `python -c "import numpy; numpy.test()"` +4. Pick any test that fails and run it as `python -c "import numpy; numpy.test(tests='x.y.z')"` +Additional information: + diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1174 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1174 new file mode 100644 index 000000000..ba349c10a --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1174 @@ -0,0 +1,13 @@ +aspeed: Fix first byte in I2C old register mode slave receive +Description of problem: +The first byte of data received through the Aspeed I2C slave controller through the old-register mode (specifically byte-buffered, not pool buffered or DMA buffered) is incorrect. It should be the 8-bit I2C slave address for the transfer, which will be the 7-bit I2C slave address of the I2C controller shifted left 1, and 1 or 0 for the lowest bit (is-slave-to-master-transfer, or is-master-to-slave-transfer). +Steps to reproduce: +You could use the simulated I2C slave EEPROM https://docs.kernel.org/i2c/slave-eeprom-backend.html, but you need another I2C model to send data to it. + +Alternatively, you can take this downstream patch and run the qtest in it. It has a test case for slave-mode rx in old-register mode: + +https://github.com/facebook/openbmc/blob/helium/common/recipes-devtools/qemu/qemu/0008-hw-misc-Add-byte-by-byte-i2c-network-device.patch +Additional information: +I already created the fix, it's pretty simple, I submitted it to the mailing list and Klaus (the author of that section of the Aspeed I2C controller) reviewed it. https://lore.kernel.org/qemu-devel/20220820225712.713209-1-peter@pjd.dev/#t + +This is relatively critical fix, but since slave-mode I2C is not widely used at this point, it's probably fine to ship with this bug. My team uses the master branch for everything anyways. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1184 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1184 new file mode 100644 index 000000000..794813dcb --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1184 @@ -0,0 +1,69 @@ +Extra SIGTRAP when breakpoint + watchpoint occur on same instruction +Description of problem: +If a breakpoint and watchpoint occur on the same instruction in TCG, gdb receives a breakpoint notification, a watchpoint notification, and then a SIGTRAP not corresponding to any set breakpoint/watchpoint. +Steps to reproduce: +Start QEMU via: + +``` +./qemu-system-i386 -display none -accel tcg -kernel kernel.elf -s -S +``` + +Here's the gdb session: + +``` +(gdb) file kernel.elf +Reading symbols from kernel.elf...done. +(gdb) tar rem :1234 +Remote debugging using :1234 +0x0000fff0 in ?? () +(gdb) b _start +Breakpoint 1 at 0x10000c: file kernel.s, line 17. +(gdb) c +Continuing. + +Breakpoint 1, _start () at kernel.s:17 +17 mov eax, 3 +(gdb) b bp +Breakpoint 2 at 0x100011: file kernel.s, line 20. +(gdb) watch *(int*)&value +Hardware watchpoint 3: *(int*)&value +(gdb) c +Continuing. + +Breakpoint 2, bp () at kernel.s:20 +20 mov dword ptr value, eax +(gdb) c +Continuing. + +Hardware watchpoint 3: *(int*)&value + +Old value = 0 +New value = 3 +done () at kernel.s:23 +23 jmp done +(gdb) c +Continuing. + +Program received signal SIGTRAP, Trace/breakpoint trap. +done () at kernel.s:23 +23 jmp done +``` +Additional information: +This patch fixes it by disabling the extra debug interrupt if the CPU is already singlestepping, but I'm not certain it's the 'correct' fix? + +```patch +--- a/softmmu/physmem.c ++++ b/softmmu/physmem.c +@@ -894,7 +894,9 @@ void cpu_check_watchpoint(CPUState *cpu, vaddr addr, vaddr len, + * trigger after the current instruction. + */ + qemu_mutex_lock_iothread(); +- cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG); ++ if ((cpu->singlestep_enabled & SSTEP_NOIRQ) == 0) { ++ cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG); ++ } + qemu_mutex_unlock_iothread(); + return; + } + +``` diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1303 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1303 new file mode 100644 index 000000000..eb38cedcb --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1303 @@ -0,0 +1 @@ +tcg/cputlb: code path is reachable in load_memop/store_memop() diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/134 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/134 new file mode 100644 index 000000000..298f3be3e --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/134 @@ -0,0 +1 @@ +Performance improvement when using "QEMU_FLATTEN" with softfloat type conversions diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1402 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1402 new file mode 100644 index 000000000..c4d4bcd4f --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1402 @@ -0,0 +1,59 @@ +cpu-exec.c fails to compile - code path is reachable +Description of problem: +Building qemu (tested with both gcc11 and gcc12) fails with: + +``` +[34/76] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +FAILED: libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +gcc -m64 -mcx16 -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm +-I../target/arm -I../dtc/libfdt -Iqapi -Itrace -Iui -Iui/shader +-I/opt/ooce/include/pixman-1 +-I/data/omnios-build/omniosorg/qemu/libtasn1-4.19.0/out/include +-I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include +-fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g +-iquote . -iquote /data/omnios-build/omniosorg/qemu +-iquote /data/omnios-build/omniosorg/qemu/include +-iquote /data/omnios-build/omniosorg/qemu/tcg/i386 +-pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D__EXTENSIONS__ +-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE +-Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes +-fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition +-Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers +-Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined +-Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value +-Wno-psabi -fstack-protector-strong -m64 -gdwarf-2 -gstrict-dwarf +-fno-omit-frame-pointer -fno-aggressive-loop-optimizations -DNEED_CPU_H +'-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' +'-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ +libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +-MF libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o.d +-o libqemu-aarch64-softmmu.fa.p/accel_tcg_cpu-exec.c.o +-c ../accel/tcg/cpu-exec.c +In file included from ../accel/tcg/cpu-exec.c:20: +In function 'tb_pc', + inlined from 'cpu_tb_exec' at ../accel/tcg/cpu-exec.c:465:13: +/data/omnios-build/omniosorg/qemu/include/qemu/osdep.h:184:35: error: call to 'qemu_build_not_reached_always' declared with attribute error: code path is reachable + 184 | #define qemu_build_not_reached() qemu_build_not_reached_always() + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +/data/omnios-build/omniosorg/qemu/include/exec/exec-all.h:608:5: note: in expansion of macro 'qemu_build_not_reached' + 608 | qemu_build_not_reached(); + | ^~~~~~~~~~~~~~~~~~~~~~ +``` +Additional information: +It appears that the compiler is not smart enough to realise that `TARGET_TB_PCREL` is false in the branch there or is not able to infer that from the `assert()`. + +Adding an explicit check as a workaround allows compilation to continue. + +```diff +--- a/accel/tcg/cpu-exec.c ++++ b/accel/tcg/cpu-exec.c +@@ -459,7 +459,7 @@ cpu_tb_exec(CPUState *cpu, TranslationBlock *itb, int *tb_exit) + + if (cc->tcg_ops->synchronize_from_tb) { + cc->tcg_ops->synchronize_from_tb(cpu, last_tb); +- } else { ++ } else if (!TARGET_TB_PCREL) { + assert(!TARGET_TB_PCREL); + assert(cc->set_pc); + cc->set_pc(cpu, tb_pc(last_tb)); +``` diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1435 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1435 new file mode 100644 index 000000000..b42506766 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1435 @@ -0,0 +1,16 @@ +Infinite recursion in tcg_gen_mulu2_i32 for certain 32-bit hosts. +Description of problem: +`tcg_gen_mulu2_i32` infinitely recurses on a 32-bit host (TCG target) that has neither `TCG_TARGET_HAS_mulu2_i32` nor `TCG_TARGET_HAS_muluh_i32`. + +I don't actually think there is any host that is 32-bits and has neither mulu2 nor muluh. The only reference I found is [this](https://gitlab.com/qemu-project/qemu/-/commit/df9ebea53ebc1c98217743f56c30ae3a46031bb9) commit, which adds an `#error` if that situation is hit. But the check, which [still exists](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/include/tcg/tcg.h#L174), checks if those flags are *defined*, not for their value. I guess, over the years as the code was refactored, the check wasn't updated because, frankly, there aren't any hosts that match that situation (except mine). + +One easy fix is to change the check mentioned above to check the actual macro value so that compilation fails. I can create a PR for that. +Steps to reproduce: +(Note: I'm linking to the v7.2.0 tag so that these links stay relevant). + +1. `tcg_gen_mulu2_i32` [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L890) `tcg_gen_mul_i64`. +2. `tcg_gen_mul_i64` on 32-bit hosts, due to [this](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1097) check for `TCG_TARGET_REG_BITS == 32`, is defined [here](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1218), and [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1226) `tcg_gen_mulu2_i32`. +3. Rinse and repeat. +4. Eventually, as gen_mulu2/mul functions spill while trying to allocate temps, they will overflow the TB buffer. This will restart code generation with smaller and smaller block sizes, until the block size reaches 1 instruction. TCG will then give up and [assert](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/accel/tcg/translate-all.c#L869). +Additional information: + diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1454 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1454 new file mode 100644 index 000000000..f15dfebf6 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1454 @@ -0,0 +1,62 @@ +QEMU TCG s390x fails an assertion while dispatching an FIXPT_DIVIDE exception on DR when compiled with LTO +Description of problem: +When running the attached minimal reproducer, with qemu-system-s390x version 7.2.0 compiled with LTO (`--enable-lto`) with GCC v12.2.1, QEMU fails an assertion and crashes: +``` +qemu-system-s390x: ../target/s390x/tcg/excp_helper.c:215: do_program_interrupt: Assertion `ilen == 2 || ilen == 4 || ilen == 6' failed. +Aborted (core dumped) +``` +Steps to reproduce: +1. Compile QEMU v7.2.0 for s390x with LTO enabled: + ``` + ../configure --target-list=s390x-softmmu --enable-lto + ``` +2. Compile the given reproducer assembler [lpswe-to-pgm.S](/uploads/200fb0e777ddd0ed26f51009e81c26ea/lpswe-to-pgm.S): + ``` + s390x-linux-gnu-gcc -march=z13 -m64 -nostdlib -nostartfiles -static -Wl,-Ttext=0 -Wl,--build-id=none lpswe-to-pgm.S -o lpswe-to-pgm + ``` +3. Execute QEMU on the reproducer: + ``` + ./qemu-system-s390x -kernel lpswe-to-pgm + ``` +Additional information: +I have debugged QEMU to try to find the root cause, and I believe I found it, but I'm not sure what the most appropriate way to fix it would be: + +QEMU executes the `DR` instruction by executing the `divs32` helper. + +When the helper sees that the final division result does not fit in 32 bits, it generates a program interrupt for fixed point divide by calling the `tcg_s390_program_interrupt` function, with the final parameter being the TCG host PC, which is found by calling `GETPC`. + +`tcg_s390_program_interrupt` then calls `cpu_restore_state`, and then as long as the host PC is valid, `cpu_restore_state` eventually calls `s390x_restore_state_to_opc` through a long chain of calls, which sets `CPUS390XState::int_pgm_ilen` to a valid value. + +Unfortunately when compiling with LTO, the host PC is not valid, which means we don't update `int_pgm_ilen`, resulting in the failed assertion. + +The reason the host PC is not valid when compiling with LTO, is that GCC decides to split `helper_divs32` into 2 parts, the actual div logic being the first part, and the call to `GETPC` & `tcg_s390_program_interrupt` being the second part. The way GCC implements it is by turning the second part into a separate function, which the first part calls - see disassembly below. (GCC then re-uses the second part in other similar TCG helpers) + +Because we now called the second part before calling `GETPC`, we have a new return address, and `GETPC` returns the address of the first part, instead of the TCG host PC. + +``` +000000000022c870 <helper_divs32>: + 22c870: 48 83 ec 08 sub rsp,0x8 + 22c874: 85 d2 test edx,edx + 22c876: 74 22 je 22c89a <helper_divs32+0x2a> + 22c878: 48 89 f0 mov rax,rsi + 22c87b: 48 63 ca movsxd rcx,edx + 22c87e: 48 99 cqo + 22c880: 48 f7 f9 idiv rcx + 22c883: 4c 63 c0 movsxd r8,eax + 22c886: 48 89 97 10 03 00 00 mov QWORD PTR [rdi+0x310],rdx + 22c88d: 49 39 c0 cmp r8,rax + 22c890: 75 17 jne 22c8a9 <helper_divs32+0x39> + 22c892: 4c 89 c0 mov rax,r8 + 22c895: 48 83 c4 08 add rsp,0x8 + 22c899: c3 ret + 22c89a: 48 8b 54 24 08 mov rdx,QWORD PTR [rsp+0x8] + 22c89f: be 09 00 00 00 mov esi,0x9 + 22c8a4: e8 47 e5 ff ff call 22adf0 <tcg_s390_program_interrupt> + 22c8a9: e8 b2 fe ff ff call 22c760 <helper_divs32.part.0> + +000000000022c760 <helper_divs32.part.0>: + 22c760: 48 83 ec 08 sub rsp,0x8 + 22c764: be 09 00 00 00 mov esi,0x9 + 22c769: 48 8b 54 24 08 mov rdx,QWORD PTR [rsp+0x8] + 22c76e: e8 7d e6 ff ff call 22adf0 <tcg_s390_program_interrupt> +``` diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1503 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1503 new file mode 100644 index 000000000..8ab7691d5 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1503 @@ -0,0 +1,50 @@ +Writing to readonly memory should call cpu_transaction_failed +Description of problem: +Currently if a guest writes to ROM memory on a system that doesn't have some other form of memory protection enabled, QEMU will silently ignore the write (https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c#L2432). Instead, it should call cpu_transaction_failed (similar to what happens when a MMIO operation fails in `io_writex` and other places). For CPUs that don't care, it'll continue to be ignored, but for other CPUs the user will get a warning (with `-d guest_errors`) or an exception as appropriate. +Steps to reproduce: +N/A +Additional information: +The documentation for do_transaction_failed says: + +``` +@do_transaction_failed: Callback for handling failed memory transactions +(ie bus faults or external aborts; not MMU faults) +``` + +which seems reasonably well suited for this case. Here's an overview of what different CPUs currently do if do_transaction_failed is called: + +alpha_cpu_do_transaction_failed: + +* raises a EXCP_MCHK + +arm_cpu_do_transaction_failed: + +* raises ARMFault_SyncExternal with EXCP_DATA_ABORT + +loongarch_cpu_do_transaction_failed: + +* raises EXCCODE_ADEM + +m68k_cpu_transaction_failed: + +* raises EXCP_ACCESS (M68040 only) + +mb_cpu_transaction_failed: + +* raises EXCP_HW_EXCP with ESR_EC_DATA_BUS + +mips_cpu_do_transaction_failed: + +* raises EXCP_DBE (data bus error) + +riscv_cpu_do_transaction_failed: + +* raises RISCV_EXCP_STORE_AMO_ACCESS_FAULT + +sparc_cpu_do_transaction_failed: + +* raises an MMU fault + +xtensa_cpu_do_transaction_failed + +* raises LOAD_STORE_PIF_ADDR_ERROR_CAUSE diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1565 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1565 new file mode 100644 index 000000000..b4d44645e --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1565 @@ -0,0 +1,34 @@ +s390x TCG migration failure +Description of problem: +We're seeing failures running s390x migration kvm-unit-tests tests with TCG. + +Some initial findings: + +What seems to be happening is that after migration a control block header accessed by the test code is all zeros which causes an unexpected exception. + +I did a bisection which points to c8df4a7aef ("migration: Split save_live_pending() into state_pending_*") as the culprit. +The migration issue persists after applying the fix e264705012 ("migration: I messed state_pending_exact/estimate") on top of c8df4a7aef. + +Applying + +``` +diff --git a/migration/ram.c b/migration/ram.c +index 56ff9cd29d..2dc546cf28 100644 +--- a/migration/ram.c ++++ b/migration/ram.c +@@ -3437,7 +3437,7 @@ static void ram_state_pending_exact(void *opaque, uint64_t max_size, + + uint64_t remaining_size = rs->migration_dirty_pages * TARGET_PAGE_SIZE; + +- if (!migration_in_postcopy()) { ++ if (!migration_in_postcopy() && remaining_size < max_size) { + qemu_mutex_lock_iothread(); + WITH_RCU_READ_LOCK_GUARD() { + migration_bitmap_sync_precopy(rs); +``` +on top fixes or hides the issue. (The comparison was removed by c8df4a7aef.) + +I arrived at this by experimentation, I haven't looked into why this makes a difference. +Steps to reproduce: +1. Run ACCEL=tcg ./run_tests.sh migration-skey-sequential with current QEMU master +2. Repeat until the test fails (doesn't happen every time, but still easy to reproduce) diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1591 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1591 new file mode 100644 index 000000000..20881e5fa --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1591 @@ -0,0 +1 @@ +test-mmap (4096 byte pages) on arm fails on ppc64le host diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1631 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1631 new file mode 100644 index 000000000..bc81e3dc0 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1631 @@ -0,0 +1,17 @@ +[8.0.0] Host MacOS 13.3.1 – does not work or works incorrectly +Description of problem: +WINXP x86 - freezes before logging in on ARM macOS 13.3.1 host + +WINXP x86 - works but slowly x86_64 macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after start on ARM macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after selecting grub boot option + +**On qemu 7.2.1 all works perfectly!!!** +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1684 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1684 new file mode 100644 index 000000000..271d4583c --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1684 @@ -0,0 +1,45 @@ +QEMU doesn't use multi-threaded TCG on aarch64 host with x86-64 guest +Description of problem: +Even configured to emulate more than one vCPU, at the host it only uses 1 CPU at 100%. The same test was made using same architecture (aarch64 on aarch64), and it archieves to use all phisical cores. The first VM uses TGC, the second one uses KVM. Screenshots attached. +Steps to reproduce: +1. Use official Debian distro from Rock Pi 5B +2. Install XFCE4 and VirtManager, qemu aarch64 and qemu x86_64 +3. Download debian x64 netinstall iso +4. Install system with basic features, then install stress-ng +5. Stop, configure -smp to 1 socket, 4 cores, 2 threads, it will result on 8 vCPUs +6. Login as root and run stress-ng to 8 CPU +7. Ctrl+Right to another TTY, install and run htop, you will see 8 CPUs on 100% usage +8. At host, open Terminal, install and run htop, you will see just one core at 100% +Additional information: +Both VMs tested. aarch64 as KVM that works fine, x86_64 as TGC that uses only one CPU. + + +VirtManager VM #1 config for x86_64 on aarch64 + + +VirtManager VM #2 config for aarch64 on aarch64 + + +VirtManager VM #2 hypervisor used as KVM + + +VirtManager VM #1 hypervisor used as TGC + + +100% on host of all cores being used with stress-ng at aarch64 guest + + +All cores at 100% on aarch64 guest + + +100% on host of just one core being used with stress-ng at x86_64 guest + + +Cool down after both VMs ended stress-ng process + + +virsh version + + +"dmesg | head -n50" at host machine + diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1736 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1736 new file mode 100644 index 000000000..d3700379d --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1736 @@ -0,0 +1,67 @@ +Invalid guest addr in debug output +Description of problem: +When using QEMU 7.1.0 the log file for the first translation block (not starting at 0) looks like this: +(Note the `guest addr 0x00010000`) +``` +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=47] + -- guest addr 0x00010000 + tb prologue +0x7f95a8000300: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7f95a8000303: 85 db testl %ebx, %ebx +0x7f95a8000305: 0f 8c 18 00 00 00 jl 0x7f95a8000323 + -- guest addr 0x00010020 +0x7f95a800030b: e9 00 00 00 00 jmp 0x7f95a8000310 +0x7f95a8000310: c7 45 3c 3c 00 01 00 movl $0x1003c, 0x3c(%rbp) +0x7f95a8000317: 48 8d 05 22 ff ff ff leaq -0xde(%rip), %rax +0x7f95a800031e: e9 f5 fc ff ff jmp 0x7f95a8000018 +0x7f95a8000323: 48 8d 05 19 ff ff ff leaq -0xe7(%rip), %rax +0x7f95a800032a: e9 e9 fc ff ff jmp 0x7f95a8000018 +``` + +For QEMU 7.2.0 and higher: +(Note the `guest addr` is only the page offset.) +``` +Trace 0: 0x7fe434000100 [00000400/00000000/00000020/ff200000] +---------------- +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=52] + -- guest addr 0x00000000 + tb prologue +0x7fe434000340: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7fe434000343: 85 db testl %ebx, %ebx +0x7fe434000345: 0f 8c 1d 00 00 00 jl 0x7fe434000368 + -- guest addr 0x00000020 +0x7fe43400034b: 8b 5d 3c movl 0x3c(%rbp), %ebx +0x7fe43400034e: 83 c3 3c addl $0x3c, %ebx +0x7fe434000351: 89 5d 3c movl %ebx, 0x3c(%rbp) +0x7fe434000354: 66 66 90 nop +0x7fe434000357: e9 00 00 00 00 jmp 0x7fe43400035c +0x7fe43400035c: 48 8d 05 1d ff ff ff leaq -0xe3(%rip), %rax +0x7fe434000363: e9 b0 fc ff ff jmp 0x7fe434000018 +0x7fe434000368: 48 8d 05 14 ff ff ff leaq -0xec(%rip), %rax +0x7fe43400036f: e9 a4 fc ff ff jmp 0x7fe434000018 +``` +Steps to reproduce: +1. Run the provided command line for any kernel / system image. (likely other architectures are affected as well) +2. Look into the debug log. +Additional information: +While looking if this was already reported I found #1528 and #1697 which could potentially caused by this. It might as well be just an oversight in the debug output. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1800 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1800 new file mode 100644 index 000000000..30ccf63c4 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1800 @@ -0,0 +1,32 @@ +8.1.0-rc1 Regression: donkey in qemu advent calender 03/2020 has graphical artifacts +Description of problem: +The game donkey shows graphical artifacts on playing. On changing the lane the car remains on its previous land as well. +A git bisect identified commit 592134617c98f37b8b39c6dd684e5a1832c071d2 as culprit +Steps to reproduce: +1. Download http://qemu-advent-calendar.org/2020/download/gw-basic.tar.xz +2. Start VM using command + ``` + qemu-system-i386 -m 16M -drive if=ide,format=qcow2,file=gwbasic.qcow2 + ``` +3. Wait for GW-Basic prompt and enter (see README): F3 - donkey - <ENTER> - F2 +4. Play to see graphical artifacts +Additional information: +``` +$ git bisect bad +592134617c98f37b8b39c6dd684e5a1832c071d2 is the first bad commit +commit 592134617c98f37b8b39c6dd684e5a1832c071d2 +Author: Richard Henderson +Date: Sun Oct 30 12:07:32 2022 +1100 + + accel/tcg: Reorg system mode store helpers + + Instead of trying to unify all operations on uint64_t, use + mmu_lookup() to perform the basic tlb hit and resolution. + Create individual functions to handle access by size. + + Reviewed-by: Peter Maydell <peter.maydell@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + + accel/tcg/cputlb.c | 394 +++++++++++++++++++++++++---------------------------- + 1 file changed, 186 insertions(+), 208 deletions(-) +``` diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1856 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1856 new file mode 100644 index 000000000..6d02df80b --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1856 @@ -0,0 +1,13 @@ +Replay got stuck with consecutive hardware interrupts coming +Description of problem: +I recorded bin file using **_rr=record_** command line. But it got stuck when replaying this record bin file. The icount number would never change after stucking if I typed _**info replay**_ with qmp command line. + +I found that the following instructions should be a sequence of consecutive hardware interrupts after stucking once checking the trace log of +both replay and record log using _**-d in_asm,int**_. +Steps to reproduce: +1.pulling from remote which the newest commit ID is 156618d9ea67f2f2e31d9dedd97f2dcccbe6808c +2.emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism +3.using **_rr=record_** to make replay file and tracing guest code and interrupts using _**-d in_asm,int**_ +4.replaying the previous file and also tracing guest code and interrupts +Additional information: +# diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1866 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1866 new file mode 100644 index 000000000..b3f775c6c --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1866 @@ -0,0 +1 @@ +mips/mip64 virtio broken on master (and 8.1.0 with tcg fix) diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2010 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2010 new file mode 100644 index 000000000..554e180a4 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2010 @@ -0,0 +1,80 @@ +The avocado test replay_kernel.py:ReplayKernelNormal.test_x86_64_pc is unreliable +Description of problem: +The replay test case is unreliable and often hangs at the second stage +Additional information: +The record stage complete fine: + +``` +2023-11-30 17:25:27,944 protocol L0481 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'. +2023-11-30 17:25:27,944 machine L0925 DEBUG| Opening console file +2023-11-30 17:25:27,944 machine L0903 DEBUG| Opening console socket +2023-11-30 17:25:42,652 __init__ L0153 DEBUG| [ 0.000000] Linux version 4.18.16-300.fc29.x86_64 (mockbuild@bkernel04.phx2.fedoraproject.org) (gcc version 8.2.1 20 +180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:24:08 UTC 2018 +2023-11-30 17:25:42,652 __init__ L0153 DEBUG| [ 0.000000] Command line: printk.time=1 panic=-1 console=ttyS0 +2023-11-30 17:25:42,652 __init__ L0153 DEBUG| [ 0.000000] x86/fpu: x87 FPU will use FXSAVE +2023-11-30 17:25:42,652 __init__ L0153 DEBUG| [ 0.000000] BIOS-provided physical RAM map: +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000007fdffff] usable +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x0000000007fe0000-0x0000000007ffffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] NX (Execute Disable) protection: active +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] SMBIOS 3.0.0 present. +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/201 +4 +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] last_pfn = 0x7fe0 max_arch_pfn = 0x400000000 +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT +2023-11-30 17:25:42,653 __init__ L0153 DEBUG| [ 0.000000] found SMP MP-table at [mem 0x000f5480-0x000f548f] mapped at [(____ptrval____)] +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: Early table checksum verification disabled +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: RSDP 0x00000000000F52A0 000014 (v00 BOCHS ) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: RSDT 0x0000000007FE1C78 000034 (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: FACP 0x0000000007FE1B2C 000074 (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: DSDT 0x0000000007FE0040 001AEC (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: FACS 0x0000000007FE0000 000040 +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: APIC 0x0000000007FE1BA0 000078 (v03 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: HPET 0x0000000007FE1C18 000038 (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] ACPI: WAET 0x0000000007FE1C50 000028 (v01 BOCHS BXPC 00000001 BXPC 00000001) +2023-11-30 17:25:42,654 __init__ L0153 DEBUG| [ 0.000000] No NUMA configuration found +... +``` + +After recording the initial step the replay hangs shortly after mapping the BIOS until the test timeout terminates it. + +``` +2023-11-30 17:25:59,414 __init__ L0153 DEBUG| [ 0.000000] Linux version 4.18.16-300.fc29.x86_64 (mockbuild@bkernel04.phx2.fedoraproject.org) (gcc version 8.2.1 20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:24:08 UTC 2018 +2023-11-30 17:25:59,415 __init__ L0153 DEBUG| [ 0.000000] Command line: printk.time=1 panic=-1 console=ttyS0 +2023-11-30 17:25:59,415 __init__ L0153 DEBUG| [ 0.000000] x86/fpu: x87 FPU will use FXSAVE +2023-11-30 17:25:59,415 __init__ L0153 DEBUG| [ 0.000000] BIOS-provided physical RAM map: +2023-11-30 17:25:59,416 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable +2023-11-30 17:25:59,416 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved +2023-11-30 17:25:59,420 __init__ L0153 DEBUG| [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] re +2023-11-30 17:27:28,826 stacktrace L0039 ERROR| +2023-11-30 17:27:28,826 stacktrace L0041 ERROR| Reproduced traceback from: /home/alex/lsrc/qemu.git/builds/all/pyvenv/lib/python3.11/site-packages/avocado/core/test.py:770 +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| Traceback (most recent call last): +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/pyvenv/lib/python3.11/site-packages/avocado/core/decorators.py", line 90, in wrapper +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| return function(obj, *args, **kwargs) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/replay_kernel.py", line 101, in test_x86_64_pc +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| self.run_rr(kernel_path, kernel_command_line, console_pattern, shift=5) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/replay_kernel.py", line 78, in run_rr +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| t2 = self.run_vm(kernel_path, kernel_command_line, console_pattern, +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/replay_kernel.py", line 61, in run_vm +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| self.wait_for_console_pattern(console_pattern, vm) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/boot_linux_console.py", line 52, in wait_for_console_pattern +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| wait_for_console_pattern(self, success_message, +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/avocado_qemu/__init__.py", line 199, in wait_for_console_pattern +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| _console_interaction(test, success_message, failure_message, None, vm=vm) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/avocado_qemu/__init__.py", line 148, in _console_interaction +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| msg = console.readline().decode().strip() +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^ +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/usr/lib/python3.11/socket.py", line 706, in readinto +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| return self._sock.recv_into(b) +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^ +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| File "/home/alex/lsrc/qemu.git/builds/all/pyvenv/lib/python3.11/site-packages/avocado/plugins/runner.py", line 77, in sigterm_handler +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| raise RuntimeError("Test interrupted by SIGTERM") +2023-11-30 17:27:28,827 stacktrace L0045 ERROR| RuntimeError: Test interrupted by SIGTERM +2023-11-30 17:27:28,827 stacktrace L0046 ERROR| +``` diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2030 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2030 new file mode 100644 index 000000000..421389bfe --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2030 @@ -0,0 +1,17 @@ +Unreachable code +Description of problem: +There is always a false condition in the function `alloc_code_gen_buffer_splitwx_memfd` in the file `tcg/region.c`. If `buf_rw == NULL` we go to the mark __fail__: + +https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/region.c?ref_type=heads#L580-L583 + +But the value of `buf_rx` is __`MAP_FAILED`__: + +https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/region.c?ref_type=heads#L577 + +And this line will never be reached: + +https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/region.c?ref_type=heads#L601 + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Voronin. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2094 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2094 new file mode 100644 index 000000000..ea0fd498a --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2094 @@ -0,0 +1,7 @@ +Various record/replay avocado tests hang when run under gitlab CI +Description of problem: +While previous fixes have gone in including #2010 and #2013 we are still seeing +hangs on CI. Some examples: + + https://gitlab.com/thuth/qemu/-/jobs/5910241580#L227 + https://gitlab.com/thuth/qemu/-/jobs/5910241593#L396 diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2105 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2105 new file mode 100644 index 000000000..a4ab37159 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2105 @@ -0,0 +1 @@ +memory trace not logging every memory write operation diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2152 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2152 new file mode 100644 index 000000000..481c2f875 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2152 @@ -0,0 +1 @@ +TCG plugin to keep track what byte is load/store into memory diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2181 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2181 new file mode 100644 index 000000000..0620c0bc5 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2181 @@ -0,0 +1,3 @@ +-icount mips/gips/kips options on QEMU for more advanced icount option +Additional information: +Changing IPS in QEMU affects the frequency of VGA updates, the duration of time before a key starts to autorepeat, and the measurement of BogoMips and other benchmarks. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2208 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2208 new file mode 100644 index 000000000..9e0ce4c43 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2208 @@ -0,0 +1,88 @@ +PC is not updated for each instruction in TCG plugins +Description of problem: +I have checkout the `master` branch (the latest available commit on my machine is *7d4e29ef80*) to test the new functions that allow plugins to read registers. See https://gitlab.com/qemu-project/qemu/-/issues/1706 that has been closed last Friday. + +I am using a simple hello-world binary for ARM for my tests: + +```bash +% ./qemu-aarch64 hello-world.out +Hello World! +``` + +I run this binary with the *execlog* plugin enabled, and with the `-one-insn-per-tb` option: + +```bash +% ./qemu-aarch64 -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=pc -one-insn-per-tb hello-world.out +``` + +Here is the end of the execution: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478", pc -> 0x00000000000040e474 +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0, pc -> 0x00000000000040d390 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f635a9e7f28, pc -> 0x00000000000040d394 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8, pc -> 0x00000000000040d398 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1", pc -> 0x00000000000040d39c +0, 0x40d39c, 0xd2800001, "movz x1, #0", pc -> 0x00000000000040d3a0 +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25", pc -> 0x00000000000040d3a8 +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f635a9e7ea0, pc -> 0x00000000000040d3ac +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f635a9e7eb0, pc -> 0x00000000000040d3b0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f635a9e7ec0, pc -> 0x00000000000040d3b4 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f635a9e7ed0, pc -> 0x00000000000040d3b8 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f635a9e7e90, pc -> 0x00000000000040d3bc +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19", pc -> 0x000000000000405d84 +0, 0x405d84, 0x91000694, "add x20, x20, #1", pc -> 0x000000000000405d88 +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23", pc -> 0x000000000000405d90 +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0", pc -> 0x000000000000418e14 +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000", pc -> 0x000000000000418e18 +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0, pc -> 0x000000000000418e1c +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0", pc -> 0x000000000000418e20 +0, 0x418e20, 0xaa0203e0, "mov x0, x2", pc -> 0x000000000000418e24 +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e", pc -> 0x000000000000418e28 +0, 0x418e28, 0xd4000001, "svc #0" +``` + +Now, here is the same part of the execution but without the `-one-insn-per-tb` option: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478" +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f4d42108f28 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1" +0, 0x40d39c, 0xd2800001, "movz x1, #0" +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25" +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f4d42108ea0 +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f4d42108eb0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f4d42108ec0 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f4d42108ed0 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f4d42108e90 +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19" +0, 0x405d84, 0x91000694, "add x20, x20, #1" +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23" +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0" +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000" +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0 +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0" +0, 0x418e20, 0xaa0203e0, "mov x0, x2" +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e" +0, 0x418e28, 0xd4000001, "svc #0" +``` + +The [documentation](https://www.qemu.org/docs/master/devel/tcg-plugins.html) says: + +> This plugin can also dump registers when they change value. Specify the name of the registers with multiple reg options. + +The `pc` register changes for each instruction. I would expect the plugin to produce the same output with or without the `-one-insn-per-tb` option. +Additional information: +The code that prints "pc -> 0x......" is in `insn_check_regs()` in `contrib/plugins/execlog.c`. It uses the new `qemu_plugin_read_register()` function and compares the new value to the previous value. The code seems OK. It means that the implementation of `qemu_plugin_read_register()` gets the same value several times in a row, instead of a new value each time. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2285 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2285 new file mode 100644 index 000000000..a10d6b50f --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2285 @@ -0,0 +1 @@ +cross-i686-tci job intermittent timeouts diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2328 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2328 new file mode 100644 index 000000000..84b17c81a --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2328 @@ -0,0 +1 @@ +sha1.c:161:13: warning: ‘SHA1Transform’ reading 64 bytes from a region of size 0 diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/245 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/245 new file mode 100644 index 000000000..1a53f9900 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/245 @@ -0,0 +1 @@ +watchpoints might not properly stop execution at the right address diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2460 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2460 new file mode 100644 index 000000000..b9c082ca0 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2460 @@ -0,0 +1,8 @@ +Significant performance degradation of qemu-x86_64 starting from version 3 on aarch64 +Description of problem: +When I ran CoreMark with different qemu user-mode versions，guest x86-64-> host arm64, I found that the performance was highest with QEMU 2.x versions, and there was a significant performance degradation starting from QEMU version 3. What is the reason? + +| | | | | | | | | | | | | +|------------------------------------------|-------------|-------------|-------------|-------------|-------------|-------------|------------|-------------|-------------|-------------|-------------| +| qemu version | 2.5.1 | 2.8.0 | 2.9.0 | 2.9.1 | 3.0.0 | 4.0.0 | 5.2.0 | 6.2.0 | 7.2.13 | 8.2.6 | 9.0.1 | +| coremark score | 3905.995703 | 4465.947153 | 4534.119247 | 4538.577912 | 1167.337886 | 1163.399453 | 928.348384 | 1327.051954 | 1301.659616 | 1034.714677 | 1085.304971 | diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2600 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2600 new file mode 100644 index 000000000..0461315a4 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2600 @@ -0,0 +1 @@ +qemu-user MAP_SHARED TB invalidation diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2632 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2632 new file mode 100644 index 000000000..dea9128d6 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2632 @@ -0,0 +1,83 @@ +tcg optimization breaking memory access ordering +Description of problem: +The following code creates register dependency between 2 loads, which forces the first load to finish before the second: +``` +movz w0, #0x2 +str w0, [x1] +ldr w2, [x1] +eor w3, w2, w2 +ldr w4, [x5, w3, sxtw] +``` + +While translating it to tcg IR, it keeps this dependency correctly. +But after running tcg optimizations, it optimized the tcg sequence for `eor w3, w2, w2` at `0000000000000144` to `mov_i64 x3,$0x0`. which then removes the dependency between the loads. + +It results in incorrect behavior on the host on a multiple threaded program +Steps to reproduce: +1. +2. +3. +Additional information: +``` +OP: + ld_i32 loc0,env,$0xfffffffffffffff0 + brcond_i32 loc0,$0x0,lt,$L0 + st8_i32 $0x0,env,$0xfffffffffffffff4 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 + + ---- 000000000000013c 0000000000000000 0000000000001c00 + mov_i64 loc3,x1 + mov_i64 loc4,loc3 + qemu_st_a64_i64 x0,loc4,w16+un+leul,2 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + mov_i64 loc5,x1 + mov_i64 loc6,loc5 + qemu_ld_a64_i64 x2,loc6,w16+un+leul,2 + + ---- 0000000000000144 0000000000000000 0000000000000000 + and_i64 loc7,x2,$0xffffffff + xor_i64 x3,x2,loc7 + and_i64 x3,x3,$0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + mov_i64 loc9,x5 + mov_i64 loc10,x3 + ext32s_i64 loc10,loc10 + add_i64 loc9,loc9,loc10 + mov_i64 loc11,loc9 + qemu_ld_a64_i64 x4,loc11,w16+un+leul,2 + st8_i32 $0x1,env,$0xfffffffffffffff4 +``` + + +``` +OP after optimization and liveness analysis: + ld_i32 tmp0,env,$0xfffffffffffffff0 pref=0xffffffff + brcond_i32 tmp0,$0x0,lt,$L0 dead: 0 + st8_i32 $0x0,env,$0xfffffffffffffff4 dead: 0 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 sync: 0 dead: 0 pref=0xffffffff + + ---- 000000000000013c 0000000000000000 0000000000001c00 + qemu_st_a64_i64 $0x2,x1,w16+un+leul,2 dead: 0 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + qemu_ld_a64_i64 x2,x1,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000144 0000000000000000 0000000000000000 + mov_i64 x3,$0x0 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + qemu_ld_a64_i64 x4,x5,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + st8_i32 $0x1,env,$0xfffffffffffffff4 dead: 0 +``` diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2634 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2634 new file mode 100644 index 000000000..cbc16f869 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2634 @@ -0,0 +1,177 @@ +Replay/record does not work with `rrsnapshot`/`loadvm` +Description of problem: +Qemu's record/replay feature does not properly work when using snapshots (like rrsnapshot). + +Record/replay without snapshotting works just fine, but when using `rrsnapshot=...` the replay is stuck at boot. `loadvm` monitor command also gets qemu stuck. + +Record command: + +``` +$ qemu-system-x86_64 \ + -cpu SandyBridge -smp 1 \ + -serial stdio -display none \ + -m 4096 \ + -drive file=./empty.qcow2,id=rr \ + -kernel ./boot/vmlinuz-lts \ + -initrd ./boot/initramfs-lts . + -monitor telnet::12345,server,nowait \ + -append "console=ttyS0 root=/dev/ram0 alpine_dev=cdrom:iso9660 modules=loop,squashfs,sd-mod,usb-storage quiet" \ + -icount shift=auto,rrfile=rr,rr=record,rrsnapshot=init +``` + +Broken replay command, which gets qemu stuck: + +``` +$ qemu-system-x86_64 \ + -cpu SandyBridge -smp 1 \ + -serial stdio -display none \ + -m 4096 \ + -drive file=./empty.qcow2,id=rr \ + -kernel ./boot/vmlinuz-lts \ + -initrd ./boot/initramfs-lts . + -monitor telnet::12345,server,nowait \ + -append "console=ttyS0 root=/dev/ram0 alpine_dev=cdrom:iso9660 modules=loop,squashfs,sd-mod,usb-storage quiet" \ + -icount shift=auto,rrfile=rr,rr=replay,rrsnapshot=init + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +``` + +Record/replay without `rrsnapshot`/`loadvm`/etc works as expected. +Steps to reproduce: +To reproduce i've used alpine linux kernel as the guest: + +``` +wget https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-standard-3.20.3-x86_64.iso +7z x alpine-standard-3.20.3-x86_64.iso +``` + +Prerequisites - an empty qcow2 file for snapshots: + +``` +qemu-img create -f qcow2 empty.qcow2 1G +``` + +Running an alpine linux kernel with `rr=record` - works just fine, kernel boots, accepts input. + +``` +$ qemu-system-x86_64 \ + -cpu SandyBridge -smp 1 \ + -serial stdio -display none \ + -m 4096 \ + -drive file=./empty.qcow2,id=rr \ + -kernel ./boot/vmlinuz-lts \ + -initrd ./boot/initramfs-lts . + -monitor telnet::12345,server,nowait \ + -append "console=ttyS0 root=/dev/ram0 alpine_dev=cdrom:iso9660 modules=loop,squashfs,sd-mod,usb-storage quiet" \ + -icount shift=auto,rrfile=rr,rr=record,rrsnapshot=init + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +mount: mounting /dev/ram0 on /sysroot failed: Invalid argument +Mounting root failed. +initramfs emergency recovery shell launched. Type 'exit' to continue boot +sh: can't access tty; job control turned off +~ # ls -alh +total 32K +drwx------ 18 root root 0 Oct 21 13:02 . +drwx------ 18 root root 0 Oct 21 13:02 .. +-rw------- 1 root root 8 Oct 21 13:02 .ash_history +drwxr-xr-x 2 root root 0 Jun 18 12:44 .modloop +drwxr-xr-x 2 root root 0 Oct 21 13:02 bin +drwxr-xr-x 9 root root 2.5K Oct 21 13:02 dev +drwxr-xr-x 4 root root 0 Oct 21 13:02 etc +-rwxr-xr-x 1 root root 25.9K Jun 18 12:44 init +drwxr-xr-x 5 root root 0 Jun 18 12:44 lib +drwxr-xr-x 5 root root 0 Jun 18 12:44 media +drwxr-xr-x 2 root root 0 Jun 18 12:44 newroot +dr-xr-xr-x 114 root root 0 Oct 21 13:02 proc +drwx------ 2 root root 0 Sep 4 12:53 root +drwxr-xr-x 3 root root 0 Oct 21 13:02 run +drwxr-xr-x 2 root root 0 Oct 21 13:02 sbin +dr-xr-xr-x 13 root root 0 Oct 21 13:02 sys +drwxr-xr-x 2 root root 0 Oct 21 13:02 sysroot +drwxr-xr-x 2 root root 0 Oct 21 13:02 tmp +drwxr-xr-x 5 root root 0 Oct 21 13:02 usr +drwxr-xr-x 3 root root 0 Jun 18 12:44 var +~ # echo "AAAAAAAA?" +AAAAAAAA? +~ # +``` + +`rr`-file is produced, which can be used for replaying **without** `rrsnapshot`-option: + +``` +$ qemu-system-x86_64 \ + -cpu SandyBridge -smp 1 \ + -serial stdio -display none \ + -m 4096 \ + -drive file=./empty.qcow2,id=rr \ + -kernel ./boot/vmlinuz-lts \ + -initrd ./boot/initramfs-lts . + -monitor telnet::12345,server,nowait \ + -append "console=ttyS0 root=/dev/ram0 alpine_dev=cdrom:iso9660 modules=loop,squashfs,sd-mod,usb-storage quiet" \ + -icount shift=auto,rrfile=rr,rr=replay + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +mount: mounting /dev/ram0 on /sysroot failed: Invalid argument +Mounting root failed. +initramfs emergency recovery shell launched. Type 'exit' to continue boot +sh: can't access tty; job control turned off +~ # ls -alh +total 32K +drwx------ 18 root root 0 Oct 21 13:02 . +drwx------ 18 root root 0 Oct 21 13:02 .. +-rw------- 1 root root 8 Oct 21 13:02 .ash_history +drwxr-xr-x 2 root root 0 Jun 18 12:44 .modloop +drwxr-xr-x 2 root root 0 Oct 21 13:02 bin +drwxr-xr-x 9 root root 2.5K Oct 21 13:02 dev +drwxr-xr-x 4 root root 0 Oct 21 13:02 etc +-rwxr-xr-x 1 root root 25.9K Jun 18 12:44 init +drwxr-xr-x 5 root root 0 Jun 18 12:44 lib +drwxr-xr-x 5 root root 0 Jun 18 12:44 media +drwxr-xr-x 2 root root 0 Jun 18 12:44 newroot +dr-xr-xr-x 114 root root 0 Oct 21 13:02 proc +drwx------ 2 root root 0 Sep 4 12:53 root +drwxr-xr-x 3 root root 0 Oct 21 13:02 run +drwxr-xr-x 2 root root 0 Oct 21 13:02 sbin +dr-xr-xr-x 13 root root 0 Oct 21 13:02 sys +drwxr-xr-x 2 root root 0 Oct 21 13:02 sysroot +drwxr-xr-x 2 root root 0 Oct 21 13:02 tmp +drwxr-xr-x 5 root root 0 Oct 21 13:02 usr +drwxr-xr-x 3 root root 0 Jun 18 12:44 var +~ # echo "AAAAAAAA?" +AAAAAAAA? +~ # +``` + +As you can see, replaying emulation session works as expected. How ever, if I add the `rrsnapshot`-option, it gets stuck: + +``` +$ qemu-system-x86_64 \ + -cpu SandyBridge -smp 1 \ + -serial stdio -display none \ + -m 4096 \ + -drive file=./empty.qcow2,id=rr \ + -kernel ./boot/vmlinuz-lts \ + -initrd ./boot/initramfs-lts . + -monitor telnet::12345,server,nowait \ + -append "console=ttyS0 root=/dev/ram0 alpine_dev=cdrom:iso9660 modules=loop,squashfs,sd-mod,usb-storage quiet" \ + -icount shift=auto,rrfile=rr,rr=replay,rrsnapshot=init + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +``` + +This also can be reproduced without `rrsnapshot` option, by issuing `loadvm init` from qemu monitor: + +``` +$ telnet localhost 12345 +qemu> loadvm init +... +``` + +Or, by using `gdb` and issuing reverse-commands that require `loadvm` to load previous state, like `reverse-stepi` or `reverse-continue`. + +Attaching a debugger & using debug-prints shows some thread being stuck in the [`rcu.c`](https://gitlab.com/qemu-project/qemu/-/blob/master/util/rcu.c), near the `qemu_event_wait(&rcu_call_ready_event);`. I've tried to wait for quite some time (about an hour) and there was no result. +Additional information: +**Qemu build.** Qemu binary built from sources of 9.1.0 with `--target-list=x86_64-softmmu`. + +**Host machine.** An almost clean Ubuntu 20.04 with necessary packages for building qemu from the latest release sources. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2645 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2645 new file mode 100644 index 000000000..49292945e --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2645 @@ -0,0 +1,23 @@ +Failed shutdown during record with `ide-hd` disk. +Description of problem: +Running `shutdown -h now` on the guest with an `ide-hd` disk during a recording results in a long wait, followed by a BMDMA error. +Steps to reproduce: +1. Install Ubuntu Server guest OS and create disk snapshot +1. Reboot and log in: `qemu-system-x86_64 -hda ubuntu_snapshot.qcow2 -m 2g -net none -monitor stdio` +2. Take a snapshot: `savevm loggedin` +3. Start recording from VM snapshot: `./qemu/build/qemu-system-x86_64 -icount shift=auto,rr=record,rrfile=ubuntu_shutdown.bin -drive file=ubuntu_snapshot.qcow2,if=none,id=img-direct -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay -device ide-hd,drive=img-blkreplay -loadvm loggedin -net none -m 2g` +4. Run `shutdown -h now` in guest +5. Wait (~5-10 mins) +6. Observe BMDMA error (see below) +Additional information: +``` +ata1.00: exeption Emask 0x0 SAct 0.0 SErr 0.0 action 0x6 +ata1.00: BMDMA stat 0x5 +ata1.00: failed command: READ DMA +ata1.00: cmd c8/xx:xx:xx:xx:xx/xx:xx:xx:xx:xx/xx tag - dma 4096 in + res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) +ata1.00: revalidation failed (errno=-2) +... +``` + +Note: Running the same command on a guest with a `virtio` disk results in further progress, but still does not shut down (stuck on `[ OK ] Stopped Create final runtime dir for shutdown pivot root.`) diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2683 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2683 new file mode 100644 index 000000000..105ef56a2 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2683 @@ -0,0 +1,39 @@ +TCG: probe_access() has inconsistent behavior +Description of problem: +In full-system mode, probe_access() will return NULL when the flag is TLB_MMIO. + +accel/tcg/cputlb.c: probe_access_internal() +``` + if (unlikely(flags & ~(TLB_WATCHPOINT | TLB_NOTDIRTY | TLB_CHECK_ALIGNED)) + || (access_type != MMU_INST_FETCH && force_mmio)) { + *phost = NULL; + return TLB_MMIO; + } +``` +But in linux-user mode, it will return correct address when the flag is TLB_MMIO. + +accel/tcg/user-exec.c: probe_access() +``` + return size ? g2h(env_cpu(env), addr) : NULL; +``` +This will lead to some different behaviors, like cbo.zero in RISC-V. + +target/riscv/op_helper.c: helper_cbo_zero() +``` + mem = probe_write(env, address, cbozlen, mmu_idx, ra); + + if (likely(mem)) { + memset(mem, 0, cbozlen); + } else { + for (int i = 0; i < cbozlen; i++) { + cpu_stb_mmuidx_ra(env, address + i, 0, mmu_idx, ra); + } + } +``` +When the current instruction has memory callback by plugin: + +Full-system mode uses slow-path(cpu_stb_mmuidx_ra) and inject mem_cbs correctly. + +Linux-user mode uses fast-path(memset) and doesn't inject callbacks. + +To ensure consistent results, probe_access() should return NULL when the flag is TLB_MMIO in linux-user mode. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2685 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2685 new file mode 100644 index 000000000..d8fa3884d --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2685 @@ -0,0 +1 @@ +Netbsd 10.0 AMD64 as host fails in tcg? diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2790 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2790 new file mode 100644 index 000000000..13ae1bb25 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2790 @@ -0,0 +1,10 @@ +Can't switch to monitor with rr=record +Description of problem: +With the above args, while the guest is paused (either because I haven't attached GDB yet, or because I've halted execution in GDB), it's not possible to switch to the QEMU monitor. + +I don't reproduce this issue with `QEMU emulator version 8.2.4 (Debian 1:8.2.4+ds-1+build1)` but I do with 9.2 and master (built from source). + +AFAICT, the monitor is working - if I just set `-monitor stdio` instead of `-serial mon:stdio` I can use it, including when the VM is paused. But the multiplexing doesn't work. +Steps to reproduce: +1. Run the above +2. Ctrl-A, c diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2791 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2791 new file mode 100644 index 000000000..5807c339d --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2791 @@ -0,0 +1,63 @@ +"Missing character write event in the replay log" when trying rr=replay with snapshot +Description of problem: +Probably best to just illustrate with commands. Happy path: + +```sh +rm replay.bin snapshots.qcow2; qemu-img create -f qcow2 snapshots.qcow2 256M + +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=record,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" + +# It runs, guest kernel crashes when realising it has no rootfs, all good +du -sh snapshots.qcow2 # 976K + +# Repeat same command just switched to rr=replay +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=replay,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" +# Much slower, but same result. All good +``` + +But, I want to take a snapshot later in boot. + +```sh +rm replay.bin snapshots.qcow2; qemu-img create -f qcow2 snapshots.qcow2 256M + +# This time, running with debug. Also have to switch to -monitor stdio because of +# https://gitlab.com/qemu-project/qemu/-/issues/2790 +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -monitor stdio \ + -icount shift=auto,rr=record,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" \ + -s -S + +# In another terminal, attach a debugger, set a breakpoint, continue to the breakpoint +gdb -ex "target remote localhost:1234" .kunit/vmlinux +(gdb) hb start_kernel +(gdb) continue + +# When the breakpoint is hit, back in the first terminal: +(qemu) savevm test +(qemu) quit + +du -sh snapshots.qcow2 # 21M + +# Now try to replay again +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=replay,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" +``` + +Result: + +``` +qemu-system-x86_64: Missing character write event in the replay log (insn total 1598039/586 left, event 886 is EVENT_INSTRUCTION) +fish: Job 1, '~/src/qemu/build/qemu-system-x8…' terminated by signal -icount shift=auto,rr=repla… ( -drive file=snapshots.qcow2…) +fish: Job -kernel ./.kunit/arch/x86/b…, 'SIGABRT' terminated by signal Abort () +``` + +Exit code is 134. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/280 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/280 new file mode 100644 index 000000000..22ea4e203 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/280 @@ -0,0 +1 @@ +(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2815 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2815 new file mode 100644 index 000000000..d0181271b --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2815 @@ -0,0 +1 @@ +clang 17 and newer -fsanitize=function causes QEMU user-mode to SEGV when calling TCG prologue diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/283 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/283 new file mode 100644 index 000000000..78e5de8d3 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/283 @@ -0,0 +1 @@ +TCG memory leak with FreeDOS 'edit' diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2899 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2899 new file mode 100644 index 000000000..43a5b2710 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2899 @@ -0,0 +1,36 @@ +Regression 10.0.0rc1: Segmentation fault on executing QEMU advent calendar 2014, day 4 +Description of problem: +On executing QEMU, a segmentation fault occurs +Steps to reproduce: +1. Download https://www.qemu-advent-calendar.org/2014/download/stxmas.tar.xz +2. Execute with QEMU command line +Additional information: +git bisect finishes with: + +``` +456709db50f424d112bc5f07260fdc51555f3a24 is the first bad commit +commit 456709db50f424d112bc5f07260fdc51555f3a24 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Sun Dec 15 10:06:10 2024 +0100 + + target/i386: execute multiple REP/REPZ iterations without leaving TB + + Use a TCG loop so that it is not necessary to go through the setup steps + of REP and through the I/O check on every iteration. Interestingly, this + is not a particularly effective optimization on its own, though it avoids + the cost of correct RF emulation that was added in the previous patch. + The main benefit lies in allowing the hoisting of loop invariants outside + the loop, which will happen separately. + + The loop exits when the low 16 bits of CX/ECX/RCX are zero (so generally + speaking the string operation runs in 65536 iteration batches) to give + the main loop an opportunity to pick up interrupts. + + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Link: https://lore.kernel.org/r/20241215090613.89588-12-pbonzini@redhat.com + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/translate.c | 55 ++++++++++++++++++++++++++++++++++++++++----- + 1 file changed, 49 insertions(+), 6 deletions(-) +``` diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/290 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/290 new file mode 100644 index 000000000..5da1198c3 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/290 @@ -0,0 +1 @@ +mmap MAP_NORESERVE of 2^42 bytes consumes 16Gb of actual RAM diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2906 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2906 new file mode 100644 index 000000000..8ee9d6540 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2906 @@ -0,0 +1,13 @@ +x86 (32-bit) multicore very slow, but x86-64 is fast (on macOS arm64 host) +Description of problem: +More cores doesn't slow down a x86-32 guest on an x86-64 host, nor does it slow down an x86-64 guest on an arm64 host. However, adding extra cores massively slows down an x86-32 guest on an arm64 host. +Steps to reproduce: +1. Run 32-bit guest or 32-bit installer +2. +3. + +I have replicated this over several OSes using homebrew qemu, source-built qemu and UTM. This is not to be confused with a different bug in UTM that caused its version of QEMU to be slow. + +This also seems to apply to 32-bit processes in an x86-64 guest. +Additional information: +https://github.com/utmapp/UTM/issues/5468 diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2907 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2907 new file mode 100644 index 000000000..86c813dfd --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2907 @@ -0,0 +1 @@ +replay_mutex_unlock() assertion on macOS diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/2914 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2914 new file mode 100644 index 000000000..df00cc5dc --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/2914 @@ -0,0 +1,15 @@ +JRE fails (SIGSEGV) on x86 Ubuntu 24.04 LTS emulated on Apple Silicon M2 ARM +Description of problem: +JRE (HotSpot Runtime) errors with SIGSEGV on x86 Linux Ubuntu 24.04.2 LTS when it is emulated on Apple Silicon M2. In this case, JRE is being triggered by SBT that is running Scala source code. + +This could be a Qemu issue, an OpenJDK issue, an Apple issue, etc. - Let me know if this is the wrong place/not under the purview of Qemu and I'll post it somewhere else. +Steps to reproduce: +I am attempting to run a Scala project (https://github.com/ucb-bar/chipyard) on a x86 machine emulated on an Apple Silicon device. The project build flow fails on step 5 when Scala sources are compiled and run. You can reproduce the issue by running Chipyard's recommended setup flow here: + +https://chipyard.readthedocs.io/en/stable/Chipyard-Basics/Initial-Repo-Setup.html#default-requirements-installation + +Then instead of running the given build-setup command in the tutorial, run `./build-setup.sh riscv-tools -s 3 -s 8 -s 7 -s 8 -s 9 -s 10 --use-lean-conda` in order to skip the irrelevant setup steps. + +The SBT build config is in the project's base directory under build.sbt. There is a commonSettings sequence that is inherited by each subsequent project. The flow: line 409 of common.mk is triggered by line 257 & 258 of build-setup.sh, which then triggers SBT with some arguments passed into the SBT executable. +Additional information: +Extensive crash logs and attempts to solve the issue has been documented at this issue on UTM's GitHub: https://github.com/utmapp/UTM/issues/7070 diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/326 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/326 new file mode 100644 index 000000000..380615a8d --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/326 @@ -0,0 +1 @@ +QEMU-user ignores MADV_DONTNEED diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/329 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/329 new file mode 100644 index 000000000..38dba665b --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/329 @@ -0,0 +1 @@ +qemu 6.0.0 fails to build with clang-11 and --enable-debug diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/343 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/343 new file mode 100644 index 000000000..67663cbd9 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/343 @@ -0,0 +1 @@ +madvise reports success, but doesn't implement WIPEONFORK. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/358 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/358 new file mode 100644 index 000000000..13445756c --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/358 @@ -0,0 +1 @@ +qemu-user deadlocks when forked in a multithreaded process diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/360 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/360 new file mode 100644 index 000000000..1dff81acc --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/360 @@ -0,0 +1 @@ +load_helper() do_unaligned_access path doesn't return correct result with MMIO diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/363 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/363 new file mode 100644 index 000000000..ffe4c1d7a --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/363 @@ -0,0 +1 @@ +Failed to build qemu-fuzz-i386 in version 6.0.0 diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/372 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/372 new file mode 100644 index 000000000..f4458e17f --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/372 @@ -0,0 +1 @@ +Indentation should be done with spaces, not with TABs, in the TCG / CPU subsystem diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/612 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/612 new file mode 100644 index 000000000..d0630306c --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/612 @@ -0,0 +1 @@ +Much larger traces with qemu-6.1 than qemu-6.0 diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/626 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/626 new file mode 100644 index 000000000..af97843d0 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/626 @@ -0,0 +1 @@ +plugin reference to qemu_plugin_hwaddr_phys_addr fails to dynamically link diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/658 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/658 new file mode 100644 index 000000000..91b7c08f0 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/658 @@ -0,0 +1 @@ +Missing documentation for TCG ctpop opcode diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/693 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/693 new file mode 100644 index 000000000..9c2f7a7f9 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/693 @@ -0,0 +1,10 @@ +Qemu increased memory usage with TCG +Description of problem: +The issue is that instances that are supposed to use only a small amount of memory (like 256MB) suddenly use a much higher amount of RSS when running the accel=tcg, around 512MB in the above example. This was not happening with qemu-4.2 (on Ubuntu 20.04). This is also not happening when using accel=kvm instead. The issue has been first noticed on Debian 11 (Bullseye) with the versions above, but it is happening in the same way on Centos 8 Stream, Ubuntu 21.10 and a pre-release version of Ubuntu 22.04. It also also seen when testing with qemu-6.1 built from source. +Steps to reproduce: +1. Deploy devstack (https://opendev.org/openstack/devstack) with VIRT_TYPE=qemu on a VM +2. Start an instance with cirros image and a flavor allocating 256MB +3. Do a ps and see a RSS size of about 512MB being used after the instance has finished booting +4. Expected result (seen with qemu-4.2 or VIRT_TYPE=kvm): RSS stays < 256MB +Additional information: +I can try to find a smaller commandline for manual reproduction if needed. The above sample is generated by OpenStack Nova via libvirt. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/730 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/730 new file mode 100644 index 000000000..6b2e8c929 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/730 @@ -0,0 +1 @@ +test-thread-breakpoint fails with some gdb version diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/773 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/773 new file mode 100644 index 000000000..27f4f37c5 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/773 @@ -0,0 +1,27 @@ +TCG profiler build fails +Description of problem: +Attempting to build with --enable-profiler fails +Steps to reproduce: +1. ../../configure --enable-profiler +2. make +Additional information: +[975/3221] Compiling C object libcommon.fa.p/monitor_qmp-cmds.c.o + FAILED: libcommon.fa.p/monitor_qmp-cmds.c.o + cc -m64 -mcx16 -Ilibcommon.fa.p -I../../dtc/libfdt -I/usr/include/capstone -I/usr/include/pixman-1 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/libpng16 + -I/usr/include/p11-kit-1 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0 -I/us + r/include/slirp -I/usr/include/virgl -I/usr/include/libusb-1.0 -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/PCSC -I/usr/include/gtk-3.0 -I/usr + /include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/ + include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/vte-2.91 -fdiagnosti + cs-color=auto -Wall -Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /home/alex/lsrc/qemu.git/linux-headers -isystem linux-headers -iquote . -iquote /home/alex/lsrc/qemu.git + -iquote /home/alex/lsrc/qemu.git/include -iquote /home/alex/lsrc/qemu.git/disas/libvixl -iquote /home/alex/lsrc/qemu.git/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOUR + CE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-co + mmon -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wend + if-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -D_DEFAULT_SOURCE -D_ + XOPEN_SOURCE=600 -DNCURSES_WIDECHAR=1 -D_REENTRANT -DSTRUCT_IOVEC_DEFINED -MD -MQ libcommon.fa.p/monitor_qmp-cmds.c.o -MF libcommon.fa.p/monitor_qmp-cmds.c.o.d -o libcommon. + fa.p/monitor_qmp-cmds.c.o -c ../../monitor/qmp-cmds.c + ../../monitor/qmp-cmds.c: In function ‘qmp_x_query_profile’: + ../../monitor/qmp-cmds.c:369:21: error: implicit declaration of function ‘tcg_cpu_exec_time’ [-Werror=implicit-function-declaration] + 369 | cpu_exec_time = tcg_cpu_exec_time(); + | ^~~~~~~~~~~~~~~~~ + ../../monitor/qmp-cmds.c:369:21: error: nested extern declaration of ‘tcg_cpu_exec_time’ [-Werror=nested-externs] + cc1: all warnings being treated as errors diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/792 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/792 new file mode 100644 index 000000000..4e4f56e8b --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/792 @@ -0,0 +1 @@ +Qemu's helper mechanism usage related issues diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/863 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/863 new file mode 100644 index 000000000..3b5227187 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/863 @@ -0,0 +1,54 @@ +contrib/plugins/howvec.c for ARM64 under constrained +Description of problem: +Consider the static InsnClassExecCount aarch64_insn_classes array in contrib/plugins/howvec.c There are 5 entries which will never be discovered, and so count as 0; see the dump below. + +I did not figure out which of prior rows in the table was over-eagerly getting instructions intended for the subsequent counted-as-0 row. + +``` + udef aka UDEF 65536 + sve aka SVE 268435456 + res aka Reserved 268369920 + pcrel aka PCrel addr 134217728 + asit aka Add/Sub (imm,tags) 67108864 + asi aka Add/Sub (imm) 67108864 + logi aka Logical (imm) 67108864 + movwi aka Move Wide (imm) 67108864 + bitf aka Bitfield 67108864 + extr aka Extract 67108864 + dpri aka Data Proc Imm 0 + cndb aka Cond Branch (imm) 33554432 + excp aka Exception Gen 16777216 + nop aka NOP 1 + hint aka Hints 4095 + barr aka Barriers 4096 + psta aka PSTATE 32768 + sins aka System Insn 1048576 + sreg aka System Reg 2097152 + breg aka Branch (reg) 33554432 + bimm aka Branch (imm) 134217728 + cmpb aka Cmp & Branch 67108864 + tstb aka Tst & Branch 67108864 + branch aka Branches 181362688 + advlsm aka AdvSimd ldstmult 262144 + advlsmp aka AdvSimd ldstmult++ 4194304 + advlss aka AdvSimd ldst 524288 + advlssp aka AdvSimd ldst++ 16777216 + ldstx aka ldst excl 67108864 + prfm aka Prefetch 16777216 + ldlit aka Load Reg (lit) 251658240 + ldstnap aka ldst noalloc pair 67108864 + ldstp aka ldst pair 469762048 + ldstr aka ldst reg 0 + atomic aka Atomic ldst 0 + ldstro aka ldst reg (reg off) 0 + ldstpa aka ldst reg (pac) 0 + ldsti aka ldst reg (imm) 134217728 + ldst aka Loads & Stores 313786368 + dprr aka Data Proc Reg 402653184 + fpsimd aka Scalar FP 402653183 + unclas aka Unclassified 536870912 +``` +Steps to reproduce: +1. Write a simple wrapper program; iterate and search through all 2**32 insns, dump the array +2. +3. diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/896 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/896 new file mode 100644 index 000000000..01b9116f6 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/896 @@ -0,0 +1 @@ +tcg/arm emits UNPREDICTABLE LDRD insn diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/898 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/898 new file mode 100644 index 000000000..e8535f9b2 --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/898 @@ -0,0 +1 @@ +check-tcg sha512-mvx test is failing on s390x hosts diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/947 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/947 new file mode 100644 index 000000000..70d2f1fca --- /dev/null +++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/947 @@ -0,0 +1,13 @@ +TCG AARCH64 Segmentation fault when helper function is called +Description of problem: +Segmentation fault in the TCG thread. +The issue occurs in the generated code when branching to (helper)lookup_tb_ptr (see op longs). +It seems that the generated instruction don't load the upper32 of the address of lookup_tb_ptr in the register before branching to it. According to LLDB, the program tries to access 0x1cffe060 while the right address 0x7ff71cffe060 (see debugger logs). +Additional information: +The issue seems to be located at https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/aarch64/tcg-target.c.inc#L1091 +`t2 = t1 & ~(0xffffUL << s1);`. +The fix would be `t2 = t1 & ~(0xffffULL << s1);` + + +[lldb.log](/uploads/6a1d57eaecae4a375c6ada7384489876/lldb.log) +[qemu_segmentation.log](/uploads/e3c2d6d42291ff7d1ff8d37341e3da1d/qemu_segmentation.log) |